A business owner called me a few months ago, pretty excited. She had just found a payment processor charging almost a full percentage point less than the one she'd been using for four years. On her volume, that added up to real money every month. She'd already signed the paperwork.
Then she asked her new provider a simple question: "How do my customers' saved cards move over?" The answer wasn't what she expected. They don't. Not automatically, anyway.
She called me confused and a little panicked. Nearly 900 customers had cards on file for recurring orders. Was she about to lose all of them? Not if she planned it right — but this is exactly the part of switching processors that catches business owners off guard. It looks like a paperwork problem. It's actually a security design, and once you understand why, the rest makes a lot more sense.
Why Your Customers' Card Numbers Don't Just "Move" With You
Here's the part most people don't realize: when a customer saves their card on your site, you almost certainly aren't storing their actual 16-digit card number anywhere in your own systems. Your payment processor is.
What your website keeps, instead, is a stand-in — a long, random string of characters called a token. When a customer's saved card gets charged, your system sends that token to your processor, and the processor matches it against the real card number sitting in its own secure vault. Your systems never touch the real number at all.
This setup, called tokenization, exists for a good reason. Storing real card numbers is expensive and risky — it puts a business squarely inside a strict set of security rules called PCI DSS (Payment Card Industry Data Security Standard), which govern how card data has to be protected. Tokenization lets most businesses sidestep a lot of that burden, because the sensitive data lives with the processor, not with you.
The catch: a token only means something to the processor that created it. It's like a claim ticket at a specific coat check — hand it to a different coat check and nobody knows what it's for. When you switch processors, your old processor's tokens generally can't be read or reused by your new one. The card numbers are still out there, safely locked in the old processor's vault, but neither your new processor nor you can see them.
That isn't an oversight — it's the whole point of the security model. I'd still encourage anyone navigating this to loop in a qualified payments or compliance professional early, since PCI requirements and processor policies shift and the specifics matter for your situation.
Your Two Real Options for Moving Customer Cards
Once you accept that tokens don't just carry over, you're choosing between two paths.
Option one: ask customers to re-enter their card. It's the simplest technically, and the cheapest up front. It's also the riskiest for your business, because every extra step you ask a customer to take is a chance they won't take it. Some percentage of customers will ignore the email, forget, or assume it's a phishing attempt and delete it. For a one-time purchase customer, that's a minor annoyance. For a customer on a recurring plan, it can mean their subscription quietly lapses — and now you've lost a paying customer over a back-office decision they never even knew was happening.
Option two: a token migration. This is a process where your old and new processors — sometimes directly, sometimes through a third-party service built for this — securely exchange the underlying card data behind the scenes, without it ever passing through your systems or requiring your customers to do anything. Done well, your customers notice nothing at all. Their next charge just goes through, on the new processor, using a new token that means something to your new provider.
Token migration isn't available in every situation — it depends on whether both processors support it, and on the compliance paperwork required to authorize the transfer. It also isn't instant; plan for real weeks, not a weekend. I'd genuinely recommend getting your new processor's sales or integration team to spell out, in writing, whether token migration is even on the table before you sign anything.
Keeping Recurring Billing Running Through the Switch
If your business has any subscriptions, memberships, or repeat billing, this is the part to plan hardest around.
The safest pattern I've seen work is running both processors in parallel for a stretch — old account still active, new account taking new business — rather than flipping a switch overnight. If token migration is happening, it runs quietly in the background while both systems are live, and you close the old account only once every recurring customer's next charge is confirmed to work on the new side. Closing the old account too early is the single most common way this goes wrong, because once it's closed, any card still tied to old tokens simply stops being chargeable.
If you're going the re-entry route instead, give yourself real lead time — weeks, not days — and multiple reminders across email and, if you have it, text. Treat it the way you'd treat any campaign where you need people to take action, because that's exactly what it is.
A Quick Real-World Example
A retail client of mine switched processors mid-year for better rates on a decent volume of repeat customers. We ran both systems in parallel for about six weeks, watching the failed-charge rate closely during the overlap window. A small handful of cards didn't transfer cleanly — mostly expired ones, which would have needed updating either way — and those customers got a short, plain email asking them to re-enter their card. That overlap window, more than anything else, is what kept the failure rate low enough that nobody really noticed the switch had happened.
Questions to Ask Before You Commit to a Switch
Before signing with a new processor, it's worth getting clear answers on: whether token migration is supported between your old and new provider, how long that process typically takes, whether both accounts can stay active in parallel during the transition, what happens to failed or expired cards during migration, and what documentation or authorization your old processor requires to release data to the new one. A processor that can't answer these clearly is telling you something about how the rest of the relationship will go.
This kind of transition touches the same territory I've written about in how a credit card reconciliation engine tracks transactions end to end, and if recurring billing is part of your business, it's worth also reading what subscription billing software has to get right — both explain pieces of the plumbing that a processor switch runs straight through.
Better rates are a good reason to switch processors. Just don't let the excitement skip the planning. If you're weighing a switch and want a second set of eyes on what it'll actually take, let's talk through your situation.