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. It is read-only: nothing is recorded, no money moves, and calling it twice changes nothing.
The checks run in a fixed order and the FIRST one that decides, decides:
- When the payment carries a conciliation id, a QR charge already paid within the last 24 hours is refused as a duplicate (motivo BE17), and so is a payer whose document differs from the one the charge was issued for — 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 WHICHEVER participant block carries THIS participant’s own ISPB — pagador first, then recebedor. If neither block does, the answer is motivo AC03 (account not found).
- That account is then looked up by its account number and its holder document compared: no such account, or a lookup that fails, is AC03; a document that does not match the account’s holder is motivo BE01 (inconsistent data). Otherwise the account is valid.
⚠️ THIS CHECK READS ONLY THIS PARTICIPANT’S OWN CUSTOMER RECORDS. Step 3 is the reason: it selects a block by this participant’s own ISPB, and an INDIRECT participant served by this participant (registered with POST /v1/indirects) has an ISPB of its own, which never equals it. A payment addressed to an indirect participant therefore matches neither block and is answered AC03 here, even though POST /v1/webhooks/cash-ins would register that same credit against that institution’s @pi_{ispb} settlement position. Do NOT read an AC03 from this operation as evidence that a credit to an indirect participant would be refused, and do not use this operation to pre-check indirect destinations.
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 is unavailable — in which case nothing was validated and the call can be retried.
Authorizations
JWT bearer token issued by the identity provider.
Body
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).
0
Payment priority type.
0
Optional value-detail entries.
Response
OK
Validation timestamp (ISO-8601, UTC).
"2026-06-20T10:00:00Z"
Validation result (0=Inválido, 1=Válido).
1
Reason code on an invalid result (BE17/AC03/BE01).
"AC03"
Human-readable reason complement on an invalid result.
"Conta recebedora não encontrada"

