Os cartões de teste do Stripe existem para que uma integração possa percorrer o caminho completo de uma cobrança sem tocar em dinheiro de verdade. Em vez de depender de sorte ou de um cartão pessoal, o desenvolvedor escolhe um número cujo resultado é conhecido de antemão: aprovado, recusado por um motivo específico ou pendente de autenticação.
Por que um provedor publica esses números
Um serviço de pagamentos só pode ser considerado pronto quando o time conhece o comportamento dele em situações ruins. Estruturar isso com dados reais é inviável: nenhum banco vai emitir um cartão que sempre recusa por saldo insuficiente só para você testar a tela de erro.
A solução é o provedor manter um ambiente de teste isolado, com números reservados que produzem resultados previsíveis. Ao usar um deles, a cobrança percorre o mesmo fluxo de uma transação verdadeira — criação da intenção de pagamento, confirmação, resposta — mas termina em uma simulação.
Esse ambiente também é o lugar para exercitar falhas de rede, respostas duplicadas e reenvios, sem que o resultado tenha consequência financeira.
Há ainda uma razão de documentação. Ao publicar números fixos, o provedor dá aos times de suporte uma linguagem comum: quando alguém relata que o pagamento não passa, é possível reproduzir exatamente o mesmo cenário e comparar o resultado. Sem isso, cada investigação começa do zero, com dados que ninguém consegue repetir depois.
A documentação do provedor destaca um cartão de sucesso universal, aquele que começa com quatro e alterna os dígitos quatro e dois até completar dezesseis posições — o número 4242 4242 4242 4242. Aceita qualquer data de validade futura e qualquer código de segurança de três dígitos, e sempre devolve aprovação.
Esse é o dado que aparece em praticamente todo tutorial, e por um bom motivo: ele permite validar a instalação da biblioteca e a configuração das chaves antes de qualquer coisa mais elaborada. Use-o para provar que o caminho feliz funciona, e depois passe para os casos difíceis.
Como provocar recusas específicas
O grupo mais interessante é o dos números que sempre falham por um motivo determinado. Cada um devolve um código de recusa diferente, como cartão recusado pelo emissor, saldo insuficiente, validade incorreta ou código de segurança inválido.
Isso permite escrever testes que verificam a mensagem exibida na tela, a decisão de permitir nova tentativa e o registro do motivo no histórico do pedido. Um fluxo de checkout que mostra “algo deu errado” para qualquer recusa está desperdiçando a informação que o provedor devolveu.
Vale testar também os casos em que a recusa vem acompanhada de uma instrução, como pedir que o cliente entre em contato com o banco. A redação dessas mensagens costuma ser decidida por quem nunca viu a resposta real do provedor.
Outro ponto que merece verificação é a etapa em que a falha ocorreu. Um mesmo código pode significar coisas diferentes conforme o momento — na autorização, na captura ou na confirmação final. Registrar a etapa junto do código evita interpretações erradas quando alguém for analisar o histórico de pedidos recusados.
Os cenários de autenticação 3D Secure
O terceiro grupo serve para exercitar a autenticação adicional exigida por algumas bandeiras e regiões. Os números desse conjunto levam a uma tela de verificação em que se pode escolher o resultado: autorizado, recusado ou abandonado no meio.
Esse é o cenário que mais quebra integrações na prática, porque envolve uma navegação para fora da página de checkout e um retorno que precisa ser tratado com cuidado. O cliente que fecha a tela de verificação é diferente do cliente que tem o pagamento recusado, e o pedido precisa terminar em um estado consistente nos dois casos.
Os cartões de teste funcionam em produção?
Não. Eles existem apenas no ambiente de teste do provedor e são recusados no ambiente real. Também não é bom conselho tentar adaptá-los: além de não funcionarem, usar números fabricados em um sistema de produção é justamente o que as regras do setor de cartões proíbem, como explica a página sobre dados de teste PCI DSS.
Um cuidado prático: mantenha as chaves dos dois ambientes bem separadas e confirme, no início de cada bateria de testes, contra qual endereço o seu código está apontando. Confundir as chaves é uma falha de configuração comum e com consequências desagradáveis.
Onde está a lista atualizada de cartões?
A lista oficial muda com o tempo: números são acrescentados, removidos e reorganizados conforme o provedor evolui. Em vez de copiar uma tabela que envelhece, consulte a fonte: a página de testes da documentação oficial do Stripe reúne os cartões atuais, os códigos de recusa e os cenários de autenticação.
Completando os dados do formulário
Os cartões de teste cobrem o número, mas um formulário de checkout pede mais campos, e alguns deles exigem coerência — a bandeira detectada precisa combinar com o comprimento e com o formato do código de segurança. Para gerar esses conjuntos, use o gerador de cartão virtual desta página. Os resultados são estruturalmente válidos, mas nunca foram emitidos por nenhuma instituição e não funcionam em nenhum gateway real.
Para quem desenvolve: montando o roteiro
Um roteiro que cobre o essencial sem virar uma lista infinita:
- Uma cobrança aprovada, para provar a instalação.
- Uma recusa genérica e uma recusa com código específico, para comparar as mensagens.
- Uma autenticação concluída, uma recusada e uma abandonada.
- Um reenvio do mesmo pedido, para verificar que a cobrança não é duplicada.
- Uma cobrança em moeda e valor diferentes, para checar formatação e arredondamento.
- Ao final, um reembolso total e um parcial.
Compare os casos escolhidos com a matriz sugerida no checklist de teste de formulário de pagamento e registre, junto de cada caso, qual número foi usado.
Próximos passos
Se você está começando agora, valide primeiro uma aprovação e depois acrescente os cenários de recusa e autenticação. Se a dúvida é como escolher números fora do ambiente do provedor, veja os números de cartão de teste por bandeira.