13-status-matrix

Publiquei um SDK Python para um gateway de pagamentos. A página de que mais me orgulho é uma tabela de estado.

13-status-matrix

Publiquei um SDK Python para um gateway de pagamentos. A página de que mais me orgulho é uma tabela de estado.

A maioria dos READMEs diz "production ready" — uma palavra de marketing.
O meu mostra uma matriz, linha a linha:

→ Unit — respx-mocked, a verificar o body exacto que vai para o fio
→ Sandbox — integração contra o ambiente sandbox do gateway
→ Prod — dinheiro real, data exacta (2026-05-31), verificado de volta via webhook

Seis métodos de pagamento. Duas gerações de API. Três autenticações.
Cada linha conquistada à parte.

A tabela também conta a verdade incómoda:

→ Apple Pay sandbox devolve 400 na validação do merchant (reportado, ainda não corrigido do outro lado).
→ Reembolso Multibanco liquida assíncrono num webhook separado, horas depois.
→ Pay By Link expira em silêncio — sem webhook, só uma 404 genérica.

Cada uma destas é agora um tipo normalizado ou uma quirk documentada no SDK.

Se o teu README tem um selo "Production Ready ✅" e nada mais, estás a pedir aos utilizadores que confiem num autocolante.
Uma matriz dá-lhes algo que podem auditar.

Qual é a coisa mais honesta nos teus docs?

Matriz de estado em direto: eupago.bilouro.com

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

#OpenSource #Python #SoftwareArchitecture

Comentários