Credit a parked received Pix
Credits a received Pix still PENDING with nothing in the ledger, typically because the receiving balance did not accept credits (pendingReason BALANCE_NOT_RECEIVING in GET /v1/transactions), until 23 hours after it arrived, or until 7 days less an hour once the ledger refused its credit because the balance did not accept credits or the ledger did not know its account or accounting route. A redelivery from JD in that window credits it by itself once the balance accepts credits; this is the client operator’s way to do it now, the other being POST /v1/parked-credits//return. A received return of a Pix this participant sent (isRefund true) is credited the same way, under the return’s own end-to-end id, on the accounting route its return code books (refund or MED), and only by this action: Pix does not return a return. Its first credit, a redelivery and an operator action never post at the same time: one that finds the Pix held posts nothing, and a redelivery is sent again by JD.
The ledger is asked first. A credit it already holds for this Pix is adopted and nothing is posted; otherwise the credit is posted once, under the Pix’s own end-to-end id kept by the ledger for 7 days, on the account and route group the Pix was received on. It answers 200 with the transaction EXECUTED. Sending it again answers 409 PIX-0153: a credited Pix is not parked any more. A later redelivery from JD is acknowledged without a second credit.
Refusals change nothing: 404 PIX-0152 when no received Pix has this id; 409 PIX-0153 when it is credited, returned or failed, or its first credit, a return of it or an earlier credit of it started less than two minutes ago and may still be running; 409 PIX-0159 past that window, the ledger’s replay window; 422 PIX-0154 for a Pix or a return received through the other core, or a Pix recorded without its initiation type; 409 PIX-0155 when the ledger holds a posting for it that is not a settled credit; 409 PIX-0156 when the receiving balance still does not accept credits (allow it in the ledger, then send this again, or return the Pix); 409 PIX-0157 when the ledger does not know the account or accounting route the credit names (return the Pix, or fix the ledger and send this again); on either, a received return is never returned: fix the ledger and send this again; 409 PIX-0105 when the ledger declares no inbound accounting route; and the ledger’s own answer when it refuses the posting. A ledger that does not answer whether the credit landed answers 5xx and keeps the Pix reserved for this action: send it again once two minutes have passed, and no return can start meanwhile. A credit the ledger never answered may still post, so that Pix is never returned by POST /v1/parked-credits//return (409 PIX-0160); this action still credits it, at most once under the same key.
Autorizações
JWT bearer token issued by the identity provider.
Parâmetros de caminho
The received Pix's transaction id (local UUID), as GET /v1/transactions lists it.
"019fb9b6-7593-7667-abe9-3b087192747b"
Resposta
OK
Transaction amount in centavos.
10050
The created transaction id.
"d1f9c0a2-..."
eTransactionStatus name.
"PENDING"
Payment description.
"Invoice 42"
The SPI end-to-end id.
"E1234567890"
Numeric eTransactionFlow (2=CASH_OUT,3=INTRA_PSP).
2
The JDPI request id (external CASH_OUT).
"REQ-123"
Numeric eTransactionPriority.
1

