Um gerador de número de cartão de crédito é usado em desenvolvimento para preencher formulários de pagamento sem que nenhum número real entre no ambiente. A confusão que cerca o assunto vem do fato de que um número de teste e um número real têm exatamente o mesmo formato: mesma quantidade de dígitos, mesmo tipo de prefixo, mesmo dígito verificador calculado pela mesma regra. O que os separa não é a aparência, e sim a origem e o destino. Neste texto, explicamos o que caracteriza um número de teste, como os prefixos de bandeira funcionam, por que o dígito verificador não pode ser inventado, por que o código de segurança e a data de validade precisam fazer parte do mesmo conjunto e quais são os limites que a norma de segurança de dados de cartão impõe mesmo em ambiente de homologação.
O que diferencia um número de teste de um número real?
Um número de teste é um valor gerado para exercitar software. Ele pode ter a estrutura correta, o dígito verificador correto e o prefixo de uma bandeira, e ainda assim não corresponder a nenhuma conta, porque não foi emitido por instituição nenhuma. É essa ausência de emissão que o torna seguro para circular em repositório, em relatório de teste e em captura de tela.
Um número real pertence a alguém, tem limites de crédito associados e produz consequência quando usado. Ele nunca deve entrar em ambiente de desenvolvimento, nem como exemplo em documentação, nem como valor de teste em script, nem em um arquivo de configuração esquecido.
A semelhança entre os dois é justamente o que torna o cuidado necessário. Não existe um dígito secreto que marque um número como “de verdade”. A única forma de distinguir é pela origem, e é por isso que a prática correta é nunca usar número que não tenha vindo de uma fonte de teste declarada.
Como os prefixos de bandeira definem o número?
Os primeiros dígitos do número formam o identificador da instituição emissora, conhecido como IIN ou, no uso corrente, BIN. Esse prefixo determina a bandeira e, em muitos casos, o tipo de produto e o país de emissão. É por isso que um número de teste precisa começar com um prefixo plausível: um formulário que detecta a bandeira pelo prefixo vai classificar o número de forma errada se o valor não seguir essa convenção.
Na prática de teste, o prefixo importa por três razões. A primeira é que o formulário exibe a bandeira, e testar a exibição exige um número de cada tipo. A segunda é que a validação de campos depende da bandeira em alguns produtos, incluindo o tamanho do código de segurança. A terceira é que roteamento e taxa variam por bandeira, então um teste de cálculo de valor precisa de exemplos de mais de uma.
O erro comum é gerar o prefixo certo e o restante dos dígitos de forma aleatória. O resultado tem a aparência correta e falha na validação de dígito verificador, que é a primeira regra aplicada por qualquer formulário bem-feito.
Por que o dígito verificador não pode ser inventado?
A maior parte dos números de cartão carrega um dígito verificador calculado por um algoritmo conhecido como Luhn, descrito na segunda metade do século vinte e ainda usado porque resolve bem o problema de detectar erro de digitação simples. O algoritmo percorre os dígitos da direita para a esquerda, dobra o valor de cada segundo dígito, soma os algarismos do resultado quando ele passa de nove e verifica se o total é divisível por dez.
A consequência prática é direta: inventar o último dígito produz um número que falha na validação em praticamente todos os casos, com chance de acerto de uma em dez. Um gerador que se preocupa com o dado de teste calcula o dígito em vez de sorteá-lo, e é isso que faz o número passar na validação de formato sem que ele pertença a ninguém.
Vale testar os dois lados. Use números com dígito verificador correto para os casos em que o sistema deve aceitar, e mantenha à parte um conjunto pequeno com dígito alterado para os casos em que o sistema deve recusar. Se o seu formulário aceita todos os números, o defeito pode estar na validação ausente, e não na lógica de pagamento que ninguém chegou a executar.
O código de segurança e a validade fazem parte do mesmo conjunto?
Fazem, e ignorar isso é uma fonte comum de teste enganoso. O código de segurança, chamado de CVV ou CVC, é um valor curto que não aparece impresso no mesmo lugar que o número e não é armazenado pelo comerciante. O tamanho varia conforme a bandeira, e por isso o seu campo precisa aceitar as duas possibilidades em vez de fixar um tamanho único.
A data de validade tem regras próprias. Ela precisa estar no futuro para que o formulário aceite, e o formato em que é digitada varia entre mês e ano, ano e mês e outras combinações. Testar apenas uma data distante no futuro deixa de fora os casos que mais quebram: o cartão que vence no mês corrente, a data digitada com dois dígitos de ano e a virada de ano na comparação.
O conjunto também precisa ser coerente consigo mesmo. Um registro com bandeira de um tipo, código de segurança de tamanho de outro e validade já vencida é útil como caso negativo e inútil como caso positivo. Separe os dois grupos e rotule cada um no próprio arquivo de teste.
Por que usar os cartões oficiais do gateway?
Os provedores de pagamento publicam conjuntos de números de teste documentados, com bandeiras, comportamentos esperados e respostas de erro simuladas. Usar esses valores é melhor do que gerar números próprios quando o objetivo é validar a integração, porque eles disparam respostas conhecidas dentro do ambiente de teste do provedor.
A documentação de teste da Stripe é um exemplo: cada número corresponde a um cenário, como aprovação, recusa por fundos insuficientes ou exigência de autenticação adicional. O mesmo padrão aparece em outros provedores, e vale manter um catálogo interno que relacione cada número ao cenário que ele simula.
O gerador tem outro papel. Ele serve para os cenários em que você precisa de volume e variedade: testar a máscara do campo com números de bandeiras diferentes, verificar como a tela se comporta com entradas parciais, popular uma base de homologação com muitos registros plausíveis. Nesses casos, a resposta do provedor não importa, e o custo de gerar é baixo.
Até onde vai a fronteira da PCI DSS em teste?
A norma de segurança de dados da indústria de cartões trata dados de conta como dados sensíveis, e ambiente de teste não é exceção. Entre outras exigências, o código de segurança não deve ser armazenado depois da autorização, e a norma pede que dados de produção não sejam usados em teste.
O que isso significa na prática é que um ambiente de homologação que recebeu uma cópia de produção está fora de conformidade, mesmo que ninguém tenha usado o dado. Cabe lembrar também que o código de segurança não pode aparecer em log, em sistema de captura de erro nem em ferramenta de observabilidade, porque o registro do log vira armazenamento.
A conclusão prática é que dado de teste sintético não é uma conveniência, e sim o caminho que permite testar sem criar risco. Um número gerado, com dígito verificador calculado e sem correspondência com conta real, pode circular no repositório e no relatório sem violar nada. O resumo sobre dados de teste e a PCI DSS aprofunda as obrigações, e o gerador de cartão de crédito desta página produz os valores usados nos cenários.
Como montar a bateria do formulário de pagamento?
Comece pelo conjunto de casos que cobrem o caminho de aceitação: um número de cada bandeira suportada, com dígito verificador correto, código de segurança de tamanho adequado e validade no futuro. Acrescente os casos de recusa, com dígito verificador errado, número com quantidade de dígitos fora da faixa, validade vencida e campo obrigatório vazio.
Depois cubra as interações. O que acontece quando o usuário cola o número com espaços? O campo aceita apenas dígitos e formata sozinho? A bandeira aparece antes de o número estar completo? O formulário aceita número com hífen, com ponto ou com espaço à direita? A mudança de bandeira altera o rótulo do código de segurança no meio do preenchimento?
Inclua também os casos de integração: resposta de recusa do provedor, tempo esgotado, resposta duplicada por duplo clique no botão de envio e comportamento da tela quando a confirmação chega depois que o usuário saiu da página. A lista de verificação do formulário de pagamento organiza esses cenários na ordem em que costumam ser executados.
Limites: dado sintético não é meio de pagamento
Os números produzidos por um gerador são dados sintéticos de formato correto, criados para exercitar o seu software. Eles não correspondem a contas, não autorizam transação, não devem ser usados para simular verificação de identidade nem para tentar qualquer operação fora do ambiente de teste do seu provedor. Também não devem ser apresentados como dado de cliente real em demonstração, porque isso cria uma expectativa falsa sobre a origem do registro.
O uso pretendido é testar: validar a máscara do campo, conferir a detecção de bandeira, exercitar o cálculo do dígito verificador no seu próprio código, verificar mensagens de erro e cobrir a integração com o provedor no modo de teste dele. Nada além disso, e nada que envolva um número que tenha sido emitido de verdade.