What to do when a GoCardless mandate is cancelled

On GoCardless, every payment hangs on a mandate: the customer’s authorisation to debit their account. When the mandate is cancelled, nothing else works. Pending payments stop, subscriptions on it end, and no retry can help. It is the most important event to handle well in a Direct Debit business, and also the one where an automated “please update your details” email is most likely to be wrong.

This guide covers why mandates end, what happens to the subscriptions and payments on them, how to read the cause, and how to get a new mandate when the customer wants to keep paying. It sticks to GoCardless’s documentation: the mandate events reference, subscription events reference, the developer guide Responding to mandate events and the help centre article on mandate statuses (all accessed November 2026). GoCardless’s documentation site was not reachable from our research environment, so we also checked field and endpoint descriptions against GoCardless’s official API client libraries (for example gocardless-pro-ruby), which are generated from the same API schema. For the payment side of recovery, see how to recover failed Direct Debit payments with GoCardless.

Mandate statuses

GoCardless documents these mandate statuses:

Status	Meaning
pending_customer_approval	Not yet signed by a second signatory
pending_submission	Not yet submitted to the customer’s bank
submitted	Submitted, not yet processed
active	Set up by the customer’s bank; payments can be taken
suspended_by_payer	Suspended by the payer
failed	Could not be created
cancelled	Cancelled
expired	Expired due to dormancy
consumed	Used and not reusable (only for schemes authorised per payment)
blocked	Blocked; payments cannot be created

Only active mandates can be charged, and a manual payment retry requires an active mandate. Each mandate also has a next_possible_charge_date, which matters when you set up a replacement and want to know when you can collect.

Why a mandate gets cancelled

The cancelled event comes with details.cause, details.origin and, when the bank is the origin, details.reason_code. Use cause for your logic. GoCardless warns that reason_code is scheme-specific and can be inconsistent between banks.

GoCardless’s developer guide lists several causes for a cancelled mandate, including:

• bank_account_closed: the customer’s bank account was closed.
• invalid_bank_details: the bank details are not valid.
• mandate_cancelled: the mandate was cancelled.

On the last one, GoCardless’s pages are not consistent with each other. The mandate events API reference describes mandate_cancelled as a mandate cancelled by the customer or their bank, while the older developer guide uses it for cancellations made through the dashboard or API and describes a bank-side cancellation by the customer differently. Do not rely on cause alone to tell “the customer cancelled at their bank” from “we cancelled it”: read origin too (bank, api, gocardless, customer and so on). An api origin means your own system, or an app you connected, did it.

An expired mandate is different: GoCardless expires mandates due to dormancy. Nobody decided to stop; the mandate simply was not used.

What happens to payments and subscriptions

A cancelled mandate takes things with it:

• Pending payments. GoCardless’s API reference for the cancel endpoint says cancelling a mandate cancels all associated cancellable payments. A payment that is already submitted to the banks can still be collected or fail on its own.
• Subscriptions. GoCardless’s subscription events reference shows subscriptions being cancelled because their mandate was cancelled, with causes such as mandate_cancelled, bank_account_closed and invalid_bank_details.
• Later payments. A payment against a cancelled mandate fails with the cause mandate_cancelled. Retrying it is not possible: retries require an active mandate.

So one cancellation produces several events: the mandate, the subscription, and possibly payments. Group them by customer before sending any email, or the customer may get three messages about one thing.

Decide what the cancellation means

Before writing to the customer, sort the cancellation into one of three cases:

Case	Signals	Right response
Customer changed or closed their account	bank_account_closed, or a cancellation followed by the customer saying they moved banks	Ask for new bank details through a new mandate
Customer wants to stop paying	Cancelled at the bank, often near a renewal; no reply	Treat it as a cancellation: confirm it, ask why, end access cleanly
Your side cancelled it	origin is api or the dashboard	Check your own logs before telling the customer anything

GoCardless’s developer guide is clear on one point: only cancel a mandate yourself if the customer has explicitly asked for it.

Setting up a new mandate

When the customer wants to continue:

1. Email once, plainly. Say the Direct Debit has been cancelled, that no further payments can be taken on it, and that they can set up a new one in a minute if they want to keep it. GoCardless’s guide recommends notifying the customer and prompting them to set up a new mandate if needed.
2. Link to a hosted flow. On GoCardless, new mandates are collected with a Billing Request and its hosted Billing Request Flow. Send that link; never ask for bank details by email.
3. Wait for active. A new mandate goes through pending_submission and submitted before active. If it fails (for example because the new account does not support Direct Debit), you receive a failed event; ask the customer to try another account.
4. Recreate what was lost. Create a new subscription on the new mandate, and a payment for any amount still owed, on or after the mandate’s next_possible_charge_date.
5. Tell the customer what will be collected and when, before it happens.

What about reinstating?

GoCardless’s API has a reinstate action for cancelled or expired mandates. It resubmits the mandate to the banks; you then receive resubmission_requested, submitted, and reinstated or failed up to two working days later, and a mandate can be resubmitted up to 10 times. Use it only when you know the mandate should still be valid, for example after an error on your side. When the customer cancelled at their bank, reinstating it without their agreement goes against their decision, and is likely to lead to a failure or a claim.

Expired mandates

An expired mandate is the easiest to recover, because nobody objected. If you plan to charge a customer whose mandate has been idle (an annual plan, or a customer who paused), check the mandate status before the charge date. If it has expired, ask the customer to set up a new mandate in advance, rather than discovering it through a failed payment.

A checklist

• Your webhook handler processes mandate events, not only payment events.
• Events are grouped by customer before any email goes out.
• cause and origin are both stored and read.
• Cancellations by your own system are recognised and not sent to customers as “your bank cancelled”.
• The new-mandate email links to a hosted Billing Request Flow.
• Subscriptions are recreated only after the new mandate is active.
• Mandates are checked before infrequent charges.

Doing this with NoChurn

GoCardless keeps the mandates, the collection and the bank details. NoChurn imports customers, mandates, subscriptions and payments, follows GoCardless webhooks, and reads mandate status (active, cancelled, expired). When a mandate is cancelled, NoChurn’s AI-written recovery email, which you review, links the customer to set up a new one; when the customer wants to stop instead, the cancel flow with a one-click cancel always visible and win-back emails at day 30, 60 and 90 take over. See NoChurn + GoCardless.