How to migrate stored card data between payment providers

Stored card data sits at the center of every subscription, membership, and repeat purchase. When this data lives inside a single payment provider, it becomes difficult to move, and the business becomes tied to that provider’s performance and pricing. Many merchants discover this only when they try to switch PSPs, expand into new regions, or improve their approval rates. The challenge is simple. Each PSP issues its own token format, and those tokens rarely move across providers without a controlled, secure process.

A safer and more flexible way forward is to use a PCI compliant, independent vault that supports migration. This keeps sensitive data out of your systems and gives you control over your future PSP choices. Gr4vy’s Cloud Vault follows this model. It lets merchants import existing tokens or encrypted card data, normalize it, and create new tokens they can use across multiple providers. This removes lock in and gives the business a long-term foundation for growth.

Before you start a migration, it helps to understand how vaulting and tokenization work. For a clear overview, you can read: What is vaulting and tokenization?

1. Understand how your current card data is stored

Before starting a migration, you need to know how your existing PSP stores card data. Most PSPs issue their own tokens, and these tokens are only valid inside their systems. This creates the main barrier to portability. The merchant cannot take those tokens and use them with a new PSP unless the current provider supports exporting them.

In most cases, merchants never touch raw card numbers. PSPs store card data in a secure vault and issue tokens that represent the card. These tokens protect sensitive data and help reduce PCI scope. This is an advantage, but it also creates dependency. Once the card lives inside one PSP’s vault, moving it requires a structured, compliant process.

Gr4vy’s website explains this well. Tokenization protects card data, but portability depends on how the token is stored. A PCI compliant vault with open support for imports is the safest model.

2. Check whether your current PSP supports token portability

PSPs differ a lot in how they allow merchants to move stored cards. Some provide simple export paths. Others require a formal migration request. Some do not support portability at all. This step helps you understand the migration path before any technical work begins.

There are two common export methods.
First, PSP-to-PSP token transfer. This is ideal when the original PSP agrees to send the tokens directly to the destination vault.
Second, encrypted card data export. In this case, the PSP provides encrypted card details that can be imported into a PCI compliant vault.

Gr4vy highlights the importance of token portability as a core part of any long-term payment strategy. A merchant should control its stored cards, not the provider. For more context on why this matters, you can read: The importance of tokenization and data portability

3. Build a PCI compliant migration plan

Card data migration must follow strict PCI rules. Merchants should never receive raw card numbers in readable form, and the entire flow should stay between secure vaults. A migration plan typically includes:

• Verifying PCI level of all parties
• Setting secure handoff procedures
• Confirming encryption methods
• Establishing a clear mapping between the old tokens and new tokens
  

The goal is to avoid any exposure of sensitive data. This protects the merchant and ensures the migration does not add compliance risk.

A PCI compliant vault, such as Gr4vy’s Cloud Vault, is built for this type of operation. It supports secure ingestion flows and maintains strict isolation of sensitive data. You can review the way this vault works in more detail here: Gr4vy Cloud Vault

4. Use an independent vault to centralize and normalize tokens

A migration is the best time to remove long-term dependency on a single PSP. An independent vault allows the merchant to centralize card data and use it with any connected provider. Gr4vy describes this as a PSP agnostic vault. It acts as the single source of truth for all stored cards.

Once the vault receives imported data, it normalizes the information. The goal is to create tokens that can be used across multiple PSPs, not tied to one. This reduces the number of future migrations and prepares the business for multi-PSP routing, testing, and global expansion.

A centralized vault also simplifies teams’ workloads. All stored cards, regardless of origin, live in one PCI compliant environment. This makes it easier to manage renewals, lifecycle updates, retries, and future PSP swaps.

5. Import encrypted card data or PSP tokens into the central vault

Once you understand the export options from your current PSP, the next step is to bring the data into your new vault. This process always happens through a secure, PCI compliant channel. Merchants do not see or handle raw card details at any point.

