Decode a scanned PIX QR code
Decodes a scanned PIX QR-code payload, normalizing static / immediate-dynamic / cobv sub-types into one null-safe response. The payer document is sourced from accountId’s CRM alias for the JDPI decode header (PI-PayerId).
Which of this deployment’s direct participants acts is decided by ispb, by exactly the rule an order’s payerIspb follows: this deployment may act as several direct participants, each with its own customers and its own JDPI credential, and naming none is answerable only while there is one answer. Omit it while this deployment acts as a single participant; once it acts as several, omitting it is 422 PIX-0127 and naming one it is not is 422 PIX-0128. When the account named on the request cannot be used by that participant, the request is refused before the operation acts and the answer names the account: 422 PIX-0137 when it is held in a ledger that is not configured for Pix, 422 PIX-0138 when its record does not say which ledger holds it, and 422 PIX-0139 when its record names a different institution. It selects the JDPI credential the decode goes out on and nothing else.
Paying through an INDIRECT participant: send indirectId, the same one the payment order will carry, and the payer’s CPF/CNPJ in X-Payer-Document. The plugin then generates the endToEndId under that indirect’s ISPB - the institution the payment originates from - and sends it to JD on the decode (PI-EndToEndId); the response returns it and the order must carry it unchanged.
Autorizaciones
JWT bearer token issued by the identity provider.
Encabezados
The CPF/CNPJ of the indirect participant's customer who scans and pays, as the indirect declares it, mask allowed. Only with indirectId, and required there unless the legacy accountId is sent instead: an indirect keeps its customers in its own core, so this plugin reads no record of them and sends this document to JD as the payer (PI-PayerId), canonical (digits, and the letters of an alphanumeric CNPJ). Refused 400 PIX-0061 without indirectId, together with accountId, or when it is not a CPF of 11 digits or a CNPJ of 14 characters.
"52998224725"
Cuerpo
The scanned EMV QR-code payload to decode.
"00020126..."
The Midaz ledger account id of the scanning payer, a customer of the asking direct participant (sources the PI-PayerId document). REQUIRED on a direct decode (absent or blank is 400 PIX-0061). With indirectId it is DEPRECATED in favour of the X-Payer-Document header: an indirect keeps its customers in its own core. accountId is still accepted there, unchanged, when the direct participant's own credential sends the request, and refused 400 PIX-0061 when an Access Manager partner is behind the request. Sending it together with X-Payer-Document is 400 PIX-0061.
"019a1b2c-3d4e-7f60-8a9b-0c1d2e3f4a5b"
Optional identifier (UUID) of the indirect participant the scanning payer pays through - send the SAME indirectId the payment order will carry. The plugin then generates the endToEndId under that indirect's ISPB, the institution the payment originates from, and sends it to JD on the decode; the response returns it, and the order must carry it unchanged. Without it JD generates the endToEndId under the direct participant's ISPB. Omit it for a payment the direct participant pays. Validated before JD is called, exactly as the order validates it: 404 PIX-0095 unknown to this tenant, 422 PIX-0100 not ACTIVE, 422 PIX-0111 while this deployment's indirect-participants feature is off. The decode then acts as the direct participant the indirect is mounted on: omit ispb, or send that participant's ISPB; any other is 422 PIX-0102. A token confined to one indirect has to name it here.
"3f2504e0-4f89-41d3-9a0c-0305e82c3301"
The ISPB of the direct participant this decode asks as. This deployment may act as SEVERAL direct SPI participants - one ISPB each, each with its own customers and its own JDPI credential - and this field is the only thing on the request that says which of them acts. OPTIONAL while it acts as a single participant: omit it and that one acts. REQUIRED once it acts as several - omitted is 422 PIX-0127, and an ISPB this deployment does not act as is 422 PIX-0128. It is ROUTING DATA you supply and guarantee, exactly like payerIspb on a transaction: never a credential, never read from a header or a path, and it never widens what your token can reach. It selects the JDPI credential the decode goes out on and nothing else - the decoded charge belongs to the payee, not to you. Send it as an absent key, not an empty string; an empty value is refused 400 PIX-0061.
^[0-9A-Z]{8}$"12345678"
Respuesta
OK
The decoded amount in centavos.
10050
The decoded recipient identity.
The decoded QR type (STATIC or DYNAMIC; cobv folds onto DYNAMIC).
"DYNAMIC"
The Pix Troco amount in centavos (troco only).
0
Recipient city (cidade; §8.3.3 Obrg=Sim on every block).
"Sao Paulo"
When the dynamic charge was created (§8.3.3 Obrg=Sim).
"2020-01-20T12:29:15.043Z"
Additional data (dadosAdicionais).
"Invoice 42"
Due date (cobv/static optional).
"2026-12-31"
The SPI end-to-end id.
"E1234567890"
Whether the QR carries a Pix Saque leg.
false
Whether the QR carries a Pix Troco leg.
false
The saque/troco PSS participant ISPB (a v5.5.0 string; leading zeros are significant).
"00360305"
The recipient PIX key.
"recipient@bank.com"
When the payer captured the QR, i.e. the moment of this decode (dtHrApresentacao; §8.3.3 Obrg=Sim).
"2020-01-23T10:21:34.107Z"
Charge revision counter (revisao). Always present on a DYNAMIC decode, including at its initial value 0; absent on a STATIC one, whose §8.3.3 block declares no revisao.
0
Conciliation id (idConciliacaoRecebedor), to copy verbatim into POST /v1/transactions. A STATIC QR may carry a txId JDPI §8.4.1 refuses on the payment (any character outside [a-zA-Z0-9], e.g. TX-001); POST /v1/transactions refuses such a txId 400 PIX-0061.
"TX001"

