Cancel a single scheduled debit at the payer's request
Cancels ONE scheduled debit at the payer’s request (Guia v1.2 §4.1).
The AUTHORIZATION IS NOT AFFECTED. This stops a single charge; the mandate keeps billing and future cycles are still scheduled. To end the mandate itself — which cascades over every debit scheduled under it — use POST /v1/payer/authorizations//cancel instead. The two are told apart on the wire by the camt.055 reason: SLBD here, CCLD there.
THE WINDOW CLOSES AT MIDNIGHT of the settlement date, in America/Sao_Paulo: the payer may cancel up to 23:59:59 of the day before, and a request at or after 00:00 is refused with PIX-0825. That boundary is where the 00:00-08:00 settlement window opens, so a cancellation admitted past it would race the debit it is trying to stop.
A DEBIT ARISING FROM A POST-DUE RETRY (purpose NTAG) CANNOT BE CANCELLED HERE, at any hour, and is refused with PIX-0826 (Guia v1.2 §5.1): the retry is a collection the payer already authorized, and ending the mandate is the payer’s remedy. The receiving side may still cancel that same charge.
The cancellation is communicated to the receiving PSP by camt.055, raised asynchronously from an obligation written in the same transaction as the cancellation. The payer is notified of the cancellation unconditionally, including when scheduling notifications are disabled.
Authorizations
JWT bearer token issued by the identity provider.
Headers
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}$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. X-Account-Id is part of the compared request too, so replaying one account's key under another account is divergent rather than a replay.
1 - 64Path Parameters
Internal identifier of the scheduled debit being cancelled. A debit that exists under a DIFFERENT account than X-Account-Id names is answered 404, not 403: the lookup carries the account as a predicate, so this end never learns that a debit exists elsewhere and cannot confirm it.
"0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40"
Response
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.
Amount in BRL that will not be debited, as a decimal string with two places. Money never travels as a number.
"150.00"
Instant the cancellation took effect on this end, in UTC. It is this end's own clock reading, not a value from the request.
"2026-09-09T15:00:00Z"
camt.055 motivoDoCancelamento sent to the receiving PSP. Always SLBD on this route — the paying user ended ONE debit. It is never CCLD, which would state that the authorization itself fell.
"SLBD"
BACEN end-to-end identifier of the charge. It is the key the receiving PSP reconciles the camt.055 against; the internal identifier above names nothing the other institution can match.
"E1234567820260810120011a2b3c4d5e"
Business date the debit would have settled on, as a YYYY-MM-DD calendar date. It is a date and not an instant: there is no time of day and no time zone to interpret.
"2026-09-10"
Internal identifier of the scheduled debit that was cancelled.
"0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40"
Lifecycle status the debit now holds. Always CANCELLED on a 202; it is returned rather than assumed so the caller reads a fact.
"CANCELLED"