GoCardless and Stripe Dunning: A UK SaaS Integration Guide

Most UK SaaS companies do not run on a single payment rail. Card payments go through Stripe because that is what the founders set up on day one. Then a few enterprise customers ask to pay by Direct Debit, because their finance team will not put a company card on a recurring subscription, and GoCardless gets bolted on. Six months later, failed payments are coming in through two different webhooks, with two different failure code systems, two different recovery timelines, and one very confused dunning process.

This guide covers how UK SaaS teams handle dunning across Stripe and GoCardless, what makes Direct Debit failures genuinely different from card declines, and where a Stripe-focused tool like Rekko fits versus multi-gateway platforms.

Why UK SaaS ends up running both rails

Stripe dominates card payments for UK SaaS. The developer experience is good, the checkout components are reliable, and the reporting is straightforward. But Stripe is less competitive for recurring Direct Debit.

GoCardless is the default for Bacs Direct Debit in the UK. Bacs gives you sub-1% processing fees versus roughly 1.5% to 2.9% on cards, no expiry issues, and no 3D Secure friction. For annual contracts and enterprise deals, the economics are compelling. Larger customers also prefer Direct Debit because it fits how their accounts payable teams actually operate.

So you end up with two rails running side by side. Stripe handles card-paying SMB customers. GoCardless handles larger UK customers paying by Bacs. Both rails fail, and both need recovery sequences, but the failures look different enough that a single generic dunning flow does not work.

Card declines vs Direct Debit failures: the core difference

On Stripe, a card decline is instant. Stripe tries to charge, the issuer says no, and you get an invoice.payment_failed webhook within seconds. The decline reason is usually one of a small set of codes (insufficient funds, card expired, generic decline, do not honour) and the recovery action is almost always the same. The customer needs to add a new card or update the existing one.

Direct Debit on Bacs is slower and the failure codes mean different things. When a Direct Debit is submitted, it moves through the Bacs three-day cycle before you know whether it cleared. Failures come back as ARUDD codes (Automated Return of Unpaid Direct Debits), and they fall into categories with genuinely different recovery paths.

• 0 Refer to payer. The customer's bank refused, usually for insufficient funds. You retry.
• 1 Instruction cancelled. The customer cancelled the mandate at their bank, not through your app. You cannot simply retry. You need them to set up a new mandate.
• 2 Payer deceased. Self-explanatory. Close the account, do not send automated dunning.
• 3 Account transferred. The account moved. GoCardless usually handles this with its mandate update system.
• 5 No account. The account details are wrong. You need a new mandate.
• B Account closed. Hard fail. New mandate required.
• C No instruction. No Direct Debit Instruction exists at the bank. New mandate required.

And then there are indemnity claims, which do not exist on card rails at all. Under the Direct Debit Guarantee, a payer can claim back any Direct Debit payment from their bank, potentially years after the fact, without your involvement. You get an indemnity claim webhook and the money is already gone. Your recovery flow here is not "update payment method." It is "contact the customer, find out what happened, and figure out whether the claim was legitimate."

A generic dunning template that says "your payment failed, click here to update your card" is wrong for most of these scenarios. It is also wrong in a way customers notice, which hurts brand trust at exactly the moment you need it.

Mapping GoCardless events to recovery actions

If you run both rails, you need at least three distinct recovery paths.

Card decline (Stripe). Standard dunning sequence. Email 1 at failure, email 2 at day 2, SMS at day 4, final email at day 7. CTA is always "update your payment method." Retry on Stripe's smart retry schedule.

Recoverable Direct Debit failure (GoCardless ARUDD 0). Shorter sequence. Email 1 at failure explaining the bounce, email 2 at day 3 asking them to confirm funds are available before you retry. Retry the Direct Debit manually or via GoCardless's retry scheduler. No SMS, because UK finance teams rarely use SMS for Bacs issues.

Broken mandate (GoCardless ARUDD 1, 5, B, C). Different sequence. The CTA is not "update your card." It is "set up a new Direct Debit." That means a link to a new mandate flow on GoCardless, not a Stripe card update. Sending them to the wrong page kills the recovery.

