Um checklist de teste de formulário de pagamento é o que impede que o checkout seja publicado tendo sido testado apenas no caminho feliz. Os campos são poucos, mas os estados possíveis são muitos, e é nas ramificações — recusa, reenvio, reembolso parcial — que aparecem os defeitos que o cliente encontra no pior momento possível.
O que rodar antes de publicar
A lista abaixo está organizada como uma sequência executável. Ela não substitui os testes automatizados, mas serve como roteiro para garantir que nenhum cenário ficou de fora.
- Campos obrigatórios vazios, com espaços e com caracteres inesperados.
- Número de cartão com dígito trocado, comprimento a menos e comprimento a mais.
- Data de validade no mês corrente, no mês anterior e em um ano distante.
- Código de segurança com dígitos a menos, dígitos a mais e letras.
- Colagem de texto com espaços nas pontas e caracteres invisíveis.
- Preenchimento automático do navegador, em especial com dados antigos.
- Envio do formulário com o mouse e com o teclado, e a ordem de foco entre os campos.
- Comportamento em tela pequena, com teclado numérico aberto.
Cada item deve ter um resultado esperado escrito antes da execução.
Recusas, nova tentativa e mensagens
A recusa é o cenário mais frequente em produção e o menos testado. Vale exercitá-la por vários motivos diferentes — número inválido, validade vencida, saldo insuficiente, autenticação não concluída — e conferir o que a tela mostra em cada caso.
Os pontos que costumam falhar são previsíveis:
- A mensagem é genérica e não diz ao cliente o que fazer a seguir.
- O formulário é limpo por inteiro, obrigando a redigitar tudo.
- O botão de nova tentativa permanece bloqueado depois de um erro.
- A tentativa anterior aparece como pedido concluído no histórico.
- Duas tentativas seguidas geram duas cobranças em vez de uma.
Esse último item é o mais caro. A verificação de que o reenvio não duplica a cobrança precisa estar no roteiro, não na esperança.
Reembolso, cancelamento e estados intermediários
Pedidos de pagamento não vivem apenas em dois estados. Existem autorizações pendentes, valores capturados em parte, estornos parciais e cancelamentos que chegam depois da cobrança. A interface precisa saber exibir todos eles.
Um roteiro mínimo costuma incluir:
- Reembolso total, conferindo o valor devolvido e o texto exibido ao cliente.
- Reembolso parcial, que costuma deixar o pedido em um estado que a tela não prevê.
- Cancelamento antes da captura, que deve liberar o valor reservado.
- Reembolso repetido do mesmo pedido, que precisa ser recusado.
- Estorno que falha no provedor, para verificar se o pedido não fica marcado como devolvido.
Cada um desses casos tem uma consequência direta no suporte ao cliente, e nenhum deles aparece em um teste de caminho feliz.
Quantas vezes o botão pode ser clicado?
Essa é uma das perguntas mais úteis de todo o checklist. Um clique duplo, um toque repetido em conexão lenta ou um reenvio automático depois de um tempo limite podem disparar mais de uma cobrança para o mesmo pedido.
O teste é simples de descrever: envie o formulário duas vezes o mais rápido que conseguir e verifique quantas cobranças chegaram ao provedor. O comportamento correto é uma única cobrança, com a segunda requisição tratada como repetição da primeira.
Para que isso funcione, o sistema precisa de uma chave que identifique a tentativa e do registro do resultado anterior. É um requisito de arquitetura, e não um detalhe de interface.
Como testar tudo isso sem dados reais?
Não é possível cobrir esses cenários com um cartão verdadeiro, e nem seria correto tentar. As regras do setor de cartões proíbem o uso de dados reais de portadores em ambientes de teste, como explica a página sobre dados de teste PCI DSS.
O caminho usual combina duas coisas: números sintéticos, que passam na validação de formato sem pertencer a ninguém, e o ambiente de teste do provedor de pagamento, que permite simular aprovação, recusa e autenticação. O texto sobre cartões de teste do Stripe mostra como esse ambiente se organiza.
Roteiro de teste no gerador
Para montar a massa de dados, o gerador de cartão virtual desta página produz número, validade, código de segurança e titular de exemplo, na bandeira e na quantidade que você escolher. Os conjuntos saem estruturalmente válidos, mas nunca foram emitidos por nenhuma instituição: existem para preencher formulários em teste e não funcionam em nenhum gateway real.
Vale gerar conjuntos diferentes para cada caso do roteiro, em vez de reaproveitar um só número em tudo. Um caso que falha e outro que passa ficam mais fáceis de comparar quando os dados de entrada são distintos.
Para quem desenvolve: matriz de estados e idempotência
Antes de considerar o checkout pronto, vale confirmar alguns pontos estruturais:
- A cobrança tem um identificador único que o cliente envia junto da tentativa, e o servidor sabe recusar repetições.
- A validação roda também no servidor, e não apenas no navegador.
- Os campos seguem o comprimento e o formato próprios de cada bandeira.
- A validade é comparada considerando o fim do mês, e não o dia da data impressa.
- Os estados do pedido estão documentados em uma tabela, e cada transição tem pelo menos um teste.
- Nenhum dado sensível é gravado em registro de log durante os testes.
Se o seu checkout também coleta endereço, vale revisar os campos de entrega com o checklist de teste de formulário de endereço internacional, que trata dos mesmos problemas de formato e normalização em outro conjunto de campos.
Próximos passos
Rode o roteiro acima em uma sessão única antes de publicar, com os dados gerados de antemão, e registre o resultado de cada item. Se algum cenário não puder ser testado, trate isso como um defeito do ambiente, e não como uma exceção aceitável. Para começar agora, monte os conjuntos de teste no gerador de cartão virtual e organize a matriz por bandeira seguindo o texto sobre números de cartão de teste por bandeira.