GoCardless Alternatives: 5 Options for Recovering Failed Direct Debits (2026)

GoCardless collects recurring Direct Debit payments straight from a bank account across eight schemes worldwide — but a real share of those collections still fail. Here are five real ways to recover them, from GoCardless's own Success+ retry engine to a dedicated AI recovery layer, with an honest look at what each one actually covers.

Unlike a card decline, a failed Direct Debit collection does not bounce back instantly — it can take a few business days for the receiving bank to report the failure, closer to how a US ACH return works than a real-time card network response. (If GoCardless is collecting through its US ACH scheme specifically, the failure even arrives as a standard NACHA return code — see our ACH return codes guide for what each one means.) That lag is exactly why having a real recovery plan — not just a hope that GoCardless retries it — matters.

What is GoCardless, and why do collections still fail?

GoCardless is a Direct Debit collection platform, not a card network — it moves money directly between bank accounts on schemes like Bacs (UK), SEPA (EU), ACH (US), PAD (Canada), Autogiro (Sweden), Betalingsservice (Denmark), and BECS/BECS NZ (Australia and New Zealand). Plenty of businesses connect to it directly, and plenty more use it indirectly — as the Direct Debit gateway plugged into a billing platform like Chargebee or Recurly.

Even with a mandate in place, collections still fail — most commonly because the account did not have enough funds on the day GoCardless attempted to collect. Less often, it is a cancelled mandate, a closed or switched account, or a first-time mandate that never passed bank verification.

How a GoCardless Direct Debit mandate actually works

A card saved with a processor is a token: authorize and capture happen in the same synchronous call, seconds apart, against the card network's real-time rails. A GoCardless mandate is a completely different mechanical object. It is a standing legal authorization the customer gives once, which then covers every future collection the merchant — or the billing platform sitting behind it — chooses to submit. That difference is exactly why a failed Direct Debit collection surfaces on a different timeline than a declined card, and why a recovery plan built around instant webhooks does not map cleanly onto Direct Debit.

1. Mandate setup.The customer authorizes Direct Debit once, through GoCardless's hosted payment page, an embedded flow, or — for Denmark's Betalingsservice specifically — a bank-mediated debtor agreement rather than a form filled out with the merchant at all. This step captures a mandate reference and bank details; nothing about a card number is involved, and nothing is stored the way a card token is.
2. Pre-notification.This step has no card-network equivalent at all. Most schemes legally require the merchant to tell the customer, in advance, the amount and date of an upcoming debit. UK Bacs sets a 10-working-day default notice period, which GoCardless's own standard merchant agreement shortens to 3 working days by prior agreement. SEPA caps the agreed notice at 14 calendar days, with 3 working days as GoCardless's stated best practice. If proper notice is not given, the customer is entitled to an immediate refund under scheme rules, and the merchant risks sanctions from the scheme itself.
3. First collection.A brand-new mandate runs visibly slower than a recurring payment, because part of the mandate — not just the payment — is still clearing with the receiving bank. GoCardless's own published Bacs timings put a first payment on a new mandate at roughly 6 working days from submission to full confirmation: the mandate clears through one Bacs three-day cycle before the payment itself clears through a second.
4. Recurring collections.Once the mandate is live, each later collection moves faster, since only the payment — not the mandate — needs to clear. For Bacs specifically: a recurring payment is collected 2 working days after submission, is "99% confirmed" by day 3, and reaches full confirmation by day 4 — the extra day accounts for the roughly 1% of failure notifications that arrive late.

This lag is the same structural reason our intro flagged: a Direct Debit failure behaves more like a US ACH return than a real-time card decline, and any recovery process built around Direct Debit — whether that is Success+, a billing platform's dunning, or a manual spreadsheet — has to be built around a multi-day reporting delay rather than an instant failure signal.

Option 1: GoCardless Success+ (native, built in)

Success+ is GoCardless's own paid add-on: a machine learning model that picks the single best day to retry a payment that failed for insufficient funds, rather than retrying on a blind fixed schedule. GoCardless's own reporting puts the average recovery rate on Success+-retried payments at around 70% — close to double the rate of retrying without it.

