Effectuate a MED refund debit (THIRD RAIL — moves money)
Effectuates the refund DEBIT at SPI for an accepted refund (JDPI POST /od, contract §2.24): posts a balanced PENDING Midaz double-entry (contested-side debit, clearing credit) and generates the pacs.004. The debit commits on the settlement reconcile poll. The precondition (accepted AND not-yet-effectuated) is checked before any ledger touch: a non-accepted request returns a coded 422, and an already-effectuated one echoes its recorded ids with no second post. A failed request is not safe to retry blindly: its reserve may have landed, and the ledger deduplicates a retry only within 300 seconds, so past that window an operator reconciles the request before it is sent again. An unknown id returns a coded 404. Optional ispb names the direct participant the request acts for: named, the record has to be one that participant is a party to, or the answer is 404 PIX-0147 before anything is read from JDPI or changed; an ISPB this deployment does not act as is 422 PIX-0128 before any record is read; a token confined to one participant has to name it. Optional indirectId names the registered indirect participant the request acts for: named, the refund request has to be over a payment this deployment recorded for that indirect — the rule GET /v1/med/refunds?indirectId= lists by — or the answer is 404 PIX-0147 before anything is read from JDPI or changed; a token confined to one indirect has to name it; a malformed indirectId is 400 PIX-0061.
Authorizations
JWT bearer token issued by the identity provider.
Path Parameters
The accepted refund-request GUID to effectuate.
"d4e5f6a7-b8c9-0123-def4-56789012345a"
Query Parameters
The ISPB of the direct participant this request acts for. OPTIONAL: omit it and the request is answered exactly as before. Named, the record has to be one that participant is a party to - either side of a dispute, the creator of a value recovery, the participant a refund credit was booked for - or the answer is 404 PIX-0147 and nothing is read from JDPI or changed. A record this deployment does not hold is 404 PIX-0147 too when an ispb is named. An ISPB this deployment does not act as is 422 PIX-0128, before any record is read. It is ROUTING DATA you supply, never a credential, and a token confined to one participant has to name it here. Sending it empty (ispb=) reads the same as omitting it.
^[0-9]{8}$"12345678"
The registered indirect participant (UUID) this request acts for. OPTIONAL: omit it and the request is answered exactly as before. Named, the refund request has to be over a payment this deployment recorded for that indirect - the rule GET /v1/med/refunds?indirectId= lists by - or the answer is 404 PIX-0147 and nothing is read from JDPI or changed; a record this deployment does not hold is 404 PIX-0147 too when an indirectId is named. It is ROUTING DATA you supply, never a credential, and a token confined to one indirect has to name it here. Not a valid UUID is 400 PIX-0061. Sending it empty (indirectId=) reads the same as omitting it.
"3f2504e0-4f89-41d3-9a0c-0305e82c3301"
Response
OK
Debit-effectuation FSM code (0=NotStarted, 1=DebitPending, 2=Settled, 3=Failed).
1
Human-readable eff_status label.
"DebitPending"
The Pending Midaz debit posting id (the reconcile commit/cancel reference).
"01HXYZ..."
The JDPI /od request id (the debit-poll handle).
"f1e2d3c4-b5a6-7890-1234-567890abcdef"
The effectuated refund-request GUID.
"d4e5f6a7-b8c9-0123-def4-56789012345a"

