Get the credit status of a MED refund order
Returns the CREDIT-side situation of a refund order by its pacs.004 endToEndIdDevolucao, read live from JDPI (JDPI credito-devolucao/, §8.5.4). stJdPiProc here is the CREDIT domain, DISTINCT from the debit poll’s despite the shared field name (§4.5). Moves no money and persists nothing — the credit itself is settled by the inbound §9.3.3 webhook, never by this read. 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 credit has to be booked against a payment this deployment recorded for that indirect, or the answer is 404 PIX-0147 before anything is read from JDPI; a token confined to one indirect has to name it; a malformed indirectId is 400 PIX-0061.
Parámetros de ruta
Parámetros de consulta
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-9A-Z]{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 credit has to be booked against a payment this deployment recorded for that indirect - the payment's own indirectId, as GET /v1/transactions?indirectId= reads it - 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"
Respuesta
OK
CREDIT-side processing situation: 0=request received, awaiting processing, 1=credit validated, awaiting settlement by the SGCT, 2=credit validation sent to SPI, 5=no final answer from SPI, 7=refund refused by SPI, 8=refund refused by JDPI, 9=credit settled. A DISTINCT domain from the debit poll's stJdPiProc despite the shared field name.
9

