> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # 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/{authorization_id}/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. ## OpenAPI ````yaml /en/openapi/v3-current/pix-lerian-pixauto.yaml post /payer/scheduled-payments/{scheduled_payment_id}/cancel openapi: 3.1.0 info: contact: name: Lerian Studio url: https://lerian.studio description: >- Pix Automático payer-facing API — deciding an authorization request raised by the receiving end, managing the payer-configurable parameters of a granted mandate, and revoking it (Guia de Implementação do Pix Automático v1.2 §3 and §6). ## Trust boundary This API is **machine-to-machine**. The caller is the client PSP's backend, authenticated with an application token; the token names that application and never one of its customers. The account therefore has to arrive in the request, and it does so in one of two shapes: most routes take it in the **`X-Account-Id`** header, the same header SPI, DICT and COB use for the same job, and the route that CREATES the resource the account belongs to takes `payerAccountId` in the body — `POST /v1/payer/authorization-requests/from-qr`, which opens a pending request for a mandate that does not exist yet. On that route, the account is part of what is being created rather than a scope on an existing resource, and a header beside the body field would be a second source for one value. Either way the value is the caller's **declaration** of which of its own customers it is acting for. **It is not proof that the end user controls that account, and this API cannot make it one.** Authenticating the payer and authorising its own customers against one another is the calling PSP's responsibility. What this end enforces is consistency: an absent header is 400 (PIX-0001) and a malformed account is 400 (PIX-0017 on the header, PIX-0003 in the body), and a resource that exists under a different account than the one named is **404**, not 403: the account is a predicate on the lookup, so this end never learns the resource exists elsewhere and cannot confirm it. Within one lookup, absence and a resource outside the selection get the same answer. license: name: Lerian Studio General License title: Pix Lerian — Pix Automático version: 1.1.0 servers: - url: https://api.example.com/pixauto/v1 description: >- Replace the example host with the URL provided during environment onboarding. security: - BearerAuth: [] tags: - description: >- Authorization requests raised by the receiving end and answered by the payer. A request is answered once. name: Payer Authorization Requests - description: Granted mandates. An authorization is managed for as long as it lives. name: Payer Authorizations - description: >- The payer's forward view of upcoming debits, and the cancellation of one of them. Cancelling a debit leaves the authorization ACTIVE — it stops one charge, not the mandate. The two operations are meant to be used together: the listing is the only place a client receives the scheduled_payment_id the cancellation addresses. name: Payer Scheduled Payments paths: /payer/scheduled-payments/{scheduled_payment_id}/cancel: post: tags: - Payer Scheduled Payments summary: Cancel a single scheduled debit at the payer's request description: >- 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/{authorization_id}/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. operationId: cancelPayerScheduledPayment parameters: - description: >- 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. example: 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d7e in: header name: X-Account-Id required: true schema: format: uuid not: const: 00000000-0000-0000-0000-000000000000 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}$ type: string - description: >- 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. example: payer-decision-20260827-001 in: header name: X-Idempotency required: true schema: maxLength: 64 minLength: 1 type: string - description: >- 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. in: path name: scheduled_payment_id required: true schema: description: >- 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. examples: - 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40 format: uuid type: string responses: '200': content: application/json: example: amount: '149.90' cancelledAt: '2026-09-09T15:00:00Z' counterpartyReason: SLBD endToEndId: E1234567820260810120011a2b3c4d5e scheduledDate: '2026-09-10' scheduledPaymentId: 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40 status: CANCELLED schema: $ref: '#/components/schemas/ScheduledPaymentCancellationResponse' description: >- 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 is 409. A client must therefore treat 200 and 409 as possible answers to a retry it believes is a replay, and must not read either as proof that a competing change happened. '202': content: application/json: example: amount: '149.90' cancelledAt: '2026-09-09T15:00:00Z' counterpartyReason: SLBD endToEndId: E1234567820260810120011a2b3c4d5e scheduledDate: '2026-09-10' scheduledPaymentId: 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40 status: CANCELLED schema: $ref: '#/components/schemas/ScheduledPaymentCancellationResponse' description: >- Scheduled debit cancelled. The camt.055 that tells the counterparty is raised asynchronously from an obligation committed with the cancellation. '400': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- Malformed request, missing required input, invalid field value or invalid idempotency key (PIX-0001, PIX-0002, PIX-0003, PIX-0015, PIX-0017, PIX-0030, plus operation-specific PIX codes). X-Idempotency absent or longer than 64 bytes (PIX-0030). '401': content: application/json: example: code: PIX-0010 message: The request could not be processed due to a client-side error. title: Client Error schema: $ref: '#/components/schemas/Error' description: >- The credentials were refused before the handler ran: absent, invalid or expired. Branch on the 401 status, not the body code, which depends on the refusing layer: the authorization middleware answers the generic client-error code PIX-0010; in multi-tenant deployments the tenant layer may answer a missing, malformed or tenantless token with its own {code,title,message} body, under codes such as MISSING_TOKEN, INVALID_TENANT or UNAUTHORIZED. '403': content: application/json: example: code: PIX-0010 message: The request could not be processed due to a client-side error. title: Client Error schema: $ref: '#/components/schemas/Error' description: >- The caller was refused before the handler ran. Branch on the 403 status, not the body code, which depends on the refusing layer: the authorization middleware answers the generic client-error code PIX-0010 when the caller is not entitled to this resource and action; in multi-tenant deployments the tenant layer may answer with its own {code,title,message} body, such as code 0131 (Service Suspended or Access Denied) when the tenant's access to this service is suspended, purged or denied. '404': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- No scheduled debit with that identifier is reachable by the caller (PIX-0824). '409': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- The debit can no longer be cancelled — the cutoff has passed or it is no longer scheduled (PIX-0825) — or it arose from a post-due retry, which this channel never cancels (PIX-0826). '412': content: application/json: schema: $ref: '#/components/schemas/Error' description: >- X-Idempotency replayed with a divergent request — a different method, URL (including the path parameter) or body (PIX-0031). 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. '415': content: application/json: example: code: PIX-0016 message: >- The request body must be sent with Content-Type: application/json. title: Unsupported Media Type schema: $ref: '#/components/schemas/Error' description: >- The request body carries a media type this operation does not admit (PIX-0016). '500': content: application/json: example: code: PIX-0000 message: >- The server encountered an unexpected error. Please try again later. title: Internal Server Error schema: $ref: '#/components/schemas/Error' description: >- Unexpected internal failure (PIX-0000). Details never travel in the envelope. default: content: application/json: schema: $ref: '#/components/schemas/Error' description: >- Any other error returned by the handler uses the same PIX error envelope. The HTTP status and code identify the concrete failure. In multi-tenant deployments the tenant layer can also refuse before the handler runs -- for example 404 TENANT_NOT_FOUND or 503 SERVICE_UNAVAILABLE -- with its own {code,title,message} body; branch on the HTTP status. components: schemas: ScheduledPaymentCancellationResponse: additionalProperties: false properties: amount: description: >- Amount in BRL that will not be debited, as a decimal string with two places. Money never travels as a number. examples: - '150.00' type: string cancelledAt: description: >- Instant the cancellation took effect on this end, in UTC. It is this end's own clock reading, not a value from the request. examples: - '2026-09-09T15:00:00Z' format: date-time type: string counterpartyReason: description: >- 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. examples: - SLBD type: string endToEndId: description: >- 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. examples: - E1234567820260810120011a2b3c4d5e type: string scheduledDate: description: >- 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. examples: - '2026-09-10' format: date type: string scheduledPaymentId: description: Internal identifier of the scheduled debit that was cancelled. examples: - 0198f3a2-1c4e-7c8b-9d1e-2f3a4b5c6d40 format: uuid type: string status: description: >- Lifecycle status the debit now holds. Always CANCELLED on a 202; it is returned rather than assumed so the caller reads a fact. examples: - CANCELLED type: string required: - scheduledPaymentId - endToEndId - status - counterpartyReason - scheduledDate - amount - cancelledAt type: object Error: additionalProperties: false properties: code: examples: - PIX-0142 type: string fields: additionalProperties: type: string type: object headers: additionalProperties: type: string type: object message: examples: - claim_id is required type: string paths: additionalProperties: type: string type: object query_params: additionalProperties: type: string type: object raw: $ref: '#/components/schemas/RawError' title: examples: - Invalid Claim Request type: string required: - code - title - message type: object RawError: additionalProperties: false properties: message: examples: - upstream provider returned 503 type: string status: format: int64 type: integer required: - status - message type: object securitySchemes: BearerAuth: bearerFormat: JWT description: JWT bearer token issued by the identity provider. scheme: bearer type: http ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.