What a merchant actually configures is narrower than "turn on AI retries" makes it sound. Inside the GoCardless dashboard, Success+exposes five settings: which currencies it applies to, the length of the retry window (for example, capping retries to 4 weeks), how many retry attempts fall inside that window, an initial delay before the first retry fires, and an optional failure filter that skips a specific retry outright when GoCardless's own model predicts it is unlikely to succeed. For merchants integrating directly against the API rather than through the dashboard, opting a payment in is a single field — retry_if_possible: true — mirrored by the same dashboard toggle for accounts connected through Chargebee, Recurly, or another partner app.

The "insufficient funds only" restriction is enforced at the level of the specific decline code each scheme returns, not just as a general policy. By GoCardless's own published retry criteria, Success+ retries:

• Bacs — code 0 (Refer to payer), reported via the scheme's ARUDD file.
• ACH — R01 (Insufficient Funds) and R09 (Uncollected Funds), the same NACHA codes covered in our ACH return codes guide.
• SEPA Core — AM04 (Insufficient Funds), and MS03 (Unspecified by bank) for a subset of Eurozone countries.
• PAD — reason code 901 (Insufficient Funds).
• BECS — code 6 (Refer to customer).
• BECS NZ — AM04 (Insufficient Funds).
• Autogiro — TK82-1 (Insufficient Funds).

Anything outside that list — a cancelled mandate, a closed account, a direct bank refusal — is explicitly excluded. GoCardless's own reasoning is that reattempting a payment the bank has already refused for a non-funds reason would simply fail again.

Option 2: Chargebee Dunning (if billed through Chargebee)

GoCardless is listed as Chargebee's preferred Direct Debit partner, supporting SEPA, ACH, Bacs, and Autogiro collection through the Chargebee gateway. When one of those collections fails, it surfaces as a failed invoice in Chargebee, and Chargebee's own configurable dunning schedule — retries plus reminder emails — takes over from there. See our full breakdown in Chargebee dunning management.

Turning on Success+ specifically inside Chargebee is a single toggle: Settings → Configure Chargebee → Dunning for online/offline payments, then enabling "Use Success+ to retry GoCardless payments" under the Direct Debit section. Once it is on, Chargebee explicitly hands the retry decision back to GoCardless — the actual schedule lives in your GoCardless dashboard's intelligent-retries settings, not in Chargebee's own dunning configuration. Chargebee's role becomes downstream from that point: it listens for GoCardless's retry notifications, creates the corresponding scheduled payment attempt, and updates the invoice timeline, while the actual "when" decision stays with the Success+ model covered above.

Two mechanical details are worth knowing before flipping that toggle on. First, keep the retry period configured in GoCardless in sync with Chargebee's own dunning period — a mismatch can leave Chargebee treating an invoice as failed and moving to the next dunning step while GoCardless still has a retry in flight, which is a real path to double-charging a customer. Second, once GoCardless has already submitted a retry to the bank, stopping dunning inside Chargebee does not pull that attempt back — a Direct Debit instruction that has gone to the bank cannot be cancelled, so a customer flagged for cancellation after that point may still see one more collection land.

Mandate failures are handled as a separate event entirely from a single failed payment. When GoCardless notifies Chargebee that a mandate itself failed verification, expired, or was cancelled by the customer's bank, Chargebee marks the stored payment method invalid and fires a notification to the team — but recovering from it means getting the customer through an entirely new mandate setup. No retry schedule, from Success+ or from Chargebee's own dunning, touches a dead mandate.

Option 3: Recurly's Dunning Cycle (if billed through Recurly)

Recurly's GoCardless integration supports SEPA, ACH, Bacs, and BECS collection, with automated insufficient-funds retries built into the gateway connection itself, on top of Recurly's broader Dunning Cycle of retries and reminder emails. See our guide to Recurly dunning and Account Updater for exactly how the schedule and retry logic work — note that Account Updater itself is card-only and does not touch Direct Debit mandates.

