GoCardless Guide: Bank Direct Debit and Subscription Collection

GoCardless Guide: Bank Direct Debit and Subscription Collection

Treating bank direct debit as another kind of card acquiring is the fastest way to fail mid-project. The difference is not in interface detail but in mechanism. Card acquiring revolves around a card number and an authorisation request; direct debit revolves around a mandate the user signs. Card payments authorise every single charge, while direct debit is one mandate with repeated collections, each one initiated by the merchant as an instruction that pulls funds from the user bank account.

That difference decides a lot: no card number to store, no 3-D Secure flow, and essentially no card scheme chargebacks, replaced by mandate management and returns handling. This guide follows GoCardless to set out the mechanism and the rollout of direct debit. It is a payment provider built around bank direct debit, covering markets such as the United Kingdom and the euro area where direct debit is supported, and it mainly fits subscriptions and recurring collection. For the wider European picture see the Europe Local Payment Guide.

1. Positioning: A Direct Debit Provider, Not a Card Acquirer

1.1 The Mechanism: Mandate, Collection Instruction and Returns

Direct debit runs in four steps. The first is signing: the user enters bank account details on your page and signs a mandate, which is recorded in the direct debit system and becomes the basis for later collections. The second is submission: the merchant submits a collection instruction specifying amount and date. The third is clearing: the instruction travels through the local direct debit system to the user bank, which debits the account. The fourth is the result: the collection succeeds, fails, or is returned by the user.

The key difference sits between the first and second steps. Card payments re-authorise with the issuing bank every time, whereas a direct debit mandate stays valid and subsequent collections run within its scope. That is why direct debit serves subscription businesses, and also why it carries operational burden: a mandate can lapse, change, or become void when an account closes or the user cancels, which requires a full lifecycle to manage it.

1.2 What It Is Not

First, it is not a card acquiring platform. It handles no card numbers and does not use card scheme authorisation, so the chargeback evidence methods from card acquiring barely apply.

Second, it is not a general-purpose tool for one-off payments. Its strength is recurring, predictable collection, while for single small immediate payments account-to-account or cards are usually a better fit.

Third, it is not a local entity. Integrating a provider changes which interface you collect through, not which jurisdiction holds your entity, tax and invoicing obligations.

Fourth, it is not a low-risk channel. Lapsed mandates, insufficient funds and user returns are routine, and handling them is part of daily operations.

2. Onboarding and Entity Requirements

2.1 Entity, Bank Account and Business Model

Direct debit onboarding looks at three things: which jurisdiction the entity sits in, whether the business model counts as acceptable recurring collection, and where the settlement account is opened. It weighs business explainability more than card acquiring, because direct debit has different risk characteristics from one-off payments: once a mandate exists the merchant can collect repeatedly, so the reviewer has to confirm that your collection logic is transparent, cancellable and that amount changes have a basis.

Beyond the usual licence and account documents, material usually needs to explain collection frequency, per-collection amount bands, the change and cancellation path, the refund policy, and how a user cancels the mandate at any time. Subscription businesses benefit from a complete subscription description page and a visible cancellation entry point, which carries significant weight in review.

2.2 Compliance and Mandate Rules Do Not Disappear

The direct debit system has its own rules governing how a mandate is obtained, what notice precedes a collection, how user returns are handled, and what evidence the merchant owes. Those rules do not disappear because you use a provider; they reach you through the provider interface and contract. Before signing, ask: what form of mandate counts as valid, must the user be notified before a collection, who is responsible for the notice and its lead time, and what evidence the merchant must supply when a return occurs.

Tax works the same way. Invoicing and tax obligations for recurring collection do not move because the collection mechanism changed, and cross-border subscriptions especially need buyer location separated from tax registration location. For the overall framework see the VAT and Sales Tax Compliance Guide, but the conclusion must land on the rules of each specific market.

3. Integration Options and Account Structure

3.1 Integration Shapes and the Mandate Signing Flow

Direct debit integration usually comes in three shapes: a hosted mandate page, an embedded mandate component and a fully self-built mandate flow. A hosted page launches fastest: the user is redirected to the provider page, enters bank details and signs, and you receive a mandate reference. An embedded component places the mandate form inside your page for a more continuous experience. A self-built flow is the most flexible but requires you to handle bank selection, account validation and mandate callbacks.

Whatever the shape, the signing flow design significantly affects conversion. The user is making a bigger decision than with a card: not only agreeing to a payment but understanding a long-term mandate. Page copy must therefore state collection frequency and amount rules clearly, otherwise users cancel right after signing or dispute the next collection. For subscription billing design see the Subscription Billing API Integration Guide.

3.2 Mandate Lifecycle Management Is the Core Engineering Problem

This is the most important technical judgement in this guide. The core engineering problem in direct debit is not the payment page but the mandate lifecycle: signed, active, amount changed, paused, resumed, cancelled, lapsed, re-signed. Those states must be modelled in your own system and kept in sync with the provider mandate state.

There are three common failure patterns. The first is state desynchronisation: the user cancels the mandate on the provider side while your system still treats it as active, so you keep submitting collections that fail. The second is untracked amount changes: after an upgrade or downgrade the collected amount no longer matches what the user approved, which invites disputes. The third is missing re-signing: a mandate lapses because the account closed or went unused, the system never prompts the user to re-sign, and renewals silently disappear.

