Integração de pagamentos: um plano de testes antes do lançamento

Desenhe o percurso da encomenda

Escolha uma compra representativa, como uma reserva de serviço com preço fixo. Identifique a criação da encomenda, o cálculo do valor, a abertura do checkout e a confirmação final. Determine qual desses passos pertence à aplicação, à OrsunPay ou ao prestador. Uma fronteira explícita evita que duas equipas esperem que a outra resolva o mesmo problema.

Mantenha identificadores distintos para encomenda e tentativa de pagamento. Um cliente que repete a operação por falta de resposta não está necessariamente a fazer uma segunda compra. O teste deve mostrar todas as tentativas ligadas ao pedido inicial. Defina também o que acontece quando o cliente altera o serviço depois de abrir a página de pagamento.

Ferramentas de desenvolvimento

Verifique valores e permissões no servidor

O servidor deve confirmar montante, moeda e estado da encomenda antes de iniciar uma operação. Não confie exclusivamente no valor enviado pelo navegador. Teste alterações deliberadas aos parâmetros, acesso a uma encomenda de outra conta e reutilização de um pedido antigo. O resultado esperado deve ser uma recusa controlada, sem revelar dados internos.

Inclua preços com casas decimais, descontos e alterações de quantidade relevantes para o negócio. Compare o valor apresentado com o transmitido ao prestador e o registado na aplicação. Um arredondamento diferente pode impedir a correspondência automática. Registe as referências necessárias para investigar o problema, mas evite copiar dados de cartão ou segredos para os registos técnicos.

Ligações a prestadores

Teste a ausência de resposta

Um tempo de espera excedido não demonstra que o prestador ignorou a operação. Simule a perda de resposta depois da aceitação do pedido e verifique se a aplicação consulta ou recupera a tentativa existente. Criar imediatamente uma nova operação independente pode produzir uma situação que a equipa terá de resolver manualmente mais tarde.

O comprador precisa de uma mensagem de verificação, não de uma afirmação precipitada de falha. Defina quem acompanha os casos pendentes e quando passam para intervenção humana. Esse prazo é uma regra operacional da empresa, não uma garantia inventada de processamento. A documentação de pagamentos e webhooks da Stripe ajuda a compreender a natureza assíncrona destes resultados.

Verifique confirmações e repetições

Envie eventos válidos, inválidos, repetidos e fora da sequência prevista. O sistema deve verificar a autenticidade segundo o protocolo da origem, localizar a operação correta e aplicar apenas transições permitidas. Um evento repetido não pode entregar duas vezes o mesmo acesso, enviar duas encomendas ou voltar a descontar existências.

Separe confirmação do pagamento e execução comercial. Se o envio do comprovativo falhar, a recuperação deve repetir essa tarefa, não a cobrança. Guarde um estado que permita distinguir evento recebido, evento aplicado e encomenda executada. Esta separação torna o teste observável e ajuda o apoio ao cliente a explicar uma demora sem alterar incorretamente o resultado financeiro.

Ensaiar com a equipa também é testar

Peça a alguém do apoio ao cliente que resolva um caso usando apenas a documentação e os dados disponíveis. Se a pessoa precisa de perguntar ao programador onde está o identificador, o processo ainda tem uma dependência escondida. A operação diária deve permitir localizar uma compra sem pedir ao cliente segredos ou dados excessivos.

• Feche o navegador antes do regresso ao site.
• Repita o pedido com a mesma intenção comercial.
• Interrompa temporariamente o tratamento de eventos.
• Confirme que uma entrega falhada pode ser recuperada separadamente.

Defina critérios de lançamento e recuperação

O lançamento deve ter critérios concretos: valores corretos, eventos verificados, ausência de execução duplicada e responsáveis pelos estados pendentes. Mantenha uma forma de suspender novas tentativas sem perder a receção dos resultados já iniciados. Reverter a interface não elimina as operações que continuam em processamento no prestador.

A OrsunPay é software de orquestração com contratos e contas de prestadores próprios do comerciante e cobrança de software separada. Não pressupõe encaminhamento automático por custo nem cascata entre prestadores. Confirme também as limitações linguísticas do checkout atual, em inglês e ucraniano, e valide o percurso real antes de o apresentar a clientes de língua portuguesa.

Fontes

• Stripe — Pagamentos
• Stripe — Notificações webhook