Arquitectando Sistemas Multi-Gateway Resilientes

Num cenário de e-commerce de alto volume, depender de um único gateway de pagamento é um risco incomensurável. Se o provedor principal sofrer uma quebra (downtime), os seus utilizadores ficam impossibilitados de comprar, e a empresa perde receita ao segundo.

A solução óbvia é um sistema Multi-Gateway, mas a sua implementação esconde complexidades severas.

O Desafio do Contexto Trocado

Imagine que o Utilizador A tenta pagar com o Gateway 1. Ocorre uma falha. Ele então troca para o Gateway 2. Se a sua arquitetura não estiver preparada, o estado do pedido (Order) pode ser subscrito com referências erradas. Pior, se o Gateway 1 responder tardiamente dizendo "Afinal recebi o dinheiro", o seu sistema pode perder esse débito porque a referência (transaction_id) foi sobrescrita pela tentativa do Gateway 2.

Preservar Tentativas Históricas

O segredo para um sistema robusto não é ter uma coluna payment_reference na tabela de pedidos, mas sim uma tabela isolada de payment_attempts (Tentativas de Pagamento).

Cada vez que um utilizador inicia um fluxo de pagamento, gera-se uma tentativa única. Se ele trocar de Gateway, gera-se uma nova tentativa. Desta forma:

1. Preserva-se o histórico: Se um webhook atrasado chegar do Gateway 1, o sistema consegue relacionar com a attempt antiga e alocar os fundos como saldo na carteira (wallet) ou reembolsar.
2. Previne perdas financeiras: Evitam-se os débitos "fantasmas" onde o cliente prova que o dinheiro saiu da sua conta, mas o sistema já não sabe a que provedor a referência pertence.

Arquiteturas modernas não devem assumir que os pagamentos são um evento linear e síncrono. Eles são máquinas de estado assíncronas que exigem um histórico blindado.