Recurring Billing: Card Updater, Declines, and the Money You Quietly Lose

Recurring billing means charging a stored card on a schedule, and three mechanics decide whether it works: the authorization you captured at signup, the stored-credential flag on every charge after that, and what you do when a charge fails. Cards expire. They get reissued after a breach. Accounts close. Visa and Mastercard both run account updater services that refresh stored card data automatically, but issuer enrollment is voluntary and the updates arrive in batches, so an updater cuts declined transactions without ever ending them. Most of the money lost in subscription billing isn't lost at the moment a payment fails. It's lost in the weeks before anybody notices.

Recurring billing for a small business is the only part of payment processing where the money leaks quietly. A card-present sale either goes through or it doesn't, and you find out in two seconds, standing in front of the customer. A scheduled charge fails at 3am into an empty room. Your cash flow absorbs it and nothing on your dashboard flinches.

Here's the whole mechanism, in the order you have to build it.

What counts as a recurring payment

Anything where you charge a card the customer isn't holding, on a schedule or a trigger you control rather than one they start at the register.

Recurring payments cover more than subscriptions. Fixed subscription billing is the obvious one: same amount, same interval, a gym membership or a software plan. Usage based billing charges a stored card for metered consumption, so the amount moves every cycle. Installments split a known total into known payments. And then there's the category most small businesses fall into without realising it: unscheduled card on file, where you keep the card details and charge them when something happens. A no-show fee. A restock. The invoice at the end of a service call.

Why the label matters

Because the card brand rules attach to it. Your payment gateway almost certainly has a field for transaction type, and issuers read it when they decide whether to approve. Tag a merchant-initiated subscription charge as a fresh one-off purchase and the issuer sees a card-not-present transaction with no cardholder present to authenticate, which is exactly the shape of a fraud attempt. You'll get declines you didn't earn.

Getting a card on file

What authorization means in a card payment

Three words get used as if they're the same thing and they aren't.

Authorization is the issuer saying yes, the funds exist, here's a hold. Capture is you claiming that money. Settlement is the batch that moves it, which runs on its own schedule (when you get paid depends on your funding terms, not on the authorization).

For recurring billing the first one is what you live and die by. Every scheduled charge is a brand new authorization request. The issuer can decline any of them, for reasons that have nothing to do with you.

Capturing consent, and what to keep

You need the customer's agreement to the terms before you bill, their express consent to the charge, and a record that you got both. That means the amount or how it's calculated, the interval, and how they stop it, disclosed before the first charge rather than buried in a terms page nobody opened.

Keep the record. Timestamp, IP address, the exact text they agreed to, the checkbox state. When a dispute lands eight months later, that record is your entire case.

A note on the rule everyone is confused about: the FTC's Negative Option Rule, the one the press called click-to-cancel, was vacated in full by the Eighth Circuit on 8 July 2025, days before it was due to bite. It is not in force. Don't build to it. What does apply is ROSCA, which has required clear disclosure before billing, express informed consent and a simple cancellation method for years, plus the FTC's general enforcement powers and state automatic renewal laws. The FTC reopened rulemaking in March 2026. Nothing proposed yet.

Where the card data lives

Not with you. Not in a spreadsheet, not on a paper form in a drawer, not in a CRM notes field.

The card information goes to your gateway, which returns a token: a reference string that only works for your merchant account. You store the token. If someone walks out with your database they get a list of useless strings. This is also the only version of card on file that doesn't drag your whole business into the deep end of PCI compliance.

Collect the billing address and the security code on the first transaction. You can't store the security code, and later charges don't need it.

Flagging the stored credential

The first transaction

The initial charge, or a $0 account verification, is where you establish the credential. The cardholder is present, they authenticate, and your gateway records that this card was stored with consent. The issuer returns a transaction identifier.

Every charge after that

You pass that identifier back with each subsequent charge, flagged as merchant-initiated and as the right type (recurring, installment, or unscheduled). This is the stored-credential framework both brands require, and it's the single most skipped step in small business subscription billing.

