feat: accept payment notifications, once, from a verified sender

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>
This commit is contained in:
Cauê Faleiros
2026-09-22 13:25:08 -03:00
parent 7386469404
commit ccc25a2d5d
12 changed files with 537 additions and 35 deletions

View File

@@ -157,9 +157,18 @@ Ports 8090/8091/8010 were used; 8080 was held by an unrelated preview server.
From the report already sent. These are dated promises, not backlog.
- `[ ]` 1.1 — Mercado Pago transparent checkout, signed and idempotent webhooks.
Requires production credentials + webhook access. Payment must never be created
before the freight amount is final.
- `[~]` 1.1 — Mercado Pago transparent checkout, signed and idempotent webhooks.
**The provider-independent half is built** (2026-09-22): `POST /api/payments/webhook`
verifies a signature before parsing, records every delivery under the provider's
own event id, and applies it in one transaction. A duplicate is a no-op, a
re-sent approval finds the order already there, and an approval whose amount
disagrees with the reviewed quote is refused rather than shipped. Order creation
moved to `app/payments.py` so the webhook and the local checkout cannot drift.
Exercised end to end by `tests/payment_test.py` against a fake signer.
What remains needs the client: a sandbox account, webhook administration, the
event/status mapping and the refund policy. In code it is one adapter supplying
`create`, `verify` and `parse` — nothing in the service changes.
- `[ ]` 1.2 — Real freight quotation. **Blocked on client inputs** (see
`PRODUCTION_INPUTS.md`): source platform, credentials, origin CEP, services,
packaging weight/dimensions per length, subsidy policy.