How do I switch payment processors without losing customers' saved cards?

You can often keep customers’ cards, but you usually can’t move the old processor’s tokens directly. Those tokens are often specific to that processor. Instead, ask whether the old provider can securely transfer the underlying card credentials to the new one, which then creates new tokens. Whether that’s possible depends on both providers and their security requirements. (pcisecuritystandards.org)

A practical migration plan

1. Ask the new processor first whether it supports card-data migration from your current provider. Confirm it can import your card types and support your recurring-payment setup.
2. Ask both providers to coordinate a formal migration. They’ll explain eligibility, required paperwork, secure transfer method, fees, and timing. Don’t export card data yourself or put it in ordinary files, email, or spreadsheets.
3. Prepare your records and integration. Keep a mapping between your customer and subscription IDs and the new processor’s IDs. Plan how to handle card updates made while the transfer is underway; those can otherwise be missed. (stripe.kb.ryzedesk.com)
4. Run the systems in parallel during the cutover. Test migrated cards and renewal flows in the new system, then move billing in stages where possible. Keep the old setup available until you’ve verified successful payments.
5. Plan for exceptions. Some payment methods—especially wallet-based credentials—may not migrate like ordinary saved cards. Have a secure “update payment method” flow ready for customers whose credentials can’t be transferred. (stripe.kb.ryzedesk.com)

Before you commit, get written answers to: Can my saved cards be migrated? Who performs the transfer? What happens to subscriptions, billing dates, and retry rules? Which wallets or card types are excluded? What’s the fallback for cards that don’t transfer?

A successful card migration doesn’t automatically move your subscriptions or billing logic, so treat those as a separate part of the project. And don’t assume that having tokens in your system means you can use them with another processor; token portability is provider- and arrangement-specific.

Your saved cards can usually move, but the tokens in your database won't. Each processor's tokens work only inside its own vault, so the workable path is a vault-to-vault transfer of the underlying card data, followed by a mapping from old tokens to new ones.

How the transfer works

• Tokens don't travel. That token generally works with the processor that issued it and nowhere else. So when you switch, the tokens in your database do not travel on their own. Instead, the card data moves, and fresh tokens are issued and mapped back to your customer records.
• The old processor sends the encrypted data straight to the new one. The encrypted card data transfers directly between the two vaults — never passing through your infrastructure. On the giving and receiving "end," the providers must comply with PCI Level 1 standards for the data migration to be possible.
• You get a mapping file. You get a file that maps each old token ID to its new one. Your software then swaps the references.

Steps

1. Check your contract first. The harder questions tend to be contractual: whether your current agreement obliges the processor to release the data, how long the export takes, and who pays for it. Know what your current processor must provide, in what format, and on what timeline, before you announce anything.
2. Start early. Vendor guidance says the process takes weeks, mostly because of paperwork and scheduling. One source says both providers require signed agreements, and the receiving provider will schedule the import into its own pipeline.
3. Confirm the new processor's compliance. Processors typically want proof before they'll send data. For example, Stripe says it can only transfer your card data to another PCI DSS Level 1-compliant payment processor.
4. Request a test export. A sample file surfaces format and mapping issues long before they would otherwise appear.
5. Reconcile and validate. Map the new tokens to your customer records and check that the counts match. One approach is to run zero-amount test authorizations on a sample of cards before going live.
6. Keep the old account open. Keep your old account open and billing until the import is confirmed. Also keep it for refunds and late disputes.

Things that often don't carry over

• Subscription logic. An export carries card details, not your subscription logic. You must rebuild plans, billing dates and customer mappings in the new system.
• Network tokens, depending on setup. Network tokens can also survive a move, but only where the Token Requestor ID belongs to you rather than to your PSP. Otherwise, confirm how they will be provisioned under the new processor so card updates keep flowing.
• Some customers. Certain cards won't survive the transfer, so you'll need a fallback. Collect those details at natural touchpoints such as a renewal or a settings update rather than at checkout, and avoid re-entry prompts that feel like an error to the customer.

Alternatives

• A third-party vault. Some merchants use a third-party tokenization service provider (TSP) to act as an intermediary. The vault holds the card data, so future processor switches are simpler.
• Overlap period. Run both processors in parallel during cutover, and keep the old account open for refunds and late disputes.

