Direct Debit Is a Pull, Not a Push: Mandates, Collections and Returns
Almost every payment you make is a push: you tell your bank to send money, and it leaves your account. A direct debit is the exception — it is a pull. Someone you've authorized reaches into your account and takes the money out. That single inversion changes everything about how the payment must be modeled, and getting it right is what this post is about.
Push versus pull, in the ledger
When KibiPay sends a credit transfer, the flow reserves your funds up front and commits them on settlement — money is leaving, so it has to be earmarked before it goes. A direct debit is the mirror image. As the collecting party you aren't sending anything; you are asking for value to arrive. The platform's Bacs Direct Debit workflow states the principle directly in its own code: "a Direct Debit is a pull against a customer mandate, not a push credit." So there is nothing to reserve at submission. Nothing is earmarked, nothing is debited from a payer's balance you don't control. The money only appears when the collection actually completes.
The mandate: permission to pull
The thing that makes a pull legitimate is the mandate — the standing authorization a payer gives a collector to debit their account. Without it, "reach into someone's account and take money" is just theft; with it, it's a direct debit. A mandate names who may collect, from which account, and under what terms, and it is the artefact a bank checks when a collection lands. On the platform today the mandate is a first-class concept in the collection workflow (it is what a collection is authorized against) even though it is not yet persisted as a standalone stored object — a deliberate scope line for a system that currently runs the collection mechanics rather than a full mandate-management product.
The collection flow
Modeled as a pull, an outbound direct debit looks nothing like a credit transfer:
- No reservation. Submitting the collection doesn't move money. The payment sits in an
ACCEPTEDstate, waiting for the scheme's collection cycle. - Credit on collection. When the collection completes, the ledger posts value in — a deposit that debits the rail's float and credits the tenant — keyed idempotently on the payment so a replayed completion can't double-credit. The payment advances to
SETTLED. - A real waiting period. Direct debit cycles take days, not seconds. The workflow waits up to a five-day window for the outcome and, if nothing arrives, simply stays
ACCEPTEDrather than guessing.
When a collection comes back unpaid
Pulls fail in ways pushes don't. You can push money into a valid account with confidence, but when you pull, the payer's bank may refuse — insufficient funds, a disputed collection, or a cancelled mandate. Bacs models these as return reason codes, and the workflow handles them explicitly: an ARUDD (Automated Return of Unpaid Direct Debits) or an ADDACS (a mandate-amendment/cancellation advice) arrives as a collection_returned signal, and the payment transitions to RETURNED. That return isn't a ledger reversal of a push; it's the acknowledgement that the money you expected to arrive never will.
Why the distinction is worth the effort
It would be tempting to shoehorn a direct debit into the same push machinery as everything else — reserve, submit, commit. But that model is a lie for a pull: there is no payer balance on your books to reserve, the timing is days not seconds, and the failure modes are collection returns rather than rejected sends. Modeling the pull honestly — mandate-authorized, no reservation, credit-on-collection, unpaid-return-aware — is what lets a direct debit sit alongside a SEPA credit transfer in the same canonical model without either one distorting the other.
A window, not a spinner
One of the more honest design choices in the direct-debit flow is how it handles the long wait. Because a collection can take days to clear or come back, the workflow doesn't sit on a tight timer expecting a quick answer, and it doesn't optimistically mark the payment settled the moment it's submitted. It waits up to a multi-day window for a real outcome signal, and if that window elapses with no word, the payment simply remains ACCEPTED rather than being force-resolved to a guess. The terminal states a direct debit can reach are therefore ACCEPTED (still in the cycle), SETTLED (collected), RETURNED (came back unpaid) or REJECTED — a small, honest vocabulary that reflects what a pull can actually do. When a collection does return unpaid, that outcome doesn't vanish into a log; it lands the payment in a state the exceptions report surfaces, so returned collections are visible to compliance and operations rather than quietly forgotten. Modeling the wait truthfully is what stops a direct debit from masquerading as a completed payment it isn't yet.