Get scheduled payment
Returns one scheduled debit of the account named in X-Account-Id, in any status, by the id that an item of List scheduled payments carries. Use it to read one debit again, for example after you cancel it or to follow its settlement, without paging the list.
The response is the same item that the list returns. A debit that settled keeps the status SCHEDULED, and settlement carries the outcome of the latest settlement attempt; it is absent while no attempt exists. Unlike the list, this operation reads the primary database, so a cancellation or a settlement outcome that was just recorded shows on the next call.
A debit that does not exist, was deleted, or belongs to an account other than X-Account-Id answers 404 (PIX-0824) in all three cases. An id that is not a UUID answers 400 (PIX-0015).
Autorizações
JWT bearer token issued by the identity provider.
Cabeçalhos
Non-zero UUID of the payer account selected by the calling PSP. The PSP must authorize its end user for that account before calling this API. A resource outside the selected account returns 404; a read with no records returns an empty page. See the API overview for the complete trust boundary.
^[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}$Parâmetros de caminho
Internal identifier of the scheduled debit, the id an item of GET /v1/payer/scheduled-payments carries, in ANY status. A debit under a different X-Account-Id is answered 404, not 403, so the caller cannot confirm that a debit exists elsewhere.
"0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40"
Resposta
The scheduled debit, in any status.
Amount that will be debited.
Internal identifier of the scheduled debit. Pass it as {scheduled_payment_id} to the cancel operation, or to the operation that reads one debit.
Why the debit exists: AGND a scheduled collection, NTAG a post-due retry, RIFL a same-day resend after a failed attempt.
AGND, NTAG, RIFL Business date the debit settles on, after business-day and local-holiday adjustment. A calendar date (YYYY-MM-DD) with no time of day and no zone.
Lifecycle state of the debit. Only a SCHEDULED debit can be cancelled; the cancellation route answers 409 for any other state. Only SCHEDULED and CANCELLED are produced: a debit that settled keeps reading SCHEDULED, and settlement.outcome carries the payment result.
SCHEDULED, DISPATCHING, SETTLED, FAILED, CANCELLED, RECONCILING Mandate the debit was scheduled under. ABSENT rather than null when the debit carries none, as on a same-day resend (purpose RIFL) answering a failed attempt.
The maximum amount in force AT SCHEDULING TIME, written once and never updated — a later change to the mandate does not reach this debit (Guia v1.2 §6.1). Absent when no ceiling was in force.
BACEN idRec of the recurrence the debit belongs to. ABSENT rather than empty on a debit that belongs to no recurrence.
Payment outcome of the debit, read from its LATEST settlement attempt. ABSENT rather than null while no attempt exists. It is the field that says whether the debit was paid: status keeps the scheduling lifecycle and a debit that settled keeps reading SCHEDULED. The listing reads a replica, so an attempt that has just concluded can still read PROCESSING there for a moment; GET /v1/payer/scheduled-payments/{scheduled_payment_id} reads the primary. The settlement_* events push only negative or pending outcomes; a COMPLETED settlement emits no event and is seen only by re-reading the debit, through the listing or the individual read (or the account's outgoing Pix).
End-to-end identifier (IdFimAFim) the debit settles under, available FROM SCHEDULING, before any settlement attempt. On a debit scheduled from a receiving PSP's payment instruction (pain.013) it is the identifier that PSP minted; it is reused byte for byte on the settlement order (pacs.008), so it equals settlement.endToEndId once an attempt exists. On a debit scheduled from an Open Finance payment initiation it is the endToEndId the initiator sent. Absent only if the debit's origin could not be read.
32"E12345678202610101200b2c3d4e5f6a"
Who the debit pays: name and CPF/CNPJ, the same shape as recurrence.receiver on the mandate surfaces. On a debit scheduled from a payment instruction it is the receiver of the recurrence the debit belongs to; on a debit scheduled from an Open Finance payment initiation, the creditor of the consent. Absent when neither is recorded.