Recurly's automated Direct Debit retry behaves less like a tunable dunning schedule and more like a hard scheme rule encoded into the product. It covers SEPA, ACH, Bacs, and BECS, but only through certain gateways underneath — GoCardless, Adyen, and Stripe, plus Worldpay for SEPA specifically — and it retries strictly twice per invoice, a ceiling Recurly ties directly to NACHA, SEPA, and EU/AU regulatory retry limits rather than to its own product preference. The retry fires automatically 24 hours after Recurly receives a late insufficient-funds notification from the gateway — AM04/MS03 for SEPA, R01 for ACH — and that 24-hour window is fixed; Recurly does not expose a setting to change it.

The one setup step that genuinely matters here: Recurly explicitly warns against running its own Direct Debit retry at the same time as a gateway-level retry service — GoCardless Success+ included — because both can independently decide to retry the same failed collection, and the customer ends up debited twice for one missed payment. If you are on Recurly with GoCardless underneath, pick one retry engine, not both. It is also worth checking your Dunning Cycle settings directly: if a subscription is configured to expire immediately on a failed payment, Recurly's Direct Debit retry never gets the chance to run, since the invoice is already closed out before the 24-hour window would fire.

Option 4: Revova — an AI recovery layer on Chargebee or Recurly

Revova does not connect to GoCardless as a standalone gateway today — it connects to Stripe, Paddle, Braintree, Chargebee, and Recurly. That means Revova's value here is specific: if your GoCardless collections already run through Chargebee or Recurly, Revova sits on top of that billing platform and adds two things neither GoCardless nor the platform's native dunning provides on its own — AI-personalized recovery emails that read like they came from a person, and a Lost Revenue Finder that scans your payment history for failures nobody ever chased.

It is worth being precise about the mechanism, too. Once GoCardless sits behind Chargebee or Recurly, Revova reads the failed invoice or failed payment record the billing platform already surfaces — not GoCardless's own ARUDD- or ADDACS-style bank reports directly. That is a real distinction: Revova's visibility into a GoCardless-sourced failure is exactly as good as Chargebee's or Recurly's own visibility into it, no better and no worse, because Revova is reading the same event the billing platform already received. If your billing platform's GoCardless integration misses a failure type — the way Chargebee's dunning and Recurly's Direct Debit retries genuinely differ in coverage, as the two sections above lay out — that gap sits one layer upstream of Revova, and nothing sitting on top of the billing platform can act on a failure the billing platform itself never surfaced.

Option 5: Manual chasing

The default everyone starts with: export failed collections, track them in a spreadsheet, and email customers by hand to update their bank details or retry. It costs nothing but time, and time is exactly what it costs — it does not scale past a handful of failures a month, and failures are easy to let go stale past the point they are still recoverable.

In practice, "manual" means checking two different lists inside the GoCardless dashboard (or one layer up, inside Chargebee's or Recurly's own failed-invoice view): the ordinary list of failed payments — for a UK Bacs account, reported via an ARUDD file a few working days after collection — and the separate list of cancelled mandates, reported via an ADDACS report, which needs a brand-new customer authorization rather than a retry. Conflating the two is the most common manual-process mistake — chasing a mandate-cancellation customer with a "please check your bank balance" email, when what they actually need is a new Direct Debit setup link.

The core problem is the lag covered earlier: because a Bacs or SEPA failure can take several working days just to surface, a spreadsheet process built around same-day card declines tends to let Direct Debit failures sit unnoticed for a week or more before anyone starts chasing them — and every day past the original due date makes the eventual recovery email feel more like a surprise than a reminder.

The 5 options compared

For the deeper mechanics of how a billing platform's dunning schedule works day to day, our what is dunning guide and dunning email templates cover the full playbook regardless of which processor or gateway sits underneath.

Which of GoCardless's 8 schemes fails most — and why

It is tempting to want a single ranked list — "Bacs fails X% of the time, SEPA fails Y%" — but GoCardless has not published a directly comparable, audited failure-rate breakdown across all eight schemes, and we will not invent one. What GoCardless has published is a detailed look at its own UK Bacs book, plus enough documented, scheme-by-scheme mandate and notice rules to explain — structurally, not statistically — why failure behavior genuinely differs by scheme even before any numbers enter the picture.

