Confirmar um desembolso já pago ao trabalhador
Registra o fato durável informado pelo cliente de que o trabalhador já recebeu o desembolso. Não é uma operação Dataprev: não usa credenciais do trilho, não consome limite governamental e não consulta produtos a jusante para avaliar a plausibilidade do pagamento.
Confirmações órfãs são aceitas, inclusive para contratos que esta implantação nunca registrou localmente. Um contrato também pode ter mais de um pagamento. A identidade é (tenant, numero_contrato, payment_reference); outro pagamento com referência diferente é um novo fato, não um conflito.
X-Idempotency é obrigatório, opaco, tem de 1 a 128 bytes e não é normalizado. Chaves que diferem em um byte são distintas; não há alias X-Idempotency-Key.
| caso | estado | X-Idempotency-Replayed |
|---|---|---|
| primeira aceitação | 202 | ausente |
| mesma chave, mesma solicitação, atendida pelo cache de transporte | 202, bytes idênticos | true |
| mesma chave, mesma solicitação, atendida pela autoridade durável | 202, bytes idênticos | ausente |
| mesma chave, solicitação divergente | 422 — nunca o corpo anterior | conforme o middleware compartilhado |
| nova chave, mesmo pagamento | 202, o mesmo corpo | ausente |
| nova chave, mesma referência de pagamento, dinheiro diferente | 409 | o que quer que o middleware compartilhado tenha escrito |
PostgreSQL é a autoridade para cada registro. O cache de idempotência de transporte é apenas um acelerador de melhor esforço. Se falhar antes da solicitação ser decidida ou depois da confirmação, a resposta continua durável; a única diferença é a ausência do cabeçalho de repetição. Uma falha de cache não transforma um pagamento registrado em 503. Uma interrupção compartilhada do Redis é diferente e pode ser recusada antes pelo limitador de taxa do tenant.
Autorizações
JWT bearer token issued by the identity provider.
Cabeçalhos
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"
Parâmetros de caminho
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"
Corpo
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"
Resposta
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"

