Gerador de Número de Cartão de Crédito

Para que serve um gerador de cartão de crédito?

Desenvolvedores de e-commerce e gateways de pagamento precisam de números de cartão válidos pelo algoritmo Luhn para testar formulários de checkout, validações de front-end e integrações com APIs de pagamento em sandbox.

Os números gerados passam na verificação Luhn mas são completamente fictícios — não correspondem a nenhum cartão real e não podem ser usados para transações.

Uso exclusivo para testes e desenvolvimento. Usar estes números para fraude é crime.

Algoritmo de Luhn e anatomia do número de cartão

Todo número de cartão de crédito impresso em um plástico — ou guardado no app da sua carteira — segue a estrutura internacional definida pela ISO/IEC 7812. O número se divide em três partes. Os primeiros seis (atualmente oito) dígitos formam o BIN/IIN (Bank Identification Number / Issuer Identification Number) e identificam a bandeira e o banco emissor. O bloco do meio é o identificador da conta, atribuído pelo emissor. O último dígito é o dígito verificador, calculado pelo algoritmo de Luhn, também conhecido como módulo 10. Sem esse dígito final, qualquer erro de digitação em um formulário de pagamento seria impossível de detectar antes da requisição entrar na rede.

O algoritmo foi criado por Hans Peter Luhn, pesquisador da IBM, em 1954 e publicado como patente americana 2.950.048 em 1960. Luhn intencionalmente colocou-o em domínio público, e por isso ele virou o checksum universal usado não só por Visa, MasterCard e Amex, mas também por números IMEI, NPI norte-americano e o Social Insurance Number canadense.

Como o checksum de Luhn é calculado

1. Pegue o número do cartão e percorra os dígitos da direita para a esquerda.
2. Dobre cada segundo dígito (posições 2, 4, 6 … contadas a partir da direita).
3. Se a duplicação gerar um número de dois dígitos, some os dígitos — equivalente a subtrair 9 (ex.: 8 × 2 = 16 → 1 + 6 = 7).
4. Some todos os dígitos transformados.
5. O número é válido se o total for múltiplo de 10.

Para gerar um número Luhn-válido, escolha todos os dígitos exceto o último, rode o algoritmo com 0 no lugar do verificador e ajuste o último dígito para o valor que torna a soma múltipla de 10. É exatamente isso que esta ferramenta faz para a bandeira escolhida.

Faixas de BIN por bandeira

• Visa — começa com 4; 13, 16 ou 19 dígitos.
• MasterCard — faixa histórica 51-55 mais o bloco moderno 2221-2720 aberto em 2017; sempre 16 dígitos.
• American Express — 34 ou 37; 15 dígitos com CID de 4 dígitos em vez de CVV.
• Discover — 6011, 65 e algumas sub-faixas; 16-19 dígitos.
• Diners Club — 300-305, 36, 38; 14-19 dígitos.
• JCB — 35 (3528-3589); 16-19 dígitos.
• Elo — bandeira brasileira (Bradesco/Banco do Brasil/Caixa), com vários BINs específicos (4011 78, 4576 31, 5066, 5067, 6362 97…); 16 dígitos.
• Hipercard — brasileira, BIN 606282; 16 ou 19 dígitos.

Além do Luhn: PCI-DSS, tokenização, EMV e 3-D Secure

O Luhn prova apenas que o número está bem formado. Não diz nada sobre o cartão existir, ter saldo ou pertencer a você. O fluxo real de autorização passa por mais três camadas. O PCI-DSS (Payment Card Industry Data Security Standard) define como o lojista pode armazenar, transmitir e proteger qualquer trecho do número; guardar o PAN inteiro quase sempre exige tokenização, em que o número original é substituído por um surrogate guardado em um cofre fortificado. Os chips EMV (Europay, MasterCard, Visa) carregam um par de chaves de criptografia assimétrica que assina cada transação, tornando uma tarja clonada muito menos útil do que era há dez anos. O 3-D Secure (Verified by Visa, MasterCard SecureCode, Amex SafeKey) acrescenta um segundo fator de autenticação para o portador em compras card-not-present, deslocando a responsabilidade pelo chargeback do lojista para o emissor.

Usos legítimos para números gerados

Números gerados servem para ambientes em que a rede de pagamento nunca vê o cartão: testes unitários de validadores de formulário e fluxos de checkout, mock data para screenshots e demos, testes de integração contra sandboxes de gateway (Stripe, Adyen, Cielo, Pagar.me, Mercado Pago, Stone). Os sandboxes normalmente publicam BINs de teste próprios (ex.: 4242 4242 4242 4242 no Stripe) e o ideal é usar esses — eles disparam respostas determinísticas de aprovação, recusa ou 3DS.

Aviso forte

Enviar um número Luhn-válido a um sistema de pagamento real tentando autorizar uma compra, contratar um serviço pago ou abrir crédito é fraude. No Brasil se enquadra no art. 171 do Código Penal (Estelionato) e, especificamente, no 171, §2-A sobre fraude eletrônica, com pena de quatro a oito anos de reclusão; nos EUA, no 18 U.S.C. § 1029; na UE, nas implementações nacionais da Diretiva 2019/713. As redes ainda rodam detecção por velocidade e comportamento, sinalizando tentativas inválidas para emissores e autoridades.

Perguntas frequentes

Por que meus cartões de teste continuam sendo recusados no sandbox? Porque os gateways comparam contra os seus próprios BINs de teste, não contra o algoritmo. Use o BIN publicado na documentação do gateway — 4242… do Stripe, 4111… do Adyen, 4242… do Pagar.me etc.

O gerador também produz um CVV e uma validade reais? Não. O CVV/CVC2 é calculado pelo emissor a partir do PAN, de um service code e de uma chave secreta (card verification key) que a rede nunca publica. A validade é definida livremente pelo emissor. Sandboxes aceitam qualquer CVV bem formatado e qualquer data futura.

Por que a Amex tem 15 dígitos e os outros 16? Razão histórica. A American Express lançou sua rede proprietária em 1958 e padronizou em 15 dígitos antes de a família ISO 7812 ser harmonizada. O PAN mais curto é compensado por um CID de 4 dígitos impresso na frente do cartão.

O Luhn é criptograficamente seguro? Não — é um checksum, não um hash nem uma assinatura. Um atacante determinado gera um número Luhn-válido trivialmente; a segurança contra fraude vem do EMV, do 3DS e do motor antifraude do emissor, não do dígito verificador.