There are two main paths for import.
If the original PSP supports token portability, the existing tokens can be sent directly to the vault. This is the simplest method because the PSP owns the sensitive data and can move it without exposing it.

If portability is not supported, the PSP can provide encrypted card data. This encrypted data is then delivered to the vault, where it can be decrypted and processed inside a secure environment. Gr4vy’s Cloud Vault supports this model. It accepts encrypted inputs and converts them into new tokens that follow a consistent format.

During import, the vault validates every record. It checks for completeness, customer associations, and token mapping so that subscriptions and saved payment methods continue to work without interruption.

6. Re-vault and re-tokenize cards for use across multiple providers

After the data enters the vault, the next step is to create new tokens that the business can use with any connected PSP. This is the core reason merchants benefit from an independent vault. Once tokens live in a PSP agnostic environment, they no longer constrain future decisions.

Gr4vy explains this approach as a way to remove lock-in. Instead of holding thousands or millions of stored cards inside one provider’s proprietary vault, the merchant gains a portable format. These new tokens are stored securely and match the structure needed for orchestration, routing, and multi-PSP setups.

Re-tokenization does not change the customer experience. It simply gives the merchant more freedom. Subscriptions continue to run, stored payment methods still work, and new PSPs can be activated without asking customers to update their cards.

For a deeper understanding of why portable tokens matter, Gr4vy outlines the concept here: The importance of tokenization and data portability

7. Test transactions with each new payment provider

Before switching traffic, it is important to run controlled tests with the new tokens. This confirms that every PSP accepts the migrated data and that each customer ID maps correctly. Testing also helps verify that risk checks, authentication, and transaction flows work as expected.

A structured testing phase reduces surprises during the live cutover. It allows you to identify PSP-specific responses, validate routing rules, and confirm that customer profiles remain consistent.

An orchestration layer, such as Gr4vy’s platform, makes testing easier. You can route a small portion of traffic to each provider, compare results, and adjust configurations without touching your checkout code. This prepares the stack for a smooth transition.

8. Activate multi-PSP routing to improve resilience and approval rates

Once the migration is complete and the new tokens are in place, you can take advantage of a more flexible payment setup. A centralized vault allows stored cards to work with multiple PSPs instead of a single provider. This opens the door to stronger performance and fewer outages.

With an orchestration layer, merchants can route transactions based on region, payment method, risk level, or cost structure. They can also introduce fallback routing so transactions move to a secondary PSP when the primary provider experiences delays or downtime. This improves approval rates and protects revenue in busy periods.

If you want a broader view of how orchestration supports global performance and flexibility, Gr4vy provides a helpful overview here: Payment orchestration in 2026: top 10 must-have features for a global business

9. Monitor performance and retire legacy PSP dependencies

After the new setup is live, it is important to monitor how transactions behave. Look at approval rates, declines, subscription renewals, and settlement flows. This helps confirm that the migrated tokens work correctly across all PSPs.

Once performance stabilizes, you can begin shutting down old connections, dashboards, and reconciliation workflows tied to the previous provider. This reduces operational overhead and simplifies compliance. It also ensures that all future updates, card renewals, and lifecycle events are managed by the new vault, not the legacy PSP.

A centralized, PCI compliant vault removes the need for repeated migrations in the future. When you add a new PSP, the stored cards are already in the right place.

Migrating stored card data can feel complex, but a clear process and the right infrastructure make it safe and manageable. The key is to avoid handling raw card data, keep every step PCI compliant, and use an independent vault that supports both import and re-tokenization. This protects customers and gives merchants long-term freedom to choose the payment providers that fit their needs.

With Gr4vy’s Cloud Vault, merchants can import existing tokens or encrypted card data, normalize it, and create new tokens that work across multiple PSPs. Combined with an orchestration layer, this approach reduces lock-in, improves resilience, and prepares the business for global expansion and higher performance.

Contact Gr4vy to learn more about migrating stored card data with Cloud Vault and payment orchestration.