Indemnity claim. No automated dunning at all. Route to a human. The claim implies the customer either disputed the charge or their bank acted on their behalf, and automation will make things worse.

Getting these mappings right is 80% of the multi-gateway dunning challenge. The other 20% is unifying reporting so you can see total recovery rate across both rails without stitching spreadsheets.

Where multi-gateway tools fit

Platforms like Chargebee and Recurly support multiple payment gateways natively, including GoCardless, Stripe, Braintree, and others. Their dunning engines can in theory run unified flows across all of them.

The trade-off is cost and complexity. Chargebee's Performance plan starts around 249 USD per month and expects you to migrate your billing onto their platform, not just bolt on dunning. Recurly is in the same ballpark. For a SaaS with a few dozen Direct Debit customers and a few hundred card customers, that is a heavy investment to solve a dunning problem.

Many UK SaaS teams instead run two focused tools. A Stripe-native dunning tool handles the card failures, which are the bulk of the volume. A lighter manual or templated process handles GoCardless failures, which are lower volume and require more judgement anyway.

Where Rekko fits

Rekko is Stripe-first and opinionated about it. It integrates with Stripe via webhooks, detects invoice.payment_failed events in real time, and runs email and SMS sequences on card failures. That is the 80% of your failed-payment volume that is pure automation.

For the GoCardless 20%, Rekko does not try to be a multi-gateway platform. Instead, the recommended pattern for UK teams is:

• Let Rekko handle Stripe card dunning fully automatically
• Wire GoCardless webhooks into a separate lightweight flow (often a Zap, a simple serverless function, or a Slack notification routed to finance)
• Use different email templates for Direct Debit failures that speak the right language (Bacs bounce, new mandate, indemnity) rather than shoehorning them into a card-style template

The result is that the high-volume, automatable path is clean and fast, and the low-volume, high-judgement path gets human attention instead of a wrong-CTA email.

If your Direct Debit volume grows to where you genuinely need multi-gateway automation, that is the moment to look at Chargebee or Recurly. Until then, paying enterprise prices for a full billing platform to solve a dunning problem is usually a bad trade.

Practical setup for UK teams running both rails

Here is a sensible baseline.

1. Connect Stripe to Rekko. Webhooks, sequences, opt-out handling, done in 5 minutes.
2. Build three Stripe dunning sequences based on customer segment: SMB, mid-market, annual. Each can differ in tone, retry cadence, and SMS usage.
3. Wire GoCardless webhooks to your own handler. At minimum, route payment_failed, mandate_cancelled, and payment_charged_back (indemnity) events to a Slack channel so finance sees them in real time.
4. Write three email templates for GoCardless failures: recoverable bounce, broken mandate, indemnity claim. Keep them manual-send at first. Automate only once you have enough volume to justify it.
5. Unify reporting monthly. Pull Stripe recovery data from Rekko and GoCardless data from your internal handler. A simple Google Sheet is fine. The goal is one number: total MRR recovered across both rails.
6. Review quarterly. If GoCardless failure volume grows enough to swamp manual handling, revisit. Otherwise, keep the two-track setup.

The compliance angle, briefly

Everything in our PECR article and lawful basis article applies equally to Direct Debit dunning. UK GDPR Article 6(1)(b) contractual necessity works for both rails. PECR rules on transactional vs marketing content apply the same way. The only extra wrinkle for Direct Debit is the Bacs scheme's own rules on advance notice and mandate changes, which live under the Direct Debit Guarantee rather than data protection law.

Summary

If you are a UK SaaS running both Stripe and GoCardless, you do not need a single multi-gateway platform to run competent dunning. You need:

• A focused tool that handles Stripe card failures well
• A lightweight process for Direct Debit failures that respects their different failure modes
• Templates that use the right language for each rail
• Monthly reporting that unifies the numbers

Rekko handles the Stripe side with flat-fee pricing, GDPR-compliant opt-outs, and email plus SMS sequences. Pair it with a simple GoCardless webhook handler and you have a recovery operation that most mid-market UK SaaS teams would be happy with.

Start your 14-day free trial, no credit card required. Or see how Rekko compares to Recurly and Stunning if you are weighing multi-gateway options.