Aashna Jain

What is a direct debit mandate?

3 min readFor buildersBuilding on it15 of 21

The payment is the easy part. The permission behind it is what actually needs building.

THE PERMISSION IS THE PRODUCT
customer signs once the mandate a durable permission reference · account · scheme collections, month after month STATES YOU MUST HANDLE active suspended cancelled expired the customer can end it without telling you

One authorisation, many collections. The states in between are where the work is.

Mandate and payment are different objects

This is the conceptual mistake that causes most of the trouble, and it shows up in data models constantly.

A payment is an event. A mandate is a relationship with a state, and it can be active, suspended, cancelled or expired independently of anything you are doing. The customer can cancel it directly at their bank without telling you, and the first you learn of it is a collection failing or a scheme notification arriving.

So the system needs to treat the mandate as a first-class object with its own lifecycle, its own reference, and its own reconciliation against what the scheme believes. A design that stores a mandate reference as a field on a subscription will eventually collect against a permission that no longer exists.

What varies between schemes, and what does not

Direct debit schemes differ enormously in the details. Advance notification periods, how long before a collection you must submit it, how long funds take to clear, how long a customer has to claim a refund, and whether the mandate is created at the bank or at the merchant all vary by country and scheme.

The one that most affects product design is the refund window. Some schemes give consumers a long, no-questions right to reclaim a direct debit, which means a collection is not final for far longer than it appears. If your revenue recognition or your fulfilment assumes finality on the collection date, that assumption is wrong, and it is wrong in the direction that costs money.

What is constant across schemes: the permission is durable, the customer controls it, notification obligations exist before you collect, and failures are routine rather than exceptional.

The failure handling is the feature

Collections fail for ordinary reasons at ordinary rates: insufficient funds, closed accounts, cancelled mandates. A system that treats a failure as an exception will generate manual work forever.

What works is unglamorous. Retry on a schedule matched to when people are paid rather than a fixed interval. Distinguish failures that should be retried from those that should not, because retrying against a cancelled mandate is not a retry, it is an error repeated. Notify the customer with something actionable rather than a notification that a payment failed. And reconcile mandate state against the scheme regularly instead of trusting your own record, because yours is a copy and theirs is the original.

A newspaper delivery you arranged years ago. Not paying does not stop the papers arriving, and the papers arriving does not mean you still want them. The arrangement is a separate thing from any single morning's delivery, and ending it means ending the arrangement.

Where you meet it

Every subscription that kept charging after you thought you had cancelled. Every failed payment email that arrived on the wrong day of the month. Every business whose churn number was really a mandate-management number.

Building this? A second pair of eyes on the architecture is what the advisory is for. →

Get the next one in your inbox.

New fundamentals and one memo every two weeks.

One memo every two weeks. Unsubscribe in one click. Delivered through Substack, so their terms and privacy policy apply.