What goes wrong when you skip it

Declines. Not dramatic ones, just authorization rates that sag for no reason anyone can name, because the issuer is seeing unauthenticated card-not-present attempts and treating them accordingly. Nine times out of ten when a merchant tells us their recurring charges fail more than they should, the flagging is either absent or wrong, and nobody at their billing software vendor has ever mentioned it.

Why recurring charges fail

Expired cards

The dumbest and most common one. Cards carry a three or four year life and they all die eventually. If you've been billing a customer for two years, the card on file is approaching the end of its term by arithmetic alone.

Reissue, replacement and closed accounts

A breach somewhere in the customer's life triggers a mass reissue. The card number stays the same sometimes and changes other times, the expiry almost always changes. Lost and stolen cards get replaced the same way. And accounts close: the customer switched banks, or the bank got acquired.

The customer did not tell you about any of this. They don't think of your charge as something that needs maintenance.

Insufficient funds

Credit limit reached, or a debit card attached to an account that's empty on the first of the month. This one is time-sensitive in a useful way, which matters for your retry strategy below.

Issuer fraud rules

The issuer's own model declined it. Unusual amount, unusual pattern, a card already flagged, a velocity rule tripped because you batched 400 charges at the same minute. You will never see the reason code behind this in any detail and you can't appeal it.

Soft declines and hard declines

Every decline comes back with a response code, and the only question that matters is whether retrying could ever work.

Retrying a hard decline does nothing except add to your decline count, and acquirers watch that ratio. Your billing system should know the difference automatically. A lot of cheap ones don't, and will cheerfully hammer an invalid card number four times.

Account updater services

Visa Account Updater and Mastercard Automatic Billing Updater do the same job from opposite sides of the market. Participating issuers push changes to the networks, the networks hold the updated card data, and your gateway queries it for the cards you have stored. Changed number, new expiry, account closed: the answer comes back and your stored credential gets refreshed without the customer doing anything or even knowing.

When it works it's the best thing in recurring billing. Nobody gets a dunning email. Nobody has to go find their new card. The charge just goes through next cycle.

Enrollment is per issuer, and it's voluntary

This is the part the vendor pages skip. No issuer is required to participate. Large national banks generally do. Plenty of small community banks and credit unions do not, and the smaller the issuer the less likely you are to get an update back.

So the updater covers some of your file, not all of it. You do not know which part until you watch your own declined transactions for a few months and see which ones the updater caught.

Batches, not real time

Updates run on a cycle, typically queried when your gateway refreshes the file rather than the instant a card is reissued. There's lag. A card reissued on the 2nd may not be refreshed in time for a charge on the 5th.

Which means an updater reduces failed payments. Anyone telling you it eliminates them is selling something.

What an updater won't catch

Insufficient funds. Issuer fraud declines. A customer who moved to a card you've never been given. Revoked authorization. None of that is stale card data, so no amount of updated card data fixes it.

Retries and dunning

A retry schedule that doesn't dig the hole deeper

For soft declines, space the retries. Something in the shape of day 1, day 3, day 7, day 14 gives an insufficient-funds decline a chance to catch a payday, and it avoids the pattern of three attempts in six hours that reads as a fraud test to the issuer's model.

Four attempts is plenty. After that you're generating declines for nothing.

The dunning sequence

Dunning is the unglamorous machinery around the retries: the emails that tell customers their payment failed and their service is about to stop. The ones that work are specific. Which card (last four only), what date, what amount, and a link that updates the payment method in two taps. One click payments are only convenient while the card is good, and the moment it isn't, your update path had better be shorter than the customer's patience.

The ones that don't work say "there was a problem with your payment" and link to a login screen. For most of your customers this is the entire customer experience of being billed by you.

When to stop

Pick a number of cycles and hold the line. Keeping a dead subscriber in the retry queue for four months isn't retention, it's a decline ratio problem with a sentimental attachment.

