How to recover failed Direct Debit payments with GoCardless

A failed Direct Debit is not a declined card. There is no card to update, the bank answers days after you asked for the money, and the customer can sometimes claim the money back long after it left their account. Recovery on GoCardless follows its own rules, and most of them come from the bank schemes (Bacs, SEPA, ACH and others) rather than from GoCardless itself.

This guide explains why GoCardless payments fail, how retries work, what to do when a mandate is cancelled or expired, and how charge-backs (indemnity claims) are handled. It sticks to GoCardless’s own documentation: the payment events reference, the mandate events reference, the Success+ guide, the help centre articles on payment failures and which failed payments Success+ can retry, and the descriptions in GoCardless’s official API client libraries (all accessed November 2026).

How a Direct Debit payment moves

A GoCardless payment goes through a series of statuses. The API documents these values for status:

Status	Meaning
pending_submission	Created, not yet submitted to the banks
submitted	Submitted to the banks
confirmed	Confirmed as collected
paid_out	Included in a payout to you
failed	The payment failed to be processed
charged_back	The payment has been charged back
cancelled	The payment was cancelled before collection

Two details matter for recovery:

1. Failures arrive after the charge date. GoCardless’s help centre says failure reports usually arrive one working day after the charge date. You find out a little later than with cards, and your dunning should start from the failure event, not from the charge date.
2. A confirmed payment can still fail. The API reference notes that payments can fail after being confirmed if the bank sends the failure message late. Do not treat confirmed as final when you grant or remove access.

Why Direct Debit payments fail

Every failure comes with an event. On payment events, GoCardless sends a details object with:

• cause: GoCardless’s simplified, predictable key for what happened.
• origin: who triggered the event, for example bank, gocardless, api or customer.
• reason_code: when the bank is the origin, the scheme-specific code the bank reported. GoCardless warns that it can be inconsistent between banks, so build your logic on cause, and keep reason_code for investigation.
• description: a human-readable text, which GoCardless says can change without notice.

The causes listed in the payment events reference include insufficient_funds, refer_to_payer, mandate_cancelled, bank_account_closed, invalid_bank_details, direct_debit_not_enabled, bank_declined_payment, payment_stopped and account_blocked_for_any_financial_transaction. They fall into three groups:

Group	Causes	What to do
Not enough money	insufficient_funds, refer_to_payer	Retry, ideally after the customer is likely to have been paid. GoCardless describes refer_to_payer (a Bacs code) as almost always meaning insufficient funds.
Mandate gone	mandate_cancelled	Do not retry. The customer needs a new mandate.
Account problem	bank_account_closed, invalid_bank_details, direct_debit_not_enabled, account_blocked_for_any_financial_transaction	Do not retry. Ask for other bank details or another payment method.
Stopped by the customer or bank	payment_stopped, bank_declined_payment	Contact the customer before trying again. A stopped payment may be a sign they want to leave.

Retries with Success+

GoCardless’s own retry product is Success+. According to the Success+ guide and the help centre:

• It is switched on in the GoCardless dashboard by an admin user, with settings per scheme.
• API integrations must also opt each payment in by sending retry_if_possible: true when creating payments, subscriptions or instalment schedules. The default is false.
• By default it retries up to 3 times within 4 weeks. You can set your own window in calendar days, and retries happen on business days inside it.
• It only retries failures it judges retryable, mainly failures for lack of funds. Cancelled mandates, closed accounts and direct bank refusals are not retried. The list of retryable codes is per scheme.
• For Bacs, the payer must be told the retry date before the payment is taken.
• Each retry is a new payment attempt for billing purposes, so check your GoCardless pricing.

On the failure event, the field will_attempt_retry tells you whether Success+ will retry. When it is false, not_retried_reason explains why: failure_filter_applied (GoCardless expects the retry to fail) or other.

GoCardless’s help centre also notes that not every software partner supports Success+. If your billing runs through a partner app, check there first.

Manual retries through the API

Without Success+, or for a payment it will not retry, you can retry yourself with POST /payments/:id/actions/retry. The API documents three rules:

