What Happens to Stored Cards When You Switch PSP?

A merchant renegotiates rates, or gets fed up with decline rates, orsimply outgrows its current setup. The decision to switch PSP gets made in ameeting. Nobody in that meeting is thinking about the 40,000 card tokenssitting in the old provider's vault. They should be. That vault is the thingthat makes recurring billing, one-click checkout, and saved-card conveniencework at all, and it's the single hardest part of a PSP migration to get right.

The token isn't the card. That's the whole problem.

A stored "card" on file isn't a card number. It's a token, areference string the PSP generates and hands back to the merchant after itcaptures and vaults the real PAN. The merchant's systems store the token. ThePSP stores the mapping between token and card. When the merchant wants tocharge that customer again, it sends the token back to the same PSP, whichresolves it internally and runs the authorization.

This is good design for security. It's terrible design for portability.The token only means something inside the vault that created it. Send a Stripetoken to Adyen and nothing happens, because Adyen has no idea what that stringrefers to. The token isn't the asset. The mapping is. And the mapping lives ina system the merchant doesn't control.

Proprietary tokens don't transfer. Network tokens sometimes do.

There are two categories of token in play here, and merchants oftendon't know which one they're holding.

Processor-proprietary tokens are generated by the PSP itself, using itsown vault and its own logic. These are locked to that provider. There's nostandard format, no shared registry, nothing that lets a competing PSP readthem. If the relationship ends, the tokens end with it.

Network tokens are different. Visa, Mastercard, and the other schemesissue these directly, and they're tied to the card and the cardholder, not towhichever PSP requested them. In principle, a network token can follow thecustomer to a new acquirer without anyone re-entering card details. That soundslike the answer to the whole problem. It mostly isn't.

The catch: the receiving PSP has to be a certified Token Requestor withthat scheme, and re-linking existing network tokens to a new merchant accountisn't instant. Scheme-side coordination typically runs into weeks, not hours.So even the "portable" token category comes with a real timelineattached, and merchants who assume network tokens make switching a non-eventusually find out otherwise mid-migration.

What a vault-to-vault migration actually looks like

When tokens genuinely can't transfer on their own, there's a manualpath: the old PSP exports the underlying card data under an encrypted handoff,and the new PSP re-tokenizes it into its own vault. This isn't a file youemail. It's a PCI DSS-governed process between two certified environments,usually requiring sign-off from acquirers or processors on both sides beforeany card data moves.

The output is a mapping file: old token, new token, same underlyingcard. The merchant then has to walk every internal system that stores the oldtoken, billing engine, CRM, support tooling, reporting, and swap it for the newone. Skip a system and it keeps trying to charge a token that no longerresolves to anything. That's a silent failure mode, and it tends to surface asa spike in failed recurring charges weeks after everyone thought the migrationwas done.

Not every PSP will do this migration for a competitor. Some will, for afee, as a courtesy to a departing client. Some won't cooperate at all, and themerchant is left negotiating from a weaker position because the old providerhas no incentive to make the exit smooth.

The alternative nobody enjoys: re-tokenize on next use

When a clean vault-to-vault handoff isn't available, or isn't fastenough, merchants fall back to migrating credentials at the point of nextcharge. The subscription renewal date hits, the merchant routes the attemptthrough the new PSP instead of the old one, and if the customer's card is stillvalid, the new PSP tokenizes it fresh and stores the new token going forward.

This avoids a bulk data transfer, but it spreads the risk out instead ofremoving it. Every renewal during the transition window is now the first timethat specific card has touched the new provider, which means normalfirst-attempt friction: card verification checks, sometimes an unexpecteddecline, occasionally a customer who needs to re-enter details because theattempt failed outright. Run this across a large recurring-billing base andeven a modest failure rate on renewal is measurable in real lost revenue,concentrated in exactly the group a merchant most wants to keep, its payingsubscribers.

There's a second-order cost too. Every customer who hits a failedrenewal and has to manually re-enter a card is a customer reminded thatsomething changed. Some of them shrug and move on. Some of them use the momentto cancel, especially if the subscription was already marginal in their mind. APSP migration doesn't just risk technical failures. It creates cancellationopportunities the merchant didn't intend to offer.

Account updater services complicate the picture further

Most merchants running recurring billing already lean on a card accountupdater, Visa Account Updater or Mastercard Automatic Billing Updater being thetwo everyone runs into. These services quietly refresh expired or reissued cardnumbers behind a stored token, so a customer whose card gets replaced afterfraud doesn't see a failed renewal. The updater talks to the token, not themerchant.

