Como você testaria um fluxo de checkout e pagamento de ponta a ponta?

Cubra o caminho feliz e depois os riscos específicos de dinheiro: cartões recusados e parcialmente autorizados, timeouts em que a cobrança dá certo mas a resposta se perde, envios duplicados, reembolsos totais e parciais, moeda e arredondamento, interação de imposto com desconto, e estoque mudando no meio do checkout. Use os cartões de teste do sandbox do provedor, e verifique o que o backend registrou em vez de confiar na tela de confirmação.

O caminho feliz leva dez minutos; tudo que é valioso está nos modos de falha, porque este é o fluxo em que um bug custa dinheiro diretamente. O caso que eu sempre testo primeiro é a transação interrompida: o provedor autoriza a cobrança, e aí a resposta nunca volta, dá timeout, ou o usuário fecha a aba. O pedido existe? O cliente foi cobrado sem nada para mostrar? Esse é o pior resultado do sistema inteiro e precisa de lógica de reconciliação, não de esperança. Junto disso, clicar duas vezes em enviar, e voltar e enviar de novo, o que deveria ser idempotente em vez de cobrar duas vezes. Depois as respostas específicas do provedor pelos cartões de teste do sandbox deles: recusas, saldo insuficiente, cartão expirado e um cartão que dispara autenticação adicional, porque esse caminho tem o próprio redirect e as próprias formas de quebrar. Depois a aritmética do dinheiro: moedas com número diferente de casas decimais, arredondamento num desconto percentual, imposto aplicado antes ou depois do desconto, e um cupom maior que o total do pedido. Também estoque chegando a zero enquanto o cliente está parado na tela de pagamento. E eu verifico contra o banco de dados e o painel do provedor, nunca a página de confirmação.