Validar número de cartão é uma expressão que esconde três perguntas diferentes, e quase todo defeito de checkout nasce de tratá-las como se fossem uma só. O número tem uma forma plausível? A soma de verificação fecha? A conta existe e pode ser cobrada? A primeira e a segunda pergunta você responde localmente. A terceira, nunca.
As três perguntas atrás da palavra válido
Vale separar bem cada camada, porque cada uma tem um propósito e um lugar no fluxo.
A checagem de forma olha para o conjunto: a entrada contém apenas dígitos, o comprimento corresponde a alguma bandeira conhecida e o prefixo indica qual delas. É uma verificação de digitação, feita para barrar erros grosseiros ainda no formulário.
A checagem aritmética aplica o algoritmo de Luhn e confirma que o último dígito foi calculado a partir dos anteriores. Ela pega trocas de algarismo e inversões comuns e é barata o bastante para rodar em qualquer lugar.
A checagem de existência é a autorização. Só ela diz se a conta está ativa, se tem limite e se o portador pode usar aquele cartão. Exige uma chamada à rede de pagamentos, tem custo e nunca deve ser feita em ambiente de teste.
A ordem que evita mensagens confusas
A sequência importa mais do que parece, porque cada etapa produz um erro diferente e o cliente precisa entender o que corrigir:
- Limpe a entrada, removendo espaços, hífens e pontos.
- Confirme que o que restou é composto apenas de dígitos.
- Compare o comprimento com as faixas plausíveis de cada bandeira.
- Identifique a bandeira pelo prefixo e verifique se ela é aceita pela loja.
- Aplique a conta do dígito verificador.
- Deixe a autorização para o servidor, junto do restante da compra.
Se a ordem se inverte, o resultado é uma mensagem genérica de número inválido para um cliente que apenas digitou um dígito a mais. Esse tipo de feedback faz o usuário desistir da compra.
Um detalhe que aparece mais do que se espera: nem todo caractere que parece um dígito é um dígito. Colagens vindas de documentos e planilhas podem trazer algarismos de outros alfabetos, sinais invisíveis de direção de texto e espaços que não são o espaço comum. Todos parecem iguais na tela e falham na comparação. Por isso a normalização precisa ser explícita — converter para a forma canônica, remover o que não for algarismo comum e só então medir o comprimento. Vale testar esse caminho com um valor colado de um documento real, porque é assim que o problema chega ao suporte. Se a sua rotina de limpeza descarta tudo o que não for alfanumérico, é provável que ela apague demais e transforme uma entrada válida em um número truncado.
O que dizer quando a checagem falha
A mensagem é parte da validação, não um detalhe de interface. Algumas diretrizes funcionam bem:
- Fale do campo, não do cliente: peça que confira o número digitado, sem insinuar má-fé.
- Se a bandeira não é aceita pela loja, diga isso de forma explícita. É diferente de um número errado.
- Nunca exponha o motivo técnico. “Dígito verificador inválido” não ajuda ninguém que não seja programador.
- Marque o campo, mantenha o valor digitado e mova o foco para ele. Apagar tudo obriga a redigitar.
- Evite validar enquanto o cliente ainda está digitando. Espere a saída do campo ou o envio do formulário.
Dá para validar sem fazer a conta do dígito?
Dá, mas você perde justamente a checagem mais útil contra erro de digitação. A conta é rápida, não depende de rede e não exige nenhuma biblioteca externa: são poucas operações aritméticas sobre os algarismos.
O que ela não substitui é a verificação de comprimento e de bandeira. Um número pode ter o dígito correto e ainda assim ter quinze dígitos em uma bandeira que usa dezesseis, como explica o texto sobre formato do número do cartão.
Basta validar no navegador?
Não. A validação no cliente é conveniência para o usuário; a validação no servidor é requisito de segurança. Tudo o que roda no navegador pode ser alterado ou ignorado, inclusive por quem envia requisições direto para a sua API sem passar pela tela.
Na prática, isso significa manter as mesmas regras nos dois lados — ou, melhor, manter uma única implementação de referência no servidor e repetir no cliente apenas o necessário para dar retorno rápido. Divergências entre as duas costumam aparecer meses depois, como um cartão legítimo recusado apenas em um dos lados.
Testando a validação com dados sintéticos
Para verificar se a sua implementação aceita o que deveria, você precisa de números bem formados — e não pode usar cartões de verdade. O gerador de cartão virtual desta página produz números com prefixo, comprimento e dígito verificador corretos para a bandeira escolhida, além de validade e código de segurança coerentes. Os valores são sintéticos, estruturalmente válidos e nunca foram emitidos por nenhuma instituição, portanto não funcionam em uma cobrança real.
Para quem desenvolve: a mesma regra nos dois lados
Um resumo das decisões que costumam dar certo:
- Normalize na fronteira do sistema, antes de qualquer regra, e trabalhe sempre com dígitos limpos.
- Trate a bandeira como um dado derivado, calculado a partir do prefixo, e não como algo que o cliente informa.
- Não recuse uma bandeira desconhecida com a mesma mensagem de um número errado. São situações distintas, e a página sobre números de cartão de teste por bandeira mostra como cobrir esse cenário nos testes.
- Registre o motivo da recusa de forma estruturada, para conseguir medir quantos pedidos falham por digitação.
- Repita a bateria com números de mais de uma bandeira e de mais de um comprimento, incluindo casos propositalmente inválidos.
- Antes de publicar, percorra o checklist de teste de formulário de pagamento.
Próximos passos
Se a sua dúvida era onde colocar cada checagem, comece movendo a validação para o servidor e mantendo no cliente apenas o retorno imediato. Para exercitar o fluxo com dados que passam em todas as checagens de formato, abra o gerador de cartão virtual e monte um conjunto de teste.