Como o Algoritmo de Luhn Valida um Número de Cartão de Crédito
O algoritmo de Luhn é o checksum que Visa, Mastercard, Amex e praticamente toda bandeira usa para saber se um número de cartão está bem formado antes mesmo de consultar um banco. Ele dobra alguns dígitos, soma tudo e confere se o resultado é múltiplo de 10. Um único dígito digitado errado quase sempre estraga essa conta, e é por isso que um formulário de pagamento consegue rejeitar um número inválido na hora, sem round-trip nenhum com a rede do cartão.
A regra, em poucas linhas
Partindo do dígito mais à direita e andando para a esquerda, dobre cada segundo dígito. Se a duplicação passar de 9, subtraia 9 do resultado (é o mesmo que somar os dois algarismos do número dobrado). Depois some todos os dígitos, os que você dobrou e os que ficaram intactos. Se o total terminar em zero, ou seja, for múltiplo de 10, o número passa no checksum.
Não é preciso decorar tabela de multiplicação nem usar calculadora científica. É uma soma simples, e é exatamente por ser simples que qualquer navegador, terminal de POS ou formulário web consegue rodar em milissegundos.
Exemplo prático: validando um cartão passo a passo
Vamos usar 4111 1111 1111 1111, o número de teste de Visa mais conhecido do mundo, publicado oficialmente para uso em ambientes de sandbox. Ele tem 16 dígitos, e como 16 é par, o próprio primeiro dígito (o 4 mais à esquerda) cai numa posição dobrada.
| Grupo de dígitos | Quantos | Posição | O que acontece | Contribuição |
|---|---|---|---|---|
Primeiro dígito (4) | 1 | 16ª a partir da direita, par | dobrado: 4×2 = 8 | 8 |
Sete 1s em posições pares | 7 | pares, dobradas | cada 1×2 = 2 | 7 × 2 = 14 |
Oito 1s em posições ímpares | 8 | ímpares, não dobradas | somam direto | 8 × 1 = 8 |
Somando as três colunas: 8 + 14 + 8 = 30. Trinta é múltiplo de 10, então o número fecha o checksum e é considerado válido. Bate com a realidade: 4111111111111111 é de fato um número de teste Visa reconhecido por processadoras do mundo todo, de Stripe a PagSeguro.
Por que um único erro de digitação já reprova
Agora pega o mesmo número e troca só o último dígito, de 1 para 2: 4111 1111 1111 1112. É o erro clássico de quem escreve o cartão de cabeça e erra o último caractere.
O último dígito ocupa a posição 1 (a mais à direita), que é ímpar e por isso não é dobrada. Ele entra na soma pelo valor de face. Antes, esse dígito contribuía com 1 para o total de 30. Agora ele contribui com 2, então o total sobe para 31.
| Número | Último dígito | Soma final | Passa no Luhn? |
|---|---|---|---|
| 4111 1111 1111 1111 | correto | 30 | sim |
| 4111 1111 1111 1112 | trocado | 31 | não |
31 não é múltiplo de 10, e o formulário de pagamento já sabe, antes de fazer qualquer chamada para a operadora do cartão, que aquele número não pode estar certo. É essa checagem instantânea, local, sem depender de rede, que faz o Luhn valer a pena rodar no navegador do cliente.
Números de teste conhecidos por bandeira
Cada bandeira publica os próprios números de cartão de teste, usados por padrão em documentações como as da Stripe, PayPal e outros gateways. Todos passam no Luhn e nenhum pertence a uma conta real:
| Bandeira | Número de teste | Passa no Luhn |
|---|---|---|
| Visa | 4111 1111 1111 1111 | sim |
| Visa (alternativo) | 4012 8888 8888 1881 | sim |
| Mastercard | 5555 5555 5555 4444 | sim |
| American Express | 3782 822463 10005 | sim |
| Discover | 6011 1111 1111 1117 | sim |
Vale notar que o Amex quebra o padrão de agrupamento: em vez de blocos de 4, o número tem 15 dígitos divididos em 4-6-5. Isso é característica da bandeira, não erro de formatação, e o checksum de Luhn funciona do mesmo jeito independente do agrupamento visual, porque ele só olha para a sequência de dígitos.
Se você desenvolve ou testa um checkout, seja integrando Stripe, PayPal, Mercado Pago ou PagSeguro, esses números resolvem uma dúvida recorrente: quando um envio de teste é rejeitado, o problema está no seu código ou o número usado é que nunca foi válido para começo de conversa? Rodar o número pela conta do Luhn primeiro elimina essa dúvida em segundos, antes de sair depurando webhook ou payload de API.
Teste com o seu número
Cole qualquer número de cartão abaixo. O validador roda a mesma conta do Luhn no seu navegador e mostra a bandeira identificada pelo prefixo, tudo sem enviar nenhum dígito para servidor nenhum.
O que o Luhn não garante
Passar no checksum prova só que o número está matematicamente bem formado, seguindo a estrutura que a bandeira define. Isso não confirma que o cartão existe, que está ativo, que tem limite disponível ou que pertence a alguém de verdade. Um número pode ser perfeitamente válido pelo Luhn e mesmo assim nunca ter sido emitido por nenhum banco, ou ter sido cancelado há anos.
Essa confirmação (existência, status, saldo) só acontece depois, quando o pedido chega na rede da bandeira e é repassado para o banco emissor. O Luhn é a primeira camada de defesa, a que barra o erro de digitação antes de gastar uma chamada de rede. As camadas seguintes, essas sim, envolvem consultar o emissor de verdade.
Erros comuns e casos especiais
Achar que Luhn detecta qualquer erro. Ele pega a grande maioria dos erros de um dígito e boa parte das transposições entre dígitos vizinhos, mas tem um ponto cego conhecido: se dois dígitos adjacentes forem trocados de posição e a diferença entre eles for exatamente 9 (ou seja, um par 0 e 9 lado a lado), a soma final não muda. O checksum passa normalmente mesmo com os dois dígitos fora de ordem. É uma limitação documentada do método, não motivo para desconfiar da conta inteira, mas vale saber que ela existe.
Confundir validação de formato com validação de identidade. Um número aprovado no Luhn não passou por nenhuma checagem de titularidade, CVV ou data de validade. Esses três dados exigem outras verificações, feitas em outras etapas do processamento.
Testar número de produção como se fosse de teste. Os números da tabela acima são públicos e seguros para usar em sandbox, mas eles não fazem sentido fora de ambiente de teste: nenhum gateway sério vai processar uma cobrança real com 4111 1111 1111 1111, porque toda a indústria reconhece esse número como teste.
Esquecer de remover espaços e traços antes de calcular. Ao implementar a checagem manualmente, é fácil esquecer de limpar a formatação visual (espaços, hífens) antes de rodar o Luhn sobre a string. O cálculo precisa da sequência pura de dígitos.
Perguntas frequentes
O algoritmo de Luhn funciona para qualquer bandeira de cartão? Sim. Luhn é um padrão de indústria (ISO/IEC 7812-1) usado por Visa, Mastercard, American Express, Discover, Diners Club, JCB e praticamente qualquer emissor. A bandeira muda o prefixo e o comprimento do número, mas o cálculo do checksum é o mesmo em todos os casos.
Um número que passa no Luhn é garantidamente um cartão real? Não. O checksum só confirma que o número segue a estrutura matemática esperada. Existência da conta, status ativo, limite disponível e titularidade são checados depois, pelo banco emissor, não pelo cálculo do Luhn.
Por que processadoras de pagamento rodam essa checagem no navegador, antes de enviar o formulário? Porque é praticamente grátis computacionalmente e pega a maior parte dos erros de digitação na hora, sem gastar uma chamada de rede. Um cliente que errou um dígito descobre isso instantaneamente, em vez de esperar o formulário ser enviado, processado no servidor e só então rejeitado.
Dá para usar o Luhn para gerar números de cartão válidos? Tecnicamente sim, dá para calcular o último dígito (o dígito verificador) que faz um prefixo de bandeira mais um corpo de números aleatórios fechar a conta do Luhn. É exatamente assim que geradores de cartão de teste funcionam. Mas isso produz só um número estruturalmente válido, nunca um cartão real vinculado a uma conta ou banco.