Gerador de Cartão de Crédito (teste)

Gerador de cartão de crédito de teste: o algoritmo de Luhn

Diferente de CPF e CNPJ, que usam variações do Módulo 11, o número de um cartão de pagamento (crédito ou débito) é validado por um algoritmo distinto: o algoritmo de Luhn (também chamado de "mod 10"), definido pela norma ISO/IEC 7812-1 e usado por todas as bandeiras — Visa, Mastercard, Amex, Elo, Diners, Discover — como primeira linha de checagem de integridade de um número de cartão, antes de qualquer consulta a uma rede de pagamento real. É essa camada, especificamente, que este gerador produz: números que satisfazem completamente a checagem de Luhn e o padrão de prefixo (BIN) e comprimento de cada bandeira, mas que não são cartões emitidos, não têm limite, não estão associados a nenhum portador e não completam nenhuma transação real.

Casos de uso em testes de checkout e integrações de pagamento

Formulários de checkout costumam ter duas camadas de validação sobrepostas: uma validação client-side imediata (formato, comprimento, dígito de Luhn) para dar feedback rápido ao usuário, e uma validação server-side que efetivamente processa a cobrança através de um gateway (Stripe, PagSeguro, Cielo, Mercado Pago). Testes automatizados de UI — em Cypress, Playwright ou Selenium — que só precisam validar a primeira camada (máscara de input, mensagens de erro, habilitação do botão de finalizar compra) não devem depender de números de cartão de teste fornecidos por um gateway específico, porque isso acopla a suíte de testes de front-end a credenciais e ambiente sandbox de um provedor de pagamento. Gerar um número sintético que passa em Luhn resolve exatamente esse caso: testa a validação de formato sem tocar em nenhuma integração real. Para testar o fluxo completo até a cobrança de fato, o caminho correto continua sendo os cartões de teste oficiais documentados por cada gateway (que seguem o mesmo princípio de Luhn, mas são reconhecidos especificamente pelo ambiente sandbox daquele provedor).

A matemática do dígito verificador de Luhn

O algoritmo processa o número da direita para a esquerda, a partir do penúltimo dígito (o último é o próprio dígito verificador, calculado por último):

1. Percorrendo os dígitos da direita para a esquerda, dobra-se o valor de cada dígito em posição par (a 2ª posição a partir da direita, a 4ª, e assim por diante).
2. Se o resultado dessa duplicação for maior que 9, subtrai-se 9 do valor (equivalente a somar os dois algarismos do resultado — por exemplo, 8 × 2 = 16 → 1 + 6 = 7, que é o mesmo que 16 - 9).
3. Somam-se todos os dígitos resultantes (os que foram dobrados e ajustados, mais os que ficaram inalterados nas posições ímpares).
4. O número é válido se essa soma total for múltiplo de 10. Para gerar o dígito verificador de um número ainda incompleto, calcula-se a soma dos dígitos já existentes pela mesma regra e o dígito final é (10 - (soma mod 10)) mod 10 — o valor que faz a soma completa fechar em um múltiplo de 10.

Este gerador aplica essa fórmula sobre um prefixo (BIN) correto para a bandeira escolhida — por exemplo, números Visa sempre começam com 4, Amex com 34 ou 37 e tem 15 dígitos (em vez de 16), Diners Club começa com 301, 305, 36 ou 38 e tem 14 dígitos — preenche o restante do número aleatoriamente, e só então calcula o dígito de Luhn sobre a sequência completa. O resultado satisfaz simultaneamente três regras independentes: comprimento correto da bandeira, prefixo (BIN) correto da bandeira, e checksum de Luhn válido — as três condições que qualquer validação de formato de cartão, em qualquer linguagem, verifica antes de considerar um número "sintaticamente" aceitável.

Por que não usar dados de cartão reais em teste

Além da questão óbvia de segurança (um número de cartão real, mesmo sem CVV, é dado sensível sob PCI-DSS e não deve circular em código de teste, logs ou fixtures versionadas em um repositório Git), há um motivo puramente técnico: número real de cartão eventualmente expira ou é cancelado, quebrando a suíte de testes sem nenhuma mudança de código. Um número sintético gerado sob demanda não tem esse problema — é válido estruturalmente por definição, indefinidamente, porque sua validade não depende de estado externo algum.