Switch PSP and that relationship breaks along with everything else. Theold PSP's updater subscription was tied to its own vault. The new PSP needs itsown enrollment, and until that's active, any card that gets reissued during themigration window renews on a dead number. Merchants who forget to re-enroll inaccount updater services after a PSP switch tend to notice the gap only whendecline codes for expired or invalid cards start climbing a few months later,which is exactly the lag that makes it hard to trace back to the migration.

How long this actually takes

Nobody wants a vague answer here, so it's worth naming rough ranges,while being clear these vary by provider and by how clean the merchant's owntoken inventory is going in.

A network token relink, where the new PSP is already a certified TokenRequestor with the relevant scheme, tends to run four to twelve weeks once thepaperwork starts moving. That's scheme coordination time, not engineering time,and it doesn't compress much no matter how urgent the business reason forswitching.

A vault-to-vault migration for proprietary tokens depends almostentirely on whether the old PSP cooperates. A willing provider with adocumented export process can turn this around in days for the data handoffitself. An unwilling one can drag it out for months, or refuse outright, inwhich case the merchant is stuck with the next-use fallback whether it wantsthat path or not.

Remapping internal systems to new tokens is usually the part merchantsbudget the least time for and it's often the longest. It touches every systemthat ever wrote down a token: billing, CRM, support tooling, fraud rules,reporting, data warehouses. A migration that looks finished from the PSP's sidecan still be leaking failed charges from a forgotten internal service weekslater.

What to check before signing with a new PSP

Most of the pain in a PSP migration is avoidable if it gets addressed atcontract time with the provider being left, not discovered at exit. A fewquestions are worth asking directly, and getting in writing, before signinganywhere:

Whether the tokens being issued are network tokens or proprietary ones,and if proprietary, whether the vendor has a documented process for exportingcard data to a competitor on request.

What the SLA is for a data export or vault-to-vault handoff if themerchant leaves, including who pays for it.

Whether the PSP will actively cooperate with a departing client's chosenreplacement, or whether cooperation has historically required escalation, legalinvolvement, or a fee negotiated after the fact.

How account updater enrollment is handled, and what happens to theupdate subscription if the merchant moves providers.

None of this is complicated to ask. It's just rarely asked, becausenobody signs a PSP contract while planning the exit.

Testing before cutover, not after

A phased rollout catches problems a big-bang switch won't. Route a smallpercentage of renewal traffic through the new PSP first, watch decline ratesand error codes closely, and only widen the rollout once the failure rate looksnormal for that customer segment. This matters more for subscription businessesthan almost anywhere else in payments, because a spike in failed renewalsdoesn't show up as one incident. It shows up as slowly rising involuntary churnthat's easy to miss until finance asks why retention dipped.

Testing every transaction type matters too, not just the common case.Refunds against old transaction IDs, partial captures, disputes filed against acharge made before the migration, these all need to keep working againstwhichever provider actually processed the original transaction, even after themerchant has moved on.

Where this goes wrong most often

Three patterns keep showing up in migrations that go badly.

The merchant doesn't know what kind of tokens it's holding until theswitch is already underway, and finds out the hard way that they're proprietaryand non-portable.

The timeline gets set by the business side of the migration, contractsigning, pricing, go-live date, without anyone checking how long scheme-sidetoken relinking or vault-to-vault handoff actually takes. Those two clocksrarely agree.

Internal systems get remapped incompletely. The billing engine gets thenew tokens. The support dashboard, the fraud tooling, or a secondary reportingpipeline doesn't, and stays quietly pointed at dead references until someonenotices declines climbing.

Why this is easier when the merchant owns the vault

There's a structural fix underneath all of this: don't let card datalive inside the PSP you might one day leave. If card capture and storage sit ina merchant-controlled or PSP-agnostic vault, tokenized once at the point ofcapture, the PSP becomes a routing destination rather than the custodian of thecustomer relationship. Switching processors then means changing where a tokengets sent for authorization, not re-acquiring the underlying card data fromscratch.

This is the architecture behind PCI Proxy's token vault. Card data iscaptured and tokenized outside any single processor's environment, which meansthe token stays valid regardless of which PSP is doing the actual charging. Adda new acquirer, drop an underperforming one, run two processors in parallel forrouting purposes, none of it requires touching the customer's stored cardagain. The vault doesn't change. Only the routing does.

The real lesson

PSP contracts get negotiated around pricing, uptime, and supportquality. The exit terms rarely come up until someone is already trying toleave, and by then the negotiating power has shifted. Before signing with a newprovider, or renewing with an existing one, it's worth asking a blunt question:if this relationship ends, who has the tokens, and what does getting them backactually cost. For a merchant with a meaningful stored-card base, that answermatters more than almost anything else in the contract.

‍

‍