19-production-discoveries

Três coisas que o sandbox não me disse sobre o meu SDK de pagamentos.

Sandbox passou. Todos os testes verdes. Fiz deploy para produção e em uma semana a produção contou-me três coisas que o sandbox nunca tinha contado.

1. "Canceled" com um L.
Os docs oficiais diziam que o enum de estado era CANCELLED — escrita britânica. O sandbox devolvia sempre exactamente isso. Em produção, o gateway às vezes devolve "Canceled" (escrita US, um L só). O meu SDK agora normaliza ambos para um único tipo CANCELLED. Sem isso, código downstream com enum strict crashava num estado perfeitamente válido.

2. Reembolsos Multibanco liquidam assíncronos.
No sandbox chamas refund e recebes "refunded" na hora. Em produção os reembolsos Multibanco liquidam horas depois — às vezes no dia seguinte — via um webhook separado com method "RB:PT" ligado à transacção original. Não dá para fazer await client.refund() e assumir que está. O estado move-se noutro canal.

3. Pay By Link expira em silêncio.
A URL Pay By Link é gerada com expiration. Em produção, quando expira, não há webhook a dizer-te. O link passa a uma 404 genérica. O teu cliente vê "página não encontrada" — esse é o modo de falha user-facing. O SDK agora segue a expiration ele próprio e emite um evento lógico de "expired" quando o prazo passa, para o merchant poder re-enviar.

Cada uma destas é uma frase silenciosa no changelog do SDK. Cada uma custou tempo real a descobrir. Nenhuma estava na especificação do sandbox.

O sandbox é um modelo do gateway. O gateway é um modelo da realidade. A realidade ganha.

O que é que a produção te ensinou que o sandbox não tinha ensinado?

Repo: github.com/bilouro/eupago-python

P.S. Novo post tech toda a quarta-feira aqui no LinkedIn.

#OpenSource #Python #SoftwareArchitecture