On the numbers GoCardless has actually published: an analysis across roughly 55,000 of its UK customers and more than 52 million transactionsput the average Bacs failure rate at around 2.9%. Of that 2.9%, GoCardless attributes more than 80% to insufficient funds alone — about 2.38 percentage points — with mandate cancellations accounting for roughly 15% of the remainder. Failure rate also correlated with payment size in that same data: payments under $250 held a fairly steady 2.6–3% failure rate, while payments over $250 ranged from 4.1–5%. Treat this as GoCardless's own reported figure for its UK book specifically — not an independently audited number, and not necessarily representative of SEPA, ACH, or any other scheme.

Where a real, verifiable structural difference does exist is in how much advance warning a customer legally gets before money leaves their account — which plausibly affects how often "insufficient funds" actually happens, even without a published cross-scheme comparison to prove it directly. UK Bacs sets a 10-working-day default notice period, shortened to GoCardless's standard 3 working days by agreement. SEPA caps agreed notice at 14 calendar days, with 3 working days as GoCardless's stated best practice. Canada's PAD requires 15 calendar daysfor a first payment — reducible to 3 days only where the mandate went through an identity-verification step — and 10 calendar days for every recurring payment after that. Sweden's Autogiro requires 8 working days' notice unless the customer has explicitly pre-authorized that specific payment amount and date.

Australia's BECS is the outlier at the notice stage: pre-notification is not a scheme requirement at all — GoCardless recommends sending one working day's noticepurely as good practice, not because the scheme demands it. Denmark's Betalingsservice takes the opposite approach at the mandate-setupstage rather than the notice stage: a mandate only authorizes successfully if the customer's CPR (personal) or CVR (business) registration number matches their own bank's records for that account, via a debtor agreement the customer has to hold with their bank first. A mismatch does not produce a failed payment later on — it blocks the mandate from ever being created.

None of this proves one scheme statistically fails more often than another — again, that comparison is not publicly available — but it does explain why a merchant collecting across multiple schemes should not expect uniform failure timing or a uniform recovery window. A SEPA customer has up to two weeks' warning before a debit; a BECS customer may have none beyond best-practice courtesy. A single retry cadence applied identically across all eight schemes is quietly applying a UK- or Eurozone-shaped assumption to schemes that never agreed to those rules.

Switching or adding a recovery layer without disrupting live mandates

A live GoCardless mandate is a standing authorization the customer already gave. Moving billing platforms, or layering a recovery tool on top, does not require asking them to authorize Direct Debit again — provided the underlying GoCardless mandate reference carries over intact. Losing sight of that distinction is the single most common, and most avoidable, mistake in a migration.

• Keep the mandate — do not recreate it. Chargebee, for example, supports importing an existing GoCardless mandate ID directly onto a customer record — via Customers → Update Customers Payment Method — rather than sending the customer through a brand-new authorization page.
• Pick one retry engine, not two.As covered above, enabling a billing platform's native Direct Debit retry alongside GoCardless Success+ risks a duplicate collection landing on the same failed payment. Turn one off before the other goes live.
• Confirm webhook and event handling before cutover. Because a Direct Debit failure can take several working days to report back, verify the new stack correctly receives the failure or cancellation event for a mandate created before the cutover date — not just for new signups after it.
• Only re-notify customers if what they were told actually changes. The pre-notification obligation covers the amount, date, and frequency a customer was told about — not which internal system happens to be billing them. If the mandate reference, price, and collection date stay the same, switching billing platforms behind the scenes generally does not reset that clock; if any of those details does change, treat it like a fresh notice period under whichever scheme applies.
• Cut over your smallest scheme first if you run more than one. Since notice periods and mandate-setup rules genuinely differ by scheme, validating the migration on your lowest-volume scheme first limits the blast radius if the new integration handles retries or mandate events differently than expected.

If the platform being added is Revova specifically, the scope limit from earlier still applies: there is nothing to migrate or reconfigure on the GoCardless side at all, because Revova connects to Chargebee or Recurly, not to GoCardless directly. It starts reading whatever failed-payment and failed-invoice events the existing billing platform already receives, with no separate cutover step for the Direct Debit mandate itself.

Frequently asked questions