How stored card rules affect your subscription billing
Understand how stored credential rules govern recurring charges, what they mean for subscription billing and when not to offer autopay.
Why your renewals stopped collecting themselves
Storing a card and charging it every month used to be the whole of subscription billing. It is no longer that simple. Card networks and processors now treat a stored credential as something you register with the customer present and identify correctly on every later charge and a recurring charge raised outside those rules is far more likely to be declined.
This guide explains the shape of those rules and how they change subscription mechanics. It is not legal or regulatory advice. The requirements are revised regularly and their application depends on the instrument and on your gateway so a qualified professional should confirm the position for your business before you build against it.
What this costs you and what it does not solve
Compliance here is not something you buy. It is implemented by your payment gateway and you inherit it. What you pay for is the engineering to fit your store around it and the support load that follows. Neither of those removes the failure rate. Mandates lapse when cards expire and customers revoke them and banks decline them and no amount of development prevents that.
Expect three costs. There is integration work to register mandates at signup rather than merely saving a card. There is a dunning and recovery process because failed debits are now normal rather than exceptional. And there is customer support time because buyers who receive a notification before a debit will sometimes query it. Gateway charges apply as usual and any tax on them varies by state.
Who should not offer autopay
A store selling one-off products should not touch any of this. Recurring mandates exist for repeating obligations and adding autopay to a catalogue of single purchases creates friction and support burden for nothing. Saved payment credentials for faster repeat checkout is a different mechanism with its own rules and it is what that business actually wants.
Businesses with a genuinely variable charge each cycle should think hard before committing. An authorisation records what the customer expects to pay so a usage-based bill that swings well above that figure invites a dispute rather than a payment. If your charges are unpredictable invoicing with a payment link is often the more reliable route even though it looks less sophisticated.
And a low value subscription may not survive the arithmetic. If the monthly charge is small the proportion of signups lost at the authorisation step plus the proportion of debits that fail each month can exceed what the subscription earns. Annual prepayment collected as a single transaction avoids most of this and is frequently the better product design. A business in that position is better off redesigning the offer than engineering around the rules.
How the framework works in practice
The sequence has three distinct parts and each matters. First the customer authorises the stored credential. This is an explicit permission carrying the amount and the frequency and how long it runs for and it is given with the customer present and authenticated. The first charge can be taken alongside it.
Second the customer is told before the money moves. Network rules and consumer protection practice both expect a clear notice ahead of a renewal and an easy route to cancel and a trial that converts to a paid plan needs a reminder before it does. This is why renewals now generate inbound queries that never previously existed.
Third every later charge has to be identified as a repeat of that original permission. A subsequent charge submitted as though it were a fresh one-off purchase is read as unauthenticated and declined more often and it loses the protection the original authorisation carried. The practical consequence is that two plans can behave very differently depending on how your gateway tags them and a change of amount or billing date can need a fresh authorisation without anyone noticing.
The numbers that tell you the truth
Mandates registered is the flattering metric. It counts intent at signup and nothing else. A business can register plenty of mandates and still collect poorly.
The measure that matters is the success rate of scheduled debits in each billing cycle and the recovery rate on the ones that fail. Track both by instrument because stored cards and bank debits fail at different rates and for different reasons. Alongside those watch the signup completion rate at the authorisation step. If it falls when you raise prices the extra authentication a larger amount can trigger is the first thing to check.
The common mistake
The expensive mistake is treating a failed debit as a cancellation. Most failures are mechanical. An expired card or a temporary bank decline or a notification the customer ignored. Stores that revoke access on the first failure lose paying customers who intended to stay and they lose them silently because nobody complains about a subscription they assume is running.
Build a retry and recovery sequence before you launch rather than after the first bad month. Retry on a schedule. Tell the customer what failed and give them a one-tap route to update the card. An account updater service from your processor refreshes expired cards automatically. Keep service running through a short grace window. Then measure how many of those recover. The work costs a fraction of acquiring replacements.
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.