GoCardless doesn't really have a "dunning" feature — not in the way Stripe, Chargebee, or Recurly do. It has a failure-reason taxonomy, a manual retry button capped at three attempts, an optional paid retry engine called Success+, and four categories of fixed system emails. Here is exactly how those pieces fit together, what each one actually does when a Direct Debit collection fails, and where the real gaps are for a subscription business that wants an actual recovery sequence.
Every other processor guide on this site starts from the same mechanical assumption: a card is charged, the network responds in seconds, and a decline code tells you why. None of that applies to GoCardless. It moves money through Direct Debit — Bacs in the UK, SEPA across the Eurozone, and six other bank-debit schemes worldwide — which means every payment is authorized in advance through a mandate, submitted to a banking system days ahead of the charge date, and reported back on a schedule the banks control, not GoCardless. That mechanical difference is the reason "dunning" means something narrower here than it does anywhere else in this series.
This guide focuses specifically on GoCardless's own native tools — not on billing-platform dunning layered on top of it, which we already cover in depth. If you want the fuller mandate lifecycle, the eight schemes, and a side-by-side of every recovery option, our GoCardless recovery options comparison picks up where this one leaves off; this article stays narrowly on what happens inside GoCardless itself.
Key takeaways
- GoCardless does not retry failed payments automatically by default — merchants click a manual "Retry payment" button, capped at three resubmissions total.
- A failed collection is reported back through the banking system, not an instant decline — a Bacs failure typically surfaces through an ARUDD file days after the charge date.
- GoCardless sends payer notification emails in four fixed categories, but none of them add up to a configurable, multi-step dunning sequence.
- Success+, GoCardless's paid automatic-retry add-on, only acts on insufficient-funds failures — every other failure reason still needs a human or a separate tool.
Card decline vs Direct Debit failure: why the mechanics are different
A card charge is authorize-and-capture in one synchronous round trip: the card network responds in seconds, and whatever comes back — approved, or a specific decline code — is known before the customer has even closed the checkout tab. A GoCardless Direct Debit collection is a completely different mechanical object. The customer authorizes a standing mandate once; every collection after that is submitted to the banking system ahead of the actual charge date and confirmed, or rejected, on the bank's own timetable — not GoCardless's, and not in real time.
That has a direct, practical consequence for anyone trying to build a recovery process around it: the signal you would normally react to instantly — a decline — simply does not exist on the same timescale for Direct Debit. GoCardless can tell you a payment is pending or submitted, but whether it actually succeeded or failed is information GoCardless itself doesn't have until the receiving bank reports back, which is the structural reason every section below eventually comes back to timing.
The same logic shows up as an ACH return code in the US
If GoCardless is collecting through its US ACH scheme specifically, a failure literally arrives as a standard NACHA return code — see our ACH return codes guide for what each one means. The underlying mechanism is the same across every other GoCardless scheme too, just reported through a different file format: a bank-to-bank return, not an instant decline.
Why a GoCardless payment actually fails
Open a failed payment in the GoCardless dashboard and it carries one of a small set of documented reasons — not a processor-specific decline code, since there is no card network involved at all. The four that matter for a recovery decision:
Insufficient fundsSoft · retryBy far the most common reason — there wasn't enough money in the account on the day GoCardless attempted to collect.
What to do: This is the one category a retry can realistically fix, and the only failure type GoCardless's own Success+ add-on is allowed to act on automatically.
Instruction cancelledHard · needs new cardThe customer, or their bank, cancelled the Direct Debit mandate itself — not just this one payment.
What to do: Retrying does nothing here. The customer needs to go through mandate setup again before another collection can be submitted.
No instructionHard · needs new cardGoCardless tried to collect against a mandate that isn't actually active — often because the original setup never fully completed or verified with the bank.
What to do: Treat it the same as a cancelled mandate: route the customer back through mandate setup, not toward a retry.
Account closedHard · needs new cardThe receiving bank account no longer exists in a state that can accept a Direct Debit collection.
What to do: There's nothing to retry against the old account — the customer needs to authorize a new mandate against a different one.
Underneath those four, each scheme's own bank reason codes roll up to one of these categories — Bacs' ARUDD code 0, SEPA's AM04, ACH's R01, and the rest of the scheme-specific list we cover in our GoCardless recovery options guide. The category is what matters for a recovery decision, and it's worth repeating because it's the single most common mistake in this whole workflow: only "insufficient funds" is ever worth retrying. Retrying a cancelled or dead mandate just spends one of your three resubmissions on something that was never going to work.
Building recovery automation on GoCardless's webhooks
If you're building your own automation directly against GoCardless's API rather than relying on the dashboard, the mechanism to build against is webhooks, not polling. GoCardless fires a webhook the moment its own system knows something — the multi-day delay covered throughout this guide is entirely upstream, in how long it takes a bank to report a failure back to GoCardless in the first place, not a lag in GoCardless's own webhook delivery once it actually has the answer.
Each webhook event names a resource and an action together — a payments event with action failed is the retry-eligible signal covered above; a mandates event with action cancelled or failedis the "stop retrying, start a new mandate" signal. Building a recovery flow that only ever listens to payments.failedand never subscribes to mandate-level events is the single most common automation mistake here — it means a customer whose mandate was cancelled weeks ago keeps getting silently re-attempted against a mandate that no longer exists, instead of being routed to a fresh authorization link.
- payments — failed: the collection itself was refused; check the reason before deciding whether to retry.
- payments — cancelled: the payment was pulled before it reached the bank at all — usually a merchant or API-side action, not a bank refusal.
- mandates — cancelled: the customer or their bank ended the standing authorization; nothing can collect against it again.
- mandates — failed: a new mandate never passed verification in the first place; it was never usable.
- subscriptions — cancelled: the recurring plan itself stopped — distinct from any individual payment or the mandate underneath it.
None of this replaces reading GoCardless's own webhook and event-type reference before building against it — the exact set of actions has grown over time, and this list is illustrative, not exhaustive. The pattern is what matters: resource and action together, always, because automation that reacts to a payments event with the same logic it uses for a mandates event will eventually retry something that was never retryable.
One practical wrinkle worth planning for: webhook events aren't guaranteed to arrive in the same order they happened, and GoCardless can redeliver an event you've already processed. Treat every webhook handler as idempotent — key off the event's own id, not just the resource id, before acting on it — and store the mandate's current status rather than assuming the last event you saw is still accurate by the time a human reviews it. A recovery workflow that trusts stale mandate state ends up making exactly the mistake described above: retrying against a mandate that already moved on.
How merchants find out — and how long it takes
A card decline reaches you before the customer has even closed the checkout tab. A GoCardless failure takes days — sometimes the better part of a week — because the receiving bank has to actually process the instruction and report back through the scheme's own reporting cycle, not through GoCardless directly.
GoCardless's own published Bacs timings put confirmation of a routine recurring payment at around four working days after submission, and a first payment on a brand-new mandate closer to six — the extra cycle covers the mandate itself clearing before the payment can. A failure surfaces through what the Bacs scheme calls an ARUDD file, arriving on that same multi-day timetable rather than as an instant push notification. We cover the full mandate lifecycle, and how it differs by scheme, in our guide to the 8 Direct Debit schemes GoCardless supports.
Build around the slower number, not the fastest one
GoCardless's own support documentation describes a standard failure notification landing about one working day after the charge date in the simplest case — but that is the floor, not the norm, once you are on a scheme with its own reporting cycle like Bacs or SEPA. Build your recovery timing around the slower number for whichever scheme you actually collect on, not the best case.
The mechanical point holds across every scheme GoCardless supports, not just Bacs and SEPA: a recovery process copied wholesale from card-decline handling will consistently notice a Direct Debit failure too late, because it was built around a signal — an instant decline — that doesn't exist here at all.
What GoCardless retries automatically — and what it doesn't
By default, GoCardless does not retry a failed payment at all. Nothing resubmits on its own — a team member has to open the failed payment record and click Retry payment, which resubmits it with a new charge date. That can be done up to three times per payment; after the third failed resubmission, GoCardless will not retry it again, and the only way to collect is to create an entirely new payment against the mandate.
✓ Pros
- +No extra cost — manual retry is built into every GoCardless plan.
- +A team member can factor in context Success+ can't — a known payday, a support conversation, a genuine one-off dispute.
- +Works for any failure type, not just insufficient funds — though only insufficient-funds failures are actually worth spending a resubmission on.
✕ Cons
- –Nothing happens unless someone manually finds the failed payment and clicks the button.
- –Capped at three resubmissions total, with no scheduling logic behind when those three attempts happen.
- –Doesn't scale past a handful of failures a month before it becomes a real ops burden.
Success+ removes the manual step for one specific case. It is GoCardless's paid add-on that automatically retries a payment that failed for insufficient funds, using a model to pick the single best day within a configurable window rather than retrying on a fixed schedule or waiting for a human to notice. GoCardless reports an average recovery rate around 70% on the payments it retries — but the scope is narrow by design: cancelled mandates, closed accounts, and every other failure reason covered earlier are explicitly outside what Success+ touches. We break down exactly which scheme-specific codes qualify in our GoCardless alternatives and recovery options guide.
The notification emails GoCardless sends — and why they aren't a dunning sequence
GoCardless does send emails automatically when something changes on a payer's account, with no configuration required to turn the sending on. They fall into four fixed categories: Authorisations (a new Direct Debit mandate has been set up), Payments (an individual collection succeeded, failed, or was cancelled), Subscriptions (a new recurring plan has started), and Customer Details(something about the stored account or contact information changed). Every payer gets these by default and can only turn specific categories off from their own settings — a merchant doesn't compose, approve, or see the copy before it goes out.
Merchants on GoCardless's Advanced or Pro plans get one extra lever: custom notifications, which let you apply your own branding and choose how much of the payer's overall notification experience runs through GoCardless versus your own systems. That is real customization of the container — logo, look, where the touchpoint sits in the customer journey — not of the underlying logic. Nothing in GoCardless's notification settings lets you branch the copy by failure reason, escalate tone over a multi-day sequence, or personalize a subject line per customer.
| What it sends | GoCardless payer notifications | A dunning sequence |
|---|---|---|
| Trigger | A fixed system event — mandate set up, payment failed, subscription started, details changed | A failed payment, timed against the retry schedule |
| Copy | Fixed template; branding only on Advanced/Pro plans | Written or personalized per failure reason |
| Timing | One email per event, as it happens | Multiple touchpoints escalating over several days |
| Audience logic | None — every payer on a plan gets the same template | Can branch by customer, failure reason, or plan value |
None of that is a flaw in GoCardless specifically — it was never trying to be a recovery-email product, and it says so implicitly by gating even basic branding behind its two highest plan tiers. But it does mean the "we already email customers about failed payments" assumption doesn't hold up the way it might for a processor with a genuinely configurable dunning cycle built in, like the ones we cover in Recurly's Dunning Cycle or these dunning email templates.
That gap tends to show up gradually rather than all at once. A merchant reviewing dashboard numbers a few weeks after launch usually finds the same shape: insufficient-funds failures recovered at a decent rate through Success+, and everything else — cancelled mandates, expired instructions, failed verifications — sitting untouched, because nothing ever nudged the customer to actually fix it. GoCardless reported the failure correctly the entire time; it just never had a mechanism designed to close the loop with the person who could resolve it.
The honest limits of GoCardless's native recovery tooling
Put plainly, here is what GoCardless's own tools do and don't cover once a Direct Debit collection fails:
- No automatic retry by default — someone has to notice the failure and click Retry payment, or you need Success+ turned on.
- Success+ only ever acts on insufficient-funds failures — a cancelled mandate or closed account gets no automatic help at all, retried or otherwise.
- A hard ceiling of three resubmissions per payment, with no setting anywhere to configure that number.
- Payer notification emails are fixed system templates, not a dunning sequence — no branching by failure reason, no escalating tone, no personalization beyond branding on the two highest plans.
- No visibility across processors — if a customer's failed GoCardless collection sits next to a failed Stripe or Braintree charge for the same business, GoCardless has no idea, because it only ever sees its own rails.
- No historical recovery pass — GoCardless doesn't scan back through payments that already failed before you changed a setting; every improvement only applies going forward.
Getting the most out of what GoCardless does offer
- Turn on Success+ if GoCardless is your only, un-intermediated collection method — it is close to zero-effort lift for insufficient-funds failures specifically, and it covers the one failure type actually worth retrying automatically.
- Set the Success+ retry window and attempt count deliberately, not by leaving the defaults — a longer window gives a slow payday more room without extending so far that the eventual retry feels random.
- If you're on GoCardless's Advanced or Pro plan, actually turn on custom notifications and put real branding on the payer emails that are already going out — it costs nothing beyond the plan tier and makes a legitimate email look less like it's being ignored.
- Check the failed-payment list on a fixed schedule, not only when a customer complains — because failures report back on a multi-day delay, a weekly review habit is close to the minimum needed to catch mandate cancellations before they go stale.
- Split your manual-review time by failure reason, not by payment amount — an "Instruction cancelled" or "Account closed" failure needs a new mandate link, not a retry, and treating it like an insufficient-funds case wastes a resubmission that might have worked on a genuinely retryable payment.
- If GoCardless sits behind Chargebee or Recurly, use that platform's own configurable dunning cycle for the email side — GoCardless was never going to provide it, but the billing platform on top usually already does.
A five-minute audit of your own GoCardless setup
- Is Success+ turned on — and if so, is its retry window actually longer than your busiest customers' typical payday gap?
- Do you know, without checking, whether a specific failed payment is "Insufficient funds" or one of the three mandate-level reasons a retry can't fix?
- If you're paying for Advanced or Pro, have you actually turned on custom notifications — or is GoCardless still sending its default, unbranded template?
- Does anyone check the failed-payment list on a set day each week, or only after a customer emails in confused about a missed collection?
- If GoCardless sits behind Chargebee or Recurly, is that platform's dunning cycle actually turned on — or are you relying on GoCardless alone to cover a gap it was never built to cover?
For the complete, current version of GoCardless's own documentation on manual retries, Success+, and payer notifications, its Support Centre is the primary source everything above is drawn from — GoCardless updates plan-tier gating and specific limits from time to time, so it is worth checking directly before finalizing a setup decision.
Where an AI recovery layer like Revova fits in
Revova doesn't connect to GoCardless directly today — it connects to Stripe, Paddle, Braintree, Chargebee, and Recurly. That matters here specifically: if GoCardless is the only way you collect payments, with no billing platform sitting on top, there is nothing for Revova to read yet, and Success+ plus the disciplined manual process covered above are genuinely your best native options.
Where it changes is the moment GoCardless sits behind Chargebee or Recurly as the Direct Debit gateway underneath. Both platforms already surface a failed GoCardless collection as a failed invoice or failed payment record on their own side — and once it is there, Revova reads that same event and adds the two pieces neither GoCardless nor the billing platform's own native dunning covers on its own: recovery emails that read like a person wrote them instead of a fixed template, and a Lost Revenue Finder that goes back through payment history for failures nobody ever actually chased.
If you're trying to decide whether the billing platform's own dunning is enough on its own, our breakdowns of Recurly's Dunning Cycle and Braintree's native retry handlinggo through the same kind of honest, "here's exactly what it covers" audit for those two processors — useful context if GoCardless is one gateway among several in your stack.
What this article is and isn't
GoCardless's own tools — manual retry, Success+, and payer notifications — are real and worth using well. This isn't a pitch to replace them; it's a map of exactly where they stop, so whatever you add next actually covers the gap instead of duplicating what's already there.
Frequently asked questions
Does GoCardless retry failed payments automatically?
Not by default. GoCardless only retries a failed collection automatically if you’ve turned on and paid for Success+, its intelligent-retry add-on — and even then, only for payments that failed due to insufficient funds. Without Success+, nothing resubmits on its own; a team member has to open the failed payment and click Retry payment, up to three times per payment.
What does "Instruction cancelled" mean on a GoCardless payment?
It means the customer, or their bank, cancelled the underlying Direct Debit mandate — not just the one payment. Retrying does nothing against a cancelled mandate; GoCardless will refuse the resubmission the same way it refused the original one. The customer needs to go through mandate setup again before another collection can be submitted.
How long does it take to find out a GoCardless payment failed?
Longer than a card decline, and the exact number depends on the scheme. GoCardless’s own support documentation describes a standard notification landing about one working day after the charge date in the simplest case, but scheme-specific reporting can take longer — a Bacs failure, for example, is reported back through an ARUDD file on a multi-day cycle, with routine recurring payments reaching full confirmation around four working days after submission.
Does GoCardless send dunning emails to customers when a payment fails?
It sends payer notification emails, which is a narrower thing. They fall into four fixed categories — Authorisations, Payments, Subscriptions, and Customer Details — triggered automatically by system events, using a template the payer can only opt in or out of, not one a merchant writes or personalizes. That is meaningfully different from a configurable, multi-step dunning sequence.
Can I customize GoCardless’s payer notification emails?
Only partially, and only on GoCardless’s Advanced or Pro plans. Custom notifications let you apply your own branding and choose how the notification experience fits into your customer journey — real customization of the container, not the underlying logic. There is no setting to branch the copy by failure reason, escalate tone over several days, or personalize content per customer.
What is GoCardless Success+, and does it cover every failure type?
Success+ is GoCardless’s paid add-on that automatically retries a failed payment, using a model to pick the best day to try again rather than a fixed schedule. GoCardless reports an average recovery rate around 70% on the payments it retries — but by GoCardless’s own published criteria, it only acts on insufficient-funds failures. Cancelled mandates, closed accounts, and every other reason on the list are explicitly outside its scope.
Does a failed GoCardless payment automatically cancel a subscription?
No. GoCardless reports what happened to the payment and the mandate — failed, cancelled, expired — but it has no concept of your subscription itself. Whether a failed collection pauses access, cancels a plan, or just sits as an open invoice is entirely up to whichever system owns that logic: your own application, or your billing platform if GoCardless sits behind Chargebee or Recurly.
Does Revova work with GoCardless?
Not directly today. Revova connects to Stripe, Paddle, Braintree, Chargebee, and Recurly — not to GoCardless as a standalone gateway. If GoCardless is your only collection method with no billing platform on top, Success+ and a disciplined manual process are your realistic native options. If your GoCardless collections run through Chargebee or Recurly, Revova can read the failures those platforms already surface and add AI-personalized recovery emails on top.
Layer AI recovery on top of GoCardless-via-Chargebee or Recurly
If your GoCardless collections already run through Chargebee or Recurly, Revova adds AI-personalized recovery emails and a Lost Revenue Finder that neither GoCardless nor native billing-platform dunning covers alone. Start free and see the real number.
Start my 14-day free trial →No credit card · Free Lost Revenue scan · 30-day money-back guarantee
