What is a direct debit mandate?
The payment is the easy part. The permission behind it is what actually needs building.
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. →
