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.
Authorizations
JWT bearer token issued by the identity provider.
Path Parameters
EndToEndId of the refund (pacs.004) whose credit status is being consulted.
"D1234567820240101000000000000099"
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 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"
Response
OK
True when the transaction is internal to this direct PSP (both legs on the same participant).
false
Refund code (BE08=MED started by the recipient's PSP, FR01=well-founded suspicion of fraud, MD06=requested by the recipient, SL02=error or disagreement on a Pix Saque or Pix Troco).
"BE08"
EndToEndId of the refund (pacs.004) whose credit is being consulted.
"D1234567820240101000000000000099"
Request situation: -1=erro no processamento, 0=requisicao recebida aguardando processamento, 9=credito efetivado com sucesso.
9
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
When the refund order reached this situation in JDPI (raw JDPI instant).
"2020-01-24T10:30:00.000Z"
Error code, present when stJdPi is -1.
"AB03"
Error-code description, present when stJdPi is -1.
"Liquidacao interrompida"
Refunded amount, in centavos; omitted when JDPI did not return it (Obrg=Nao).
5010