Your billing descriptor

The descriptor is the text that appears on the cardholder's statement. You get a limited number of characters, and most small businesses never touch the default, which is usually the legal entity name nobody recognises.

Put the name the customer bought from in it, and a phone number if the field allows one. A dispute costs you the transaction, a chargeback fee and an hour of somebody's time, and a share of them start with a statement line the customer couldn't place. Fixing the descriptor takes ten minutes.

Do it before you scale the subscription count, not after.

Disputes that start with "I don't recognise this charge"

Most recurring billing disputes aren't fraud and aren't really about cancellation either. The customer forgot. Twelve months of a $19 charge went past unnoticed, they finally spotted it, and the fastest button in their banking app says "dispute this."

What reduces it: a recognisable descriptor, a receipt email after every single charge rather than only the first, and a renewal notice before the annual plan bills. What saves you when it happens anyway is the consent record from signup, which is why you kept it. The process from there is the ordinary one, and we've written it up in how to fight chargebacks.

Sales tax on recurring charges

Whether a subscription is taxable depends on what you're selling and where the customer is, and the treatment of digital services has changed in a lot of places over the last few years. Tax compliance on recurring revenue is a question for your accountant, not your processor. A billing system that calculates tax per invoice is worth more than one that makes you do it by hand.

We don't give tax advice, and we'll say so rather than guess.

Choosing a billing system

Which billing software is best for a small business

There's no answer to that question and the pages claiming otherwise are affiliate roundups. What there is, is a short list of things to check before you commit, because switching billing platforms once you have 300 active subscriptions hurts.

Does it support account updater, and is it turned on? Does it set the stored-credential flags correctly? Does it distinguish soft from hard declines? Can you export your customer list with tokens portable to another gateway, or are you locked in? Does it handle the invoices and the dunning, or only the charge?

That last one catches people. Automating the charge is the easy half, and plenty of integration options will charge a card on a schedule then do nothing at all when it fails.

Pricing models and what the card side costs

Two different costs sit on top of each other: what the billing system charges you, and what the card processing costs. They're separate negotiations and the second one is usually the bigger number.

Recurring charges are card-not-present transactions, which carry higher interchange than a card dipped at a terminal. If you want the detail, what interchange is covers the mechanics.

Our own pricing: a 4% cash discount is the standard program, where the posted cash price is the price and the card price sits 4% above it. Split pricing is available if you'd rather carry part of it, with the business and the customer each covering a share that totals 4%. Traditional interchange-plus is on the table too. No monthly fees of any kind, no program fee, no statement fee, no annual fee. No contract either. Month to month, no early termination fee, cancel whenever you like at no cost.

Why there's 2% extra on some card payments

Because somebody set up a surcharge, and the number you're seeing is theirs, not a standard.

Surcharging runs on card brand rules rather than statute. Visa caps credit card surcharges at 3%, cut from 4% in April 2023. Mastercard's published cap is 4%. Both are also capped at the merchant's actual cost of acceptance, so you can't charge more than the card costs you. Surcharging is prohibited on debit and prepaid cards, including a debit card run as signature over the credit rails. You give your acquirer 30 days' written notice before starting, and the disclosure has to appear at the point of entry, at the point of sale and on the receipt. Some states restrict or prohibit the practice and that list has moved over the years.

For recurring billing there's a mechanic worth flagging: if you surcharge, your billing system has to know the card type on every scheduled charge, because a surcharge landing on a debit card is out of compliance with the brand rules whether anyone catches it or not. Cash discounting avoids that, because the posted cash price applies to everyone. We've laid out the difference in cash discount vs surcharge.

Send us a statement

If you're billing stored cards every month, your processing statement says things your dashboard won't: how much of your volume is card-not-present, what your declines are doing, and whether you're paying for services you don't use.

Send three months of statements and we'll do a free savings analysis. One person reads it, not a queue. Start here.

And if your current pricing is already good, we'll tell you so and leave you alone. That happens more often than you'd expect.