Register a scheduled Pix payment
Registers a Pix payment for a future civil date, evaluated in America/Sao_Paulo. The available balance is NOT touched here (RF-07, REG-Art.9 caput): nothing moves until the scheduled date, when the order is sent inside the settlement window IN 513 art. 12 fixes. Non-business days are accepted, because Pix settles every day. Pix Saque (OTHR) and Pix Troco (GSCB) are refused at creation rather than on the scheduled date: REG-Art.11-P prohibits scheduling them, and the rule is knowable now. The payee is photographed at creation AND resolved again on the scheduled date, which is what REG-Art.9§5 requires — a key can be reassigned in between.
Authorizations
JWT bearer token issued by the identity provider.
Headers
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.
1 - 64Body
Payer account UUID.
"019606a1-3b4c-7d8e-9f01-234567890abc"
Amount to settle, in BRL with two decimals. The available balance is NOT touched at creation (RF-07).
"150.00"
How the destination is resolved. DICT reads the directory and requires payeeKey; MANUAL requires destination. QR_CODE is published but not yet accepted on this route.
MANUAL, DICT, QR_CODE "DICT"
Civil settlement date in AAAA-MM-DD, evaluated in America/Sao_Paulo. Never an instant: a date that is still today in UTC can already be yesterday here. Non-business days are accepted -- Pix settles every day.
"2026-09-10"
Always BRL. Present for forward compatibility only.
BRL "BRL"
Free-text memo, at most 140 characters -- the RmtInf ceiling. Stored and returned VERBATIM: markup is not interpreted, escaped or stripped, and escaping belongs to whoever renders it (RF-16).
"Aluguel de setembro"
The payee's account and owner. Required when initiationType is MANUAL.
The Pix key to resolve. Required when initiationType is DICT.
Only IPAY can be scheduled. Pix Saque (OTHR) and Pix Troco (GSCB) are point-in-time operations and REG-Art.11-P prohibits scheduling them, so they are refused at creation rather than on the scheduled date.
IPAY "IPAY"
Response
Created
Payer account.
"019606a1-3b4c-7d8e-9f01-234567890abc"
Amount to settle, in BRL.
"150.00"
Every attempt of the scheduled day, oldest first. Empty before that date, and never null.
The first instant a cancellation is REFUSED. Cancellation is accepted right up to it and refused AT it, and it is strictly before the first window so the two can never overlap.
Always BRL.
"BRL"
The payee as photographed at creation. On the scheduled date this is compared against a fresh directory answer (REG-Art.9§6), which is why it is stored rather than re-resolved.
When the first settlement window of the scheduled date opens (IN 513 art. 12 caput). Photographed at creation.
Schedule identifier.
"019606a1-3b4c-7d8e-9f01-234567890abc"
How the destination was resolved.
MANUAL, DICT, QR_CODE "DICT"
Always IPAY: REG-Art.11-P prohibits scheduling any other purpose.
IPAY "IPAY"
Civil settlement date in AAAA-MM-DD, in America/Sao_Paulo.
"2026-09-10"
The payer as photographed at creation.
Lifecycle status. DISPATCHED_OUTCOME_UNKNOWN is NOT terminal: the order is awaiting reconciliation and will resolve to SETTLED or FAILED. It does NOT assert that the order reached the rail -- it also covers an order that provably did not, whose reserved funds are still being released.
PENDING, EXECUTING, DISPATCHED_OUTCOME_UNKNOWN, AWAITING_RETRY, SETTLED, CANCELLED, FAILED "PENDING"
Present exactly when status is CANCELLED. A cancellation the payer asked for and one the domain performed are deliberately distinguishable.
USER_REQUEST, OWNERSHIP_MISMATCH, KEY_NOT_FOUND, RECURRENCE_CANCELLED The payer's memo, returned exactly as it was stored. Markup is not interpreted here and was not escaped on the way in (RF-16); escaping belongs to whoever renders it.
"Aluguel de setembro"
The transfer that settled this schedule, once it has.

