Validate a receiving account synchronously
Pre-checks a receiving account before a payment is sent, and answers the section 9.3.1 envelope . JDPI calls it BEFORE settlement, on behalf of the payer’s PSP, so that a payment that would fail is not sent.
EVERY VALIDATION OUTCOME IS HTTP 200, including a rejection: resultado carries the verdict and motivo the reason. Do not branch on the HTTP status here — a 200 with resultado inválido is a refusal, and treating it as success is the mistake this shape invites. No money moves; the one thing recorded is step 7’s hold. Asking again for the same order does not change its verdict, but each re-ask that holds the charge records the hold again, so a late re-ask extends that order’s hold.
The checks run in a fixed order and the FIRST one that decides, decides:
- When the payment carries a conciliation id and is not a static QR (tpIniciacao 2 or 10: a static QR is no charge, takes any number of payments and skips this step), a blank recebedor.cpfCnpj is refused with motivo CH11 and a blank recebedor.ispb with motivo DS04; a QR charge already paid to the same recebedor within the last 24 hours is refused as a duplicate (motivo DUPL); a charge another payment order to the same recebedor at the receiving PSP, by CPF/CNPJ or by account, holds (step 7) is refused with motivo DUPL too, until that order’s credit lands, up to 24 hours; and a payer whose document differs from the one the charge was issued for is refused BE17 — but only when that charge was created demanding the payer be validated.
- A pagador.ispb identifying Bacen (99999) passes unconditionally.
- The account to check is the one on the participant block naming an ISPB the client’s catalog serves — recebedor first, the pagador only when the recebedor is not served. If neither block does, and the client runs indirect participants, a recebedor.ispb naming an indirect registered with POST /v1/indirects is answered from that registration alone: ACTIVE is valid (then step 6 still applies), CLOSED is motivo AC07 and any other state motivo AC06, and steps 4, 5 and the credit screen are skipped. On a devolução whose recebedor does not decide, the pagador.ispb is asked the same way. Anything else is motivo AC03 (account not found). On a payment whose pagador alone is served, an indirect recebedor is still answered from its registration first; only one the registry does not know falls back to the pagador block.
- That account is then looked up by its branch and account number and its holder document compared: no such account is AC03; a lookup that could NOT BE COMPLETED is a 500, never a verdict — an unreadable record establishes nothing about the account, and AC03 would tell the payer’s PSP that a live account is absent; a document that does not match the account’s holder is motivo BE01 (inconsistent data).
- When step 3 chose the recebedor block, that account, by branch and number as the credit resolves it, is then read in the ledger: closed is motivo AC07, blocked or a default balance refusing credits is motivo AC06, and an account the ledger does not hold is AC03; a ledger that could NOT BE READ is a 500, never a verdict. Coordinates naming no account or several, and every other account status, leave the account valid.
- A devolução (creditoDevolucao) that account would accept is refused with motivo AM09 when its valor exceeds what is left to return of the payment endToEndIdOriginal names: that payment’s amount less every devolução already settled against it, booked or still awaiting its payment’s settlement here. A payment this participant never made is not measured, and a balance that could NOT BE READ is a 500, never a verdict.
- A payment step 1 checked that passes every check holds that charge for that recebedor’s CPF/CNPJ and for that receiving account, at the receiving PSP. Of two orders validated at once, on this route or the asynchronous one, exactly one holds it and the other is answered DUPL.
⚠️ AN INDIRECT PARTICIPANT’S CUSTOMER IS VALIDATED BY THE INDIRECT’S REGISTRATION, NOT BY ITS ACCOUNT. Its customers live in the indirect’s own core, which this check never reads: a valid answer says the credit will be registered against that institution’s @pi_{ispb} settlement position, exactly as POST /v1/webhooks/cash-ins does, not that the account exists there. A credit to an account the indirect does not hold lands on its @pi and is returned by the indirect. The registry is read, uncached, when the client’s catalog does not serve the recebedor (on a devolução, only when it serves neither block), so a suspension or closure is refused at the next validation and a participant of the client always wins over an indirect registered on the same ISPB. With indirect participants turned off the registry decides nothing: a request no block of the client serves is AC03 as before, and a payment whose pagador the client serves is judged on that block. A registry, or the indirect-participants setting itself, that could NOT BE READ is a 500, never a verdict.
Refusals, as opposed to verdicts, are only transport-level: 400 PIX-0061 when the body fails schema validation at the edge, and 500 when a record this check has to read or write is unavailable — in which case nothing was validated and the call can be retried.
Autorizações
JWT bearer token issued by the identity provider.
Corpo
Operation timestamp (ISO-8601).
"2026-06-20T10:00:00Z"
The payer participant block (ISPB drives Bacen detection).
The receiver participant block.
Amount in reais (a JSON number).
10.5
Optional return-credit block.
Optional payment-order credit block.
Finality (eFinality).
0
Recipient conciliation id.
"CONC-V"
Free-text inter-client info.
"note"
Saque/troco PSS participant ISPB (a v5.5.0 string).
"12345678"
Agent modality (eModalityAgent).
0
Payment priority.
0
Initiation type (eStartupType). A static QR (2, or 10 by proximity) is no charge: its idConciliacaoRecebedor is never checked for a second payment.
0
Payment priority type.
0
Optional value-detail entries.
Resposta
OK
Validation timestamp (aaaa-mm-ddTHH:mm:ss.sssZ, UTC).
"2026-06-20T10:00:00.000Z"
Validation result (0=Inválido, 1=Válido).
1
Reason code on an invalid result (DUPL/CH11/DS04/BE17/AC03/AC06/AC07/BE01/AM09).
"AC03"
Human-readable reason complement on an invalid result.
"Conta recebedora não encontrada"