Moving recurring billing, and the question that decides everything.
Everything about switching a subscription business is manageable except the stored cards. Ask one question before you commit to anything: can my tokens migrate? The answer changes the whole project.
What this page settles.
Three questions, in the order most people ask them.
Ask this before anything else
“Can my stored card tokens be migrated to you from my current gateway?”
Ask it of the prospective new provider, in writing, before you discuss rates, before you sign anything, before you tell anyone you are moving. The answer determines whether this is a straightforward switch or a project that costs you customers.
Ask the follow-up too: “has my current gateway cooperated with migrations before?” Both sides have to participate, and the side you are leaving has the least incentive to.
Everything else about moving a subscription business — the hardware, the integrations, the reporting, the reconciliation — is ordinary work. The stored cards are the part that can go badly wrong, and the window to find out is before you commit.
Why tokens are the hard part
When a customer gives you a card for recurring billing, you do not store the card number. Your gateway stores it and gives you a token — a reference that lets you charge that card again without ever holding the number yourself. This is the right design and it is what keeps card data out of your systems. Tokenization and P2PE.
The consequence nobody mentions at signup: the tokens belong to the gateway, not to you. They are meaningless to anyone else’s system. Move processors and your list of tokens becomes a list of nothing.
There is a solution, and it exists precisely because this problem is well known. The card networks support secure token migration — a provider-to-provider transfer, under their rules, where the underlying card data moves between compliant environments and you receive new tokens on the new system. The customer does nothing and notices nothing.
Whether it is available to you depends on three things: whether your current gateway will participate, whether the new one supports receiving a migration, and whether your card data is in a form that can be transferred at all. Which is why it is a question and not an assumption.
If they can migrate
The project is routine. A sensible sequence:
Agree the migration in writing with both providers, including the timetable and who does what.
Board the new account and test it with a handful of real transactions before touching anything recurring.
Point new sign-ups at the new system immediately. From that day the problem stops growing.
Run the migration on the existing tokens, and reconcile the count. The number of tokens received should equal the number sent; if it does not, find out which customers are missing before you proceed.
Run one full billing cycle on both, with the new system live and the old one still available. A monthly biller should allow a month; this is not the step to compress.
Compare the cycle results. Successful charges, declines, and amounts, against the previous cycle on the old system. A decline rate materially worse than before means something is wrong with the migration, not with your customers.
Then switch off the old system, and only then. How to switch processors.
If they cannot
A different project, and worth deciding deliberately rather than stumbling into.
Every customer has to re-enter a card. However you frame it, you are asking people to take an action they get nothing from, and a proportion will not. Some will forget, some will decide they did not want the subscription anyway, and some will never see the email.
It is a campaign, not a switch. Plan for two to three months: an initial notice, a way to update that takes one click, reminders, and a phone call for high-value accounts.
Make it as easy as it can be. A hosted update page, a direct link per customer, no login if you can avoid it, and mobile-friendly. Every additional step costs you customers.
Start with your most valuable accounts and call them. A personal call recovers accounts an email will not.
Keep the old system billing until each customer has moved, so nobody experiences an interruption.
And weigh whether the move is worth it. If you are saving $200 a month and the migration costs you 5% of a subscriber base, that is a bad trade. Work out the number before starting. If the saving is large and durable, it usually still wins — but it is arithmetic, not a foregone conclusion.
The lesson for next time is to ask about token portability before choosing a gateway. An independent gateway that works with many processors keeps this option open; a processor’s own gateway generally does not. What is a payment gateway.
The things that break if you rush
Five, all seen in real migrations.
Double billing. Both systems charge the same customer in the same cycle. The fastest way to generate disputes from loyal customers, and it happens when the old schedules are not disabled as each customer moves.
Billing dates shifting. A customer billed on the 3rd for two years is suddenly billed on the 17th. It looks like an unfamiliar charge and gets disputed. Preserve the dates. Friendly fraud.
The descriptor changing. The text on their statement is now different, so a familiar charge becomes an unrecognised one. Set the new descriptor to match the old one before the first cycle. Billing descriptors.
Amounts changing by cents. Rounding differences between systems produce an unexpected figure, which produces support tickets.
Declines you did not expect, because account updater was enabled on the old system and nobody switched it on at the new one. See below.
Set up properly on the other side
Four things on day one, not later.
Account updater. The network service that automatically refreshes expired and reissued card numbers on stored cards. For a subscription business this is the single highest-value feature available — card expiry is the largest cause of involuntary churn — and it is routinely left switched off. Confirm it is on and confirm it is working.
Recurring indicators. Recurring transactions carry their own interchange treatment and need the right flag. Sent as plain keyed transactions they sit at a worse tier and look more like fraud to issuers. Ask explicitly whether stored-credential and recurring indicators are being set. Card-not-present downgrades.
Dunning. What happens on a failed charge — how many retries, how far apart, what the customer is told. Retrying a hard decline repeatedly gets you flagged; retrying a soft decline sensibly recovers real money. Why transactions get declined.
The descriptor, matching the old one.
What we charge
Interchange + 0.50% + 10¢ in person, interchange + 0.75% + 25¢ keyed, with no contract, no monthly fee and no monthly minimum. Recurring billing is part of the account.
If you bill customers monthly, the first thing we will do is find out whether your tokens can migrate — before quoting you anything. If they cannot, we will tell you the move may not be worth it, because a saving that costs you subscribers is not a saving.
While we are on the subject
Can I move stored cards to a new processor?
Often yes, through a secure token migration between gateways. Both sides have to support it and your current provider has to agree, which is why you ask before committing.
What happens if tokens cannot migrate?
Every customer has to re-enter their card details. Expect to lose some, and expect the process to take months rather than weeks.
Should I run both systems at once?
Yes, for at least one full billing cycle. New customers on the new system, existing ones migrating, and nothing switched off until a cycle has run clean.
What is account updater and do I need it?
A network service that automatically updates expired and reissued card numbers on stored cards. For a subscription business it is the single highest-value feature available.