Cartão de teste em gateway de pagamento: por que um número Luhn-válido não basta

É comum um dev pegar um gerador de números de cartão, produzir um "4111 1111 1111 1111" qualquer, colar no checkout de sandbox e ficar sem entender por que a transação não aprova nem recusa — simplesmente não acontece nada, ou o gateway devolve um erro genérico de "cartão inválido". A causa quase sempre é a mesma: número Luhn-válido e cartão de teste de gateway são duas coisas diferentes, e confundir as duas custa horas de depuração em cima de um problema que não existe no seu código.

O que o Algoritmo de Luhn realmente garante

O Gerador de Cartão deste site, como qualquer gerador desse tipo, produz números que satisfazem o Algoritmo de Luhn: o checksum criado por Hans Peter Luhn em 1954 e usado por praticamente todo cartão do mundo para detectar erro de digitação sem precisar consultar banco nenhum. Isso é útil para testar exatamente uma coisa — a validação de formato no front-end: o campo do formulário rejeita corretamente um número mal digitado, o JavaScript de máscara calcula o dígito certo, o layout se comporta bem com 15 dígitos (Amex) versus 16 (Visa/Mastercard).

O que esse número não tem é BIN (Bank Identification Number) registrado em nenhuma bandeira real nem em nenhum ambiente de sandbox de gateway. Ele passa no checksum e para por aí — qualquer gateway de pagamento de verdade, mesmo em modo teste, vai rejeitá-lo porque o prefixo não corresponde a nenhuma faixa que a bandeira ou o próprio gateway reconhece como válida para simulação.

O que um sandbox de gateway realmente testa

Cada adquirente e cada gateway (Stripe, Mercado Pago, PagBank, Cielo, Rede, Adyen, entre outros) mantém sua própria lista de números de cartão fictícios, documentados oficialmente, que só funcionam dentro do ambiente de teste (sandbox) daquele provedor específico com as chaves de API de teste. A diferença essencial é que esses números não são gerados por você — eles vêm prontos na documentação, e cada um simula um cenário de resposta específico do processador, não apenas "um número válido":

• Aprovação simples — o cenário feliz, confirma que o fluxo de checkout completa e a aplicação trata a resposta de sucesso corretamente.
• Recusa genérica (generic decline) — testa se a aplicação mostra a mensagem de erro certa e não trava o carrinho ou duplica a cobrança numa nova tentativa.
• Saldo insuficiente / limite excedido — cenário de recusa com motivo específico, útil quando a UX precisa diferenciar "cartão recusado" de "tente outro cartão".
• Cartão expirado ou CVV inválido — valida a mensagem de erro de validação do próprio processador, distinta da validação client-side.
• Autenticação 3DS / desafio obrigatório — dispara o fluxo de 3D Secure (redirecionamento ou modal do banco emissor), essencial para lojas que operam sob a regulamentação que exige autenticação forte em determinadas transações.
• Erro de processador / timeout simulado — testa se a aplicação lida bem com falha de comunicação, sem deixar o pedido em estado indefinido.

Alguns gateways controlam o cenário pelo próprio número do cartão de teste (é o caso mais comum). Outros, como o Mercado Pago, usam o nome do titular preenchido no formulário como gatilho do cenário — digitar um nome de teste específico no campo "nome no cartão" muda a resposta simulada, com o mesmo número de cartão de teste. Vale a pena checar isso antes de montar sua suíte, porque um teste que varia só o número pode não estar de fato cobrindo cenários diferentes se o gateway usa outro campo como gatilho.

Onde encontrar os números certos

Não existe uma lista universal — e reproduzir aqui uma lista congelada de números por provedor é, na prática, um convite a documentação desatualizada, porque cada gateway revisa periodicamente seus cartões de teste. A forma correta é sempre consultar a documentação oficial do provedor que você está integrando, na seção geralmente chamada "Test Cards", "Cartões de teste" ou "Sandbox":

• Busque pela documentação de test cards do gateway específico (Stripe, Mercado Pago, PagBank/PagSeguro, Cielo, Rede, Adyen, Braintree etc.) — todos publicam essa lista de forma aberta, sem precisar de conta paga.
• Confirme que está usando as chaves de API de teste (normalmente prefixadas com algo como test_ ou sandbox_) — usar um cartão de teste com chave de produção geralmente falha, e usar um cartão real com chave de teste nunca deveria funcionar (se funcionar, é motivo para reportar ao provedor).
• Verifique se o cenário é disparado pelo número do cartão, pelo valor da transação (alguns gateways usam centavos específicos, como R$ 1,00 para simular recusa) ou por outro campo do formulário, como no exemplo do Mercado Pago citado acima.

Erros comuns ao montar essa suíte de testes

1. Testar só o caminho de aprovação. É o erro mais caro em produção: o time testa apenas o cartão que aprova, entrega, e a primeira recusa real que chega em produção expõe um bug de tratamento de erro que nunca foi exercitado.

2. Misturar número de teste de um gateway com as chaves de outro. Cada provedor tem sua própria faixa de números de teste; um cartão de teste do Stripe não tem qualquer relação com o sandbox de outro gateway, mesmo que ambos usem, por coincidência, o mesmo prefixo de bandeira.

3. Deixar cartão de teste vazar para configuração de produção. Números de teste às vezes acabam hardcoded em algum script de seed ou fixture de CI e, por engano, terminam referenciados em um ambiente de homologação apontando para chave de produção. Isso não movimenta dinheiro real (o gateway rejeita), mas gera ruído nos logs de fraude do processador e pode acionar alertas desnecessários da equipe antifraude do gateway.

4. Confundir validação de formato com validação de negócio. Um número Luhn-válido gerado localmente é a ferramenta certa para o primeiro tipo de teste (o formulário aceita o formato certo?). Um cartão de teste oficial do gateway é a ferramenta certa para o segundo (o backend trata corretamente cada resposta do processador?). São duas camadas diferentes do mesmo checkout, e testar uma não substitui testar a outra.

Checklist antes de testar um checkout

• Validação de formato do formulário (máscara, dígito verificador, quantidade de dígitos por bandeira) testada com números Luhn-válidos genéricos.
• Cenário de aprovação testado com o cartão de teste oficial do gateway, usando chave de API de teste.
• Cenário de recusa genérica e de recusa por motivo específico (saldo, cartão expirado, CVV) cobertos separadamente.
• Fluxo de autenticação 3DS/desafio testado, se a integração ou a regulamentação do mercado exigir.
• Confirmado que o gatilho do cenário é o número do cartão, o valor da transação ou outro campo — conforme a documentação daquele gateway específico.
• Nenhuma chave de produção referenciada em ambiente de teste, e nenhum cartão de teste referenciado em ambiente de produção.

O Gerador de Cartão deste site resolve a primeira camada — números Luhn-válidos para testar a validação de formato do seu formulário, sem depender de nenhum provedor específico. Para testar de verdade a integração com o gateway (aprovação, recusa, 3DS), a documentação oficial do provedor é sempre a fonte certa, porque só ela garante que o número vai disparar o cenário esperado no ambiente de sandbox daquele processador.