Confirm a disbursement already paid to the worker
Records the gateway’s own durable fact that a client bank ALREADY paid a worker. This is NOT a Dataprev operation: no rail credential is used, no government boundary is crossed, and Dataprev publishes no disbursement-confirmation operation to proxy. The gateway records what the client asserted; it asks no downstream product whether the payment is plausible.
It accepts ORPHAN confirmations — money for a contract this deployment never registered locally — and a contract may be disbursed in MORE THAN ONE payment. The identity of a confirmation is (tenant, numero_contrato, payment_reference), so a second payment under a different reference on the same contract is a first acceptance with its own fact, never a conflict.
X-Idempotency is mandatory, opaque, 1..128 bytes, and never defaulted. Two keys differing in one byte are two keys, and there is no X-Idempotency-Key alias.
| Case | Status | X-Idempotency-Replayed |
|---|---|---|
| First acceptance | 202 | absent |
| Same key, same request, served from the transport cache | 202, the identical bytes | true |
| Same key, same request, served from the durable authority | 202, the identical bytes | absent |
| Same key, divergent request | 422 — never the earlier body | whatever the shared middleware wrote |
| New key, same payment | 202, the same body | absent |
| New key, same payment reference, different money | 409 | whatever the shared middleware wrote |
PostgreSQL is the authority on every row. The transport idempotency cache is a best-effort accelerator over it, in BOTH directions: whether that cache fails before the request is decided or after the confirmation is already committed, the answer is the durable one and the only difference on the wire is that the replay header is absent. A cache failure never turns a recorded payment into a 503. That is a different failure from a shared Redis outage, which the tenant rate limiter refuses first.
Authorizations
JWT bearer token issued by the identity provider.
Headers
Mandatory opaque replay key, 1..128 bytes of valid UTF-8, preserved byte for byte. There is no default, no X-Idempotency-Key alias, no case folding and no normalization: two keys differing in one byte are two keys.
1 - 128"idem-desembolso-0001"
Path Parameters
The rail contract number the money was paid against (Manual 004 §2.2.2 p.18: Texto, 15). Exact, control-free UTF-8, bounded in BYTES: no trimming and no case folding. Nothing looks it up — an orphan confirmation for a contract this deployment never registered is first-class.
1 - 15"99999999999AN1"
Body
The BRL amount already paid to the worker, as a canonical positive decimal string matching ^[1-9][0-9]*.[0-9]{2}$ (at most 13 bytes). A string, never a JSON number: money never passes through a float.
13"2000.00"
When the money was paid, strict RFC 3339 UTC with a literal Z (2026-08-01T12:00:00Z). Exactly one spelling per instant: a +00:00 offset, a lowercase z, fractional seconds or a missing zone are refused, never normalized.
20"2026-08-01T12:00:00Z"
The client's opaque payment reference — a Pix EndToEndId, a TED protocol number, an internal settlement id. Valid UTF-8, 1..256 bytes, preserved byte for byte with no trimming, case folding or normalization.
256"E32074986202608011200A1B2C3D4E5F"
Response
The confirmation is durably recorded. A replay of the same payment — under the same key or a new one — answers with the identical body.
The confirmed amount, echoed verbatim.
"2000.00"
The gateway's identity for this immutable confirmation.
"1f5b9c26-6f5a-4f77-9c1c-5d1c0f0a9b21"
When the gateway durably recorded the confirmation, strict RFC 3339 UTC.
"2026-08-01T12:00:05Z"
The rail contract number the confirmation was addressed to, echoed from the path.
"99999999999AN1"
When the money was paid, echoed verbatim.
"2026-08-01T12:00:00Z"
The client's payment reference, echoed verbatim.
"E32074986202608011200A1B2C3D4E5F"

