Skip to main content
POST

Autorizações

Authorization
string
header
obrigatório

JWT bearer token issued by the identity provider.

Cabeçalhos

X-Idempotency
string
obrigatório

REQUIRED. Client-supplied replay key, at most 64 bytes. A request without it is refused with PIX-0030 @ 400 before the handler runs. Replaying the same key with a divergent method, URL or body is PIX-0031 @ 412.

Required string length: 1 - 64

Corpo

application/json

The scanned QR Code content, with the journey-3 or journey-4 payment outcome when there is one.

payerAccountId
string<uuid>
obrigatório

The payer account the authorization would apply to, selected by the calling PSP among its own customers. A value that is not a non-zero UUID is refused with 400. This is the one route of the payer surface that carries the account in the BODY rather than the X-Account-Id header: a QR journey creates a mandate that does not exist yet, so the account is part of what is being created.

Pattern: ^[0-9A-Fa-f]{8}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{4}-[0-9A-Fa-f]{12}$
Exemplo:

"0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d7e"

qrCodePayload
string
obrigatório

Raw EMV content read from the QR Code. The app decodes it, detects the journey and reads the recurrence payload from the location it carries.

Maximum string length: 4096
Exemplo:

"00020126180014br.gov.bcb.pix5204000053039865802BR5913Fulano de Tal6008BRASILIA62070503***80740014br.gov.bcb.pix2552pix.example.com/rec/2353c790eefb11eaadc10242ac1200026304F2DA"

immediatePayment
object

How the payment-or-scheduling flow of the charge ended. REQUIRED on journey 3, where Guia v1.2 §3.4 forbids proceeding with the authorization before the settlement flow completed. On journey 4 it is optional, and a FAILED result is refused: §3.5 forbids the offer that would follow an error. Ignored on journey 2, which carries no charge.

Resposta

Recovered duplicate. The same X-Idempotency header was replayed with an identical request, so the FIRST call's response body is returned verbatim and nothing was reprocessed. A replay answers 200 whatever the original status was, so a client tells a replay from a fresh execution by the status code alone. NOTE: this 200 depends on the replay cache. The gate DEGRADES when the cache is unavailable -- it still demands the header, and each route still refuses a second effect through its own durable guard -- but a repeat is then answered by that guard rather than replayed, which for most routes is 409. A client must therefore treat 409 as a possible answer to a retry it believes is a replay, and must not read it as proof that a competing change happened.

authorizationRequestId
string
obrigatório

Local payer-side request identifier created for the QR journey. Use this exact value on the decision route; do not forward it as a BACEN idSolicRec.

Exemplo:

"SC12345678202608276bca619e690"

expiresAt
string<date-time>
obrigatório
Exemplo:

"2026-09-26T19:18:38Z"

journey
enum<string>
obrigatório

The journey detected from the QR Code content.

Opções disponíveis:
JOURNEY_2,
JOURNEY_3,
JOURNEY_4
Exemplo:

"JOURNEY_2"

recurrenceId
string
obrigatório
Exemplo:

"RR12345678202608276bca619e690"

status
enum<string>
obrigatório

The pending status the request was born in.

Opções disponíveis:
RECEIVED
Exemplo:

"RECEIVED"