Should you build card-on-file subscription billing
Work out whether stored-credential subscription billing is worth building for your business, what it excludes, and the mandate ceiling mistake that is expensive to undo.
The renewal you have to keep asking for
You sell something a customer buys again on a cycle. A coaching programme. A monthly refill of coffee or supplements. A software licence. Every month somebody on your side sends a payment link and then follows it up. Some customers pay on day one. Some pay on day nine. A few drift away without ever saying they have left.
Stored-credential billing is the rail that removes the asking. The customer authorises a standing mandate once at checkout and you charge the stored card or bank account on the cycle date without touching them again. It is a debit instruction and nothing more. It will not fix a product that nobody wants to renew.
What it costs and what it leaves to you
A stored mandate does not give you invoicing or proration or dunning messages or tax-compliant billing documents or a customer portal. Everything wrapped around the debit stays your problem or your subscription tool's problem. The rail only moves money on a schedule.
The direct cost is your gateway's charge on each successful debit. Rates sit on each gateway's own pricing page and differ by plan so read yours rather than assuming. The larger cost is engineering. Somebody has to build mandate creation and handle the approval callback and store the mandate reference and react to a failed debit and give support staff a screen that explains why a charge did not land. Add support load to the budget. Customers who have forgotten they approved a mandate raise tickets when the debit appears.
Who should build this and who should not
It suits a business with many small recurring charges of a predictable amount. Content subscriptions. Gym and class memberships. Consumables on a fixed refill cycle. The maths works once the labour saved on chasing exceeds the build cost and the per-debit fee.
Do not build it if you have a few dozen renewals a month. A store with forty subscribers is better served by one person sending forty payment links. Do not build it if the amount changes every cycle. B2B billing that moves with usage fits ordinary invoicing far better than a stored mandate carrying a fixed ceiling. And do not build it in the hope of curing churn. Where customers leave because the product underwhelms a smoother debit only moves the cancellation one cycle later.
How a mandate actually behaves
The sequence is fixed. You request a mandate with a maximum amount and a frequency and an end date. The customer approves it by authenticating with their bank or card issuer. The mandate then sits with their bank rather than with you. Ahead of each debit the customer receives a pre-debit notification. On the cycle date the debit is attempted and either clears or fails.
Two behaviours shape the build. Mandates above a value threshold require the customer to authenticate each individual debit instead of letting it pass silently and that threshold varies by category and has been revised more than once. The customer can also pause or revoke the mandate from their app without telling you. Your system learns about that from a gateway webhook and not from a conversation. Design the failure path before the happy path. Decide the retry window and decide what the customer sees on the morning a debit bounces.
The number that matters and the number that flatters
What matters is the successful debit rate on the cycle date read next to involuntary churn. Involuntary churn is the count of customers lost to a failed payment rather than to a decision. Those two figures together tell you whether the rail is earning its keep.
Mandates created is the flattering number. It rises whenever you add a prompt at checkout and it says nothing about money collected. A mandate that never debits cleanly is a row in a database.
The mistake that is expensive to reverse
Most businesses set the mandate maximum at exactly today's price. It feels tidy and it is a trap. That maximum is the ceiling the bank will ever honour. Any price rise and any change in tax treatment and any added delivery charge then needs a fresh mandate approved by every existing customer one at a time.
Re-collecting consent from a base you spent two years building is slow and a visible share of those customers will not re-approve. Set the ceiling above the charge you intend to make with room for a plausible future price and state the ceiling plainly on the approval screen. A customer who notices the gap asks one question and that costs one support reply. Re-papering the whole base costs revenue.
A note on the rules
This rail is regulated. The card networks set the stored-credential rules and your processor and sponsoring bank add requirements of their own. Thresholds and notification timings and category carve-outs have all been revised since launch and will be revised again. Treat this page as a description of how the mechanism works rather than as the current rulebook. A qualified professional should confirm the position for your category and your business before you build against it.
This guide explains how something works. It is not legal, tax or financial advice, and rules change. Confirm anything regulatory with a qualified professional before you act on it.