The way to handle these is to treat the mandate as a first-class entity: its own state machine, its own reconciliation rules and its own support process. For recovery methods see the Subscription Dunning and Recovery Guide.

4. Core Capabilities and Market Coverage

4.1 Coverage and the Boundary of the Method

Direct debit is not a globally universal payment method. It is a mainstream choice in markets such as the United Kingdom and the euro area where direct debit is supported, and it may not fit markets where habits favour cards or local wallets. GoCardless coverage is built around those direct-debit markets, so the first evaluation step is confirming whether your buyers are located there.

Beyond coverage there is another boundary: each market direct debit system has its own rules and timing arrangements, and mandate validity, pre-collection notice requirements and return handling windows all differ. So even when one provider covers several markets, rollout still needs parameters and processes configured per market rather than one setting for all.

4.2 Mechanism Comparison

The table is worth using directly in solution reviews. Many teams assume direct debit merely adds another collection channel, but it actually changes how charges are initiated, how disputes are handled and how refunds travel, and all three pull operational processes along with them.

5. Fee Structure and Real Cost

5.1 Fee Components

Current rates and conditions belong to the official quote and the signed contract. Any percentage in an article goes stale, and budgeting from old numbers is the easiest error to make.

5.2 Real Cost: Mandate Churn and Returns Handling

The direct debit cost structure differs from cards in one key way: it depends on retention. Card transactions are priced individually, while direct debit value comes from repeated collections on one mandate, so a high churn rate raises unit cost noticeably. Model retention and average collections per mandate rather than only per-collection fees.

The second characteristic is the cost of failure handling. Failures from insufficient funds are common in recurring collection: a good retry strategy recovers some of them, a poor one adds both failure fees and churn. The third is the evidence cost of returns handling, usually carried by operations headcount and invisible in a rate card.

6. How It Divides Work With Other Options

6.1 Against Card Acquiring

Card acquiring and direct debit divide work rather than replace each other. Cards fit first payments and one-off purchases, with broad coverage and immediate completion; direct debit fits renewals from users who already have a relationship, with a cost structure better suited to recurring collection. A common combination is a card payment first, then guiding the user to switch to direct debit, preserving first-time conversion while lowering renewal cost.

Note that the switch requires a new mandate from the user, which loses some users, so the prompt timing and incentive design matter. For general success rate work see the Payment Success Rate Optimization Guide.

6.2 Against Account-to-Account Payments

Account-to-account payments run through open banking: the user confirms in online banking and the transfer completes immediately, fitting one-off payments and cases that need instant settlement. Direct debit fits recurring collection because it can collect repeatedly. Both bypass card schemes, but the logic is entirely different: one depends on user confirmation each time, the other on a standing mandate.

In the same business they can be sequential: new users pay the first time through account-to-account, existing users renew through direct debit. For how an open banking option differs, compare Trustly, and for the overall European method choice see the Local Payment Methods by Region Guide. When evaluating European options it also helps to compare the direct debit coverage and settlement structure of Mollie, Adyen and Stripe side by side.

7. Who It Fits and Who It Does Not

7.1 Good Fit

First: subscription and recurring-revenue businesses, especially SaaS, membership, education and insurance where buyers concentrate in the United Kingdom and the euro area.

Second: teams with mid-range order values and stable collection frequency. The direct debit cost structure only pays off across repeated collections.

Third: teams able to maintain a mandate state machine and a retry strategy. Direct debit carries higher operational complexity than cards, and missing engineering or operational investment hurts retention.

7.2 Weak Fit

First: teams dominated by one-off payments with uncertain repeat business. Without recurring collection there is no advantage to gain.

Second: teams whose buyers are mostly in markets where direct debit is uncommon. However good the method is, it means nothing if buyers do not use it.

Third: teams expecting to integrate and then stop investing in operations. Mandate churn and returns handling are continuous work, not a one-time configuration.

Fourth: teams treating direct debit as a low-risk channel. The risk shape changes; the risk does not disappear.

8. Rollout Notes and Common Misreadings

8.1 Rollout Notes

8.2 Common Misreadings

The first misreading is assuming a direct debit mandate can be stored and charged at will like a card. Every collection must sit within the mandate scope and follow the system rules on notice, basis for amount changes and cancellation rights. Collections outside scope produce returns and complaints.

The second misreading is treating direct debit as a low-risk method. There are indeed no card scheme chargebacks, but lapsed mandates, insufficient funds and user returns are routine, and handling them is the main operational load.

The third misreading is assuming integration means continuous collection. Mandates lapse, accounts close and users cancel proactively, so renewal governance is ongoing work.

The fourth misreading is ignoring the difference in refund paths. A direct debit refund is a reverse instruction through the system, which differs from a card return to source in both timing and experience, and support scripts have to adapt. For refund and settlement operations see the Payment Refund and Settlement Operations Guide.

For general reconciliation and billing operations see the Payment Reconciliation and Bill Operations Guide. If you are working on payment selection for a subscription business, use this guide as a checklist: confirm whether your buyer markets support direct debit, confirm whether mandate lifecycle and failure handling have engineering support, and finally write the refund path and reconciliation dimensions into your process. For the wider regional judgement, continue from the Payment category page.

Source: 16IDC original. Product capabilities, pricing and eligibility requirements follow the relevant providers’ official documentation and contract terms.