Caveat: Some of these sources are vendor blogs, and one ServiceBridge guide is quite old. It suggests skipping token migration for small card counts, under about 300 cards, since it may not be worth the effort. Your current processor's exact export process and fees will matter most, so get that in writing before you commit to a date.

Switching payment processors without losing your customers' saved card information is a standard but sensitive technical process known as token migration or card data portability.

Because security tokens are unique to each processor (meaning a "token" from Processor A will not work in Processor B), you cannot simply "copy and paste" them. Instead, the underlying card data must be securely transferred.

How the Migration Process Works

1. Initiate the Request: Contact your current payment processor to request an export of your saved card data. You will typically need to be the account owner to authorize this.
2. Verify Compliance: Your new processor must be PCI DSS Level 1 compliant. The old processor will only send the data directly to another provider that meets this security standard.
3. Secure Data Transfer: The processors will coordinate a secure, encrypted transfer (usually via PGP encryption) of the raw card data (or vaulted details). You will not see or handle the raw credit card numbers during this process.
4. Re-Tokenization: Once the new processor receives the data, they will "re-tokenize" it, creating new tokens that work within their specific system.
5. Mapping: You will receive a mapping file that links your old token IDs to the new ones. You or your technical team will need to update your database so that your system knows to use the new tokens for future transactions.

Essential Steps to Avoid Disruption

• Run Processors in Parallel: Do not cancel your old account immediately. Run both processors concurrently for at least one full billing cycle. This allows you to handle any remaining disputes or transactions from the old system while ensuring the new one is stable.
• Account for Non-Transferrable Data: Most migrations do not include subscription schedules, historical payment records, or specific metadata. You must export these separately and rebuild them in the new system.
• Plan for Timeline: This process is not instantaneous; it typically takes two to four weeks. Start well in advance of any planned cutover dates.
• Check for "Independent Vaults": To avoid being locked in again in the future, some businesses choose to store their tokens in an independent, third-party payment vault. This allows you to switch between multiple processors without having to migrate data every time.

Before You Start

• Read Your Contract: Check for exit fees or specific language regarding data portability.
• Confirm Compatibility: Ask your new processor explicitly: "What is your process for importing existing PCI-compliant card data from my current provider?" If they do not have a clear, documented process for this, it may be a red flag.
• Test in a Sandbox: Always integrate and test the new processor in a sandbox environment before going live with real customer data.

You can often keep customers’ saved cards, but don’t assume the card tokens will work with a new processor. Processor-issued tokens are commonly tied to that provider; migration usually requires a supported vault-to-vault transfer or another approved re-tokenization process. ⁵⁶

A practical migration plan

1. Ask both providers about portability before you set a cutover date. Confirm whether the outgoing processor can securely export the stored credentials and whether the incoming one can import them. Ask what happens to recurring-payment records, customer IDs, and stored-credential consent data, and get the process and responsibilities in writing. ⁵⁶

1. Have the providers handle the sensitive-data transfer. Arrange a direct transfer between their PCI-compliant environments; don’t export card numbers to spreadsheets, email, or your own application. Confirm the required security, compliance evidence, and agreements with both providers. ⁷¹²

1. Map and test the migration. Keep a reliable mapping between old and new customer/payment-method IDs, and verify a representative set of migrated records and billing schedules. Run controlled test charges or a limited rollout, and have a rollback plan before moving recurring volume. ⁶¹²

1. Handle anything that can’t be migrated separately. For those customers, ask them to re-enter their card details through a secure checkout or account-update flow—ideally at their next renewal or other natural interaction, with clear notice to avoid surprises. ⁶⁷

1. Check account-updater coverage. Visa Account Updater and Mastercard Automatic Billing Updater can help refresh changed card details for eligible stored-card payments, but they are not a substitute for migrating your existing vault or tokens. Confirm availability with the new provider and which card types and issuers are covered. ²⁴

Before switching, get specific answers: Is the transfer supported for your account and payment types? Will subscriptions and customer references carry over? Are wallet payments or bank debits included? What’s the timeline, cost, and failure-handling process? Some credentials—such as wallet tokens or direct-debit mandates—may need their own migration path. ⁵⁷