Get a PIX transaction status
Resolves one transaction’s status. This is the operation that closes the loop after a payment: an outbound SPI order answers 201 or 202 with nothing settled, and the verdict arrives here.
The path id is resolved in three steps, in order: by JDPI request id (idReqJdPi), then — only when the value parses as a UUID — by local transaction id, and finally, when neither matched, by a LIVE lookup at JDPI (§8.4.2). Those branches do not answer the same thing. A local hit returns the status the reconciler last persisted; a live hit is a projection of JD’s own processing status, is the only branch that populates jdpiStatus, and projects JD status 9 to EXECUTED. So a transaction this plugin never persisted can still answer 200 here, and a status read live is not evidence that a local row exists.
Read-only: it neither commits nor releases the held amount — the background reconciler does that on its own tick, so a PENDING answer means “not decided yet”, not “stuck”. Refusals: 400 PIX-0061 when transactionId is empty; and on the live branch, JDPI’s own outcome — 404 PIX-1027 when JD does not know the id either, 503 PIX-1050 when JDPI is unreachable — so a failure here names the dependency instead of hiding behind a generic error.
Authorizations
JWT bearer token issued by the identity provider.
Path Parameters
The transaction id (local UUID or JDPI request id).
"d1f9c0a2-..."
Response
OK
Transaction amount in centavos.
10050
The transaction id (or JDPI tx id on the live branch).
"d1f9c0a2-..."
eTransactionStatus name.
"EXECUTED"
Payment description.
"Invoice 42"
The SPI end-to-end id.
"E1234567890"
JDPI error code (live branch).
""
JDPI error message (live branch).
""
Numeric eTransactionFlow.
2
The JDPI request id.
"REQ-123"
Raw JDPI eProcessingStatus (live branch only).
9
The payee party.
The payer party.

