ccc25a2d5d
There was no inbound payment path at all: a button called a fake synchronously and wrote an order. A real provider does the opposite — it charges, then tells us, repeatedly, out of order, and sometimes long afterwards. POST /api/payments/webhook verifies the signature before the body is parsed, so an unsigned or tampered delivery is refused and recorded without touching an order. Verified deliveries are stored under the provider's own event id with a unique constraint, and applied inside the same transaction that marks them processed: a repeat is a no-op, a crash is retried rather than half-applied. An approval whose amount disagrees with the reviewed quote does not become an order. Underpayment would ship artwork nobody paid for, and overpayment means something a person should look at. Order creation moved to app/payments.py so the webhook and the local development checkout share one implementation and cannot drift. That also closes 3.5: the charge happens inside the transaction that persists the order, rather than before it. The adapter contract is create/verify/parse. FakePayment implements it with a real HMAC scheme so the whole path is exercised now, by tests/payment_test.py: unsigned, tampered, underpaid, duplicate, re-sent, unknown reference, and non-approved statuses. Connecting Mercado Pago is one adapter; no service code changes. PAYMENT_WEBHOOK_SECRET is optional in production on purpose. Required would break the next Portainer render, and a guessable default would be worse than either: with no secret configured the adapter verifies nothing and therefore accepts nothing, which is the right state until a provider is connected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Documents
| File | What it is |
|---|---|
reuniao-2026-09-09-anotacoes.pdf |
Meeting notes that set the business direction: the bottleneck, the 24h goal, the automation and payment decisions. Still the record of what was asked for. |
roadmap-cliente.pdf |
The client-facing plan, as last sent. Generated by tools/generate_dtf_report.py; regenerate rather than edit. |
historico/ |
The original specification and prototype documents. Background only — they describe a model this system does not implement. |
Current engineering documents live at the repository root: CONTEXT.md for how
the system works, ROADMAP.md for what is outstanding, LOCAL_SETUP.md to run
it, PORTAINER.md to deploy it, SECURITY_REPORT.md and PRODUCTION_INPUTS.md
for the security position and the decisions still owed by the client.
Weekly client reports are deliverables, not repository content. They are produced for a specific week and are deliberately not versioned here.