1. The underlying mandate must be active.
2. A payment can be retried up to 3 times.
3. The call fails with retry_failed if the payment has not failed.

After the call you receive a resubmission_requested event, then the same sequence as a new payment: submitted, followed by confirmed or failed. The retry needs a new charge date, so choose it on purpose. For an insufficient_funds failure, a date just after a common payday in the customer’s country is a reasonable choice. Retrying the next day is usually not.

Tell the customer before you retry

Unlike a card retry, a Direct Debit retry is visible on the customer’s bank statement, and for Bacs GoCardless requires advance notice of the retry date. A good message:

1. Says the payment did not go through, with the amount and the plan.
2. Gives the date of the next attempt.
3. Offers a way to change bank details or pay another way if the account will not have funds.
4. Is sent from an address that a person reads.

Cancelled and expired mandates

A payment needs an active mandate. The API documents these mandate statuses, among others: active, suspended_by_payer, cancelled, expired (expired due to dormancy), failed, consumed and blocked. Watch mandate events (resource_type: mandates) as closely as payment events: a cancelled mandate means every future payment on it will fail.

When a mandate is cancelled by the customer at their bank, a payment against it fails with the cause mandate_cancelled. Do not retry; you need a new mandate. Steps:

1. Find out why. A customer who cancels their Direct Debit at the bank may simply have changed bank, or may want to stop paying. The email should ask, not assume.
2. Send a link to set up a new mandate. On GoCardless, a new mandate is collected through a Billing Request, usually with a hosted Billing Request Flow. Send the customer that link, not a form asking for bank details by email.
3. Recreate the payment on the new mandate once it is active.

GoCardless’s API also has a reinstate action for cancelled or expired mandates (up to 10 times per mandate). It resubmits the mandate to the banks and you then receive submitted, followed by reinstated or failed, up to two working days later. Use it only when you know the mandate should still be valid. When the customer cancelled on purpose, reinstating it without asking is not the right move.

Charge-backs (indemnity claims)

Direct Debit gives customers strong refund rights, and they differ by scheme. GoCardless’s help centre and guides describe them:

Scheme	Customer’s right to claim
Bacs (UK)	Under the Direct Debit Guarantee, GoCardless says there is currently no time limit on indemnity claims.
SEPA Core	No-questions-asked refund within 8 weeks of the debit; up to 13 months for unauthorised payments.
SEPA B2B	No refund for authorised payments; claims for unauthorised payments up to 13 months.

A claimed payment moves to charged_back and the amount is taken back from you. Unlike card disputes, there is usually no evidence process. GoCardless describes a chargeback challenge feature in its help centre, with plan and scheme conditions; check whether it applies to you.

What you can control is what happens before the claim:

• Make cancelling easy. A customer who cannot find how to cancel will stop the Direct Debit at their bank or file a claim. A clear cancel button on your side costs less.
• Send advance notices that are easy to read. A customer who forgot about a renewal is more likely to claim.
• Treat a charge-back as a cancellation signal. Stop future payments on that mandate until you have spoken to the customer.

Webhooks to listen to

A minimal recovery integration on GoCardless follows these events:

Resource	Action	Why
payments	failed	Start recovery; read cause, will_attempt_retry
payments	resubmission_requested, submitted, confirmed	Track a retry
payments	charged_back	Indemnity claim; pause and contact the customer
mandates	cancelled, expired	Ask for a new mandate before the next payment

Remember that one failure can produce several events (for example a mandate cancelled and its pending payments cancelled), so deduplicate on the event ID and group by customer before emailing anyone.

Doing this with NoChurn

NoChurn connects to your GoCardless account, imports customers, mandates, subscriptions and payments, and follows GoCardless webhooks. When a payment fails, it sends AI-written recovery emails that you review, timed for Direct Debit, and when a mandate is cancelled the email links the customer to set up a new one. Collection, retries and Success+ stay with GoCardless, and charge-backs show up on the customer timeline, since Direct Debit claims have no evidence to send. NoChurn also adds cancel flows with a one-click cancel always visible, win-back emails at day 30, 60 and 90 based on the cancel reason, and a churn score. See NoChurn + GoCardless.