Changing Payment Gateway: Can You Move Stored Cards, Tokens and Recurring Payments?

Quick summary: can you move stored cards when changing payment gateway?

Stored card details and recurring-payment customers may be transferable when a business changes payment gateway or payment provider, but migration is not automatic.

Whether payment details can be moved depends on:

• how the card details are currently stored
• the type of token being used
• whether the existing provider supports secure data export
• whether the new provider supports payment-data imports
• PCI DSS requirements
• the merchant's recurring-payment setup
• the billing or subscription platform being used
• whether important recurring-payment and authentication data is available.

Businesses should therefore investigate payment-data portability before cancelling the existing gateway or processor.

In many migrations there are several separate elements to consider:

• customer records
• stored card or payment details
• payment tokens
• subscription or billing schedules
• recurring-payment information
• gateway integration
• fraud and 3D Secure configuration
• merchant acquiring.

These do not necessarily move together.

A merchant can therefore successfully migrate stored payment information but still need additional work before existing subscriptions and recurring payments operate correctly through the new provider.

Find Your New Processor

What happens when you change payment gateway?

The answer depends on how your existing payment setup has been built.

For a relatively straightforward ecommerce business taking one-off payments, changing gateway may mainly involve:

• opening the new payment account
• integrating the new gateway
• testing payments
• changing the checkout
• moving live transactions to the new provider.

For a business with thousands of customers whose cards are already stored for future payments, the migration can be considerably more complicated.

The business may need to retain the ability to charge those customers without requiring everyone to enter their card details again.

This is where payment-data migration and token portability become important.

Before switching, businesses should establish:

Where are our customers' payment credentials currently stored?

Who controls those credentials?

Can they be securely transferred to the new provider?

What additional recurring-payment data needs to move with them?

Are you switching from Stripe, SumUp or another payment provider?

Businesses start looking at payment-data migration for different reasons.

Sometimes the existing provider no longer suits the way the business operates. In other cases, the business has grown and now needs:

• different pricing arrangements
• greater control over acquiring
• multiple merchant accounts or acquirers
• more complex payment integrations
• specialist sector support
• international acquiring
• more control over stored-payment data
• a different recurring-payment setup
• greater payment resilience
• more flexibility over its wider payment infrastructure.

The commercial reason for switching is only one part of the decision.

If the business already has online customers, stored payment credentials, recurring transactions or software integrations, it also needs to understand what will happen technically when the existing provider is replaced.

Outgrown Stripe?

A business may begin reviewing Stripe as its transaction volumes, international requirements, subscription model or wider payment infrastructure become more complex.

That does not necessarily mean Stripe needs to be replaced.

The review could result in the business deciding to:

• retain Stripe unchanged
• optimise or renegotiate its current Stripe arrangement
• add another payment provider alongside Stripe
• move only part of its payment activity elsewhere
• migrate away from Stripe completely.

Our Outgrown Stripe guide looks at how businesses can decide whether to stay, optimise or switch.

If the business has stored cards, subscriptions or recurring customers, payment-data portability should form part of that decision before existing Stripe services are cancelled.

Outgrown SumUp?

SumUp is not limited to face-to-face card machines.

SumUp also offers online-payment technology including Hosted Checkout, its Payment Widget and APIs. Its online-payment tools can also support stored cards and recurring payments.

A business may nevertheless start considering a different payment setup as it grows and begins to need:

• different acquiring arrangements
• more complex integrations
• multiple providers or merchant accounts
• specialist payment functionality
• different commercial terms
• greater control over its payment architecture.

Our Outgrown SumUp guide looks at when businesses may want to compare alternative payment providers and what to consider when switching.

If the business already uses SumUp for online or recurring payments, it should establish what happens to any stored payment information, tokens and recurring customers before the existing setup is closed.

Switching merchant account provider?

Changing merchant account provider and changing payment gateway are not necessarily the same thing.

Depending on the existing payment setup, a business may be able to:

• change acquirer while retaining its existing gateway
• change gateway while retaining its existing acquirer
• change both gateway and acquiring provider
• add a second provider without immediately removing the first
• retain some parts of the payment infrastructure while migrating others.

For a broader explanation of the commercial switching process, see our Tips for Switching Merchant Account Provider.

The important first step is to map the whole payment setup before cancelling anything.

That means identifying:

• the existing payment gateway
• the acquirer or merchant account provider
• any separate payment processor
• where stored card credentials are held
• how payment tokens are generated
• how recurring billing is managed
• which software systems are integrated
• which elements actually need to change.

Only then can the business understand whether the switch is primarily a commercial change, a technical migration, or both.

Changing provider does not always mean replacing everything

One of the most important parts of a payment-provider review is understanding which parts of the existing infrastructure can remain in place.

For example, a business using an acquirer-agnostic gateway may be able to change acquiring provider without rebuilding its entire checkout.

Another merchant may be able to retain its acquirer but move to a different gateway.

A more complex business may decide to retain its existing provider while adding another payment route through a multi-acquirer or payment-orchestration setup.

See our Acquirer-Agnostic Payment Gateways guide and Payment Orchestration guide for more information.

The objective should be to change only the parts of the payment stack that actually need changing.

Stored cards are not necessarily stored as card numbers

Businesses often describe themselves as having customers' cards “stored”.

In modern payment systems, the merchant will often not store the customer's underlying card number directly.

Instead, the payment provider may store the sensitive card information in a secure vault and return a token that the merchant can use for future payments.

The merchant's system might therefore hold something such as:

Customer 123 → token ABC123

rather than:

Customer 123 → full card number

This can reduce the merchant's exposure to sensitive card information.

However, it creates an important switching question:

Does that token work only with the existing payment provider?

What is a payment token?

Tokenisation replaces sensitive payment information with a non-sensitive substitute that can be used to reference the underlying payment credentials.

However, the word token can describe different things.

A business might encounter:

• gateway tokens
• PSP or processor tokens
• vault tokens
• network tokens
• digital-wallet tokens.

These should not be assumed to behave in the same way when changing provider.

For more information about network-level tokenisation, see our Network Tokenisation guide.

Gateway token vs network token: what is the difference?

Gateway or PSP token

A payment gateway or PSP may store the underlying payment details within its own secure environment and give the merchant a token that references those details.

That token may be specific to that provider's platform.

Moving to another provider may therefore require the underlying payment information to be securely transferred and new tokens generated by the receiving provider.

Network token

A network token is issued through the card-network tokenisation ecosystem and represents the underlying card account.

Network tokenisation can offer benefits such as keeping payment credentials updated when the underlying card changes.

However, merchants should not assume that having network-tokenised cards means switching providers is automatically frictionless.

How network tokens are provisioned and supported can depend on the provider, acquirer and implementation.

Adyen, for example, distinguishes between its own PSP tokenisation and network tokenisation and currently states that its network-tokenisation implementation applies to payments acquired by Adyen rather than external acquirer connections.

View Adyen's network-tokenisation documentation.

The safest approach is therefore to ask the existing and proposed providers exactly what will happen to both stored credentials and associated tokens during migration.

Can payment tokens be transferred to another provider?

Sometimes, but it depends on the type of token and payment setup.

A merchant normally cannot assume that a token generated by Provider A can simply be entered into Provider B's platform.

The original token may only have meaning within Provider A's vault.

Instead, a payment migration may involve:

1. the outgoing provider securely exporting the underlying stored payment information
2. the receiving provider securely importing that information
3. the receiving provider creating new payment-method records or tokens
4. the merchant mapping the old customer or token references to the new ones.

This is why customer and token mapping can become an important part of the migration project.

Do customers need to enter their card details again?

Not necessarily.

If the existing provider can securely export the required payment information and the new provider can import it, existing customers may not need to re-enter their card details solely because the business has changed processor.

Stripe, for example, publishes a formal payment-data migration process designed to allow merchants to import stored customer and card information from another processor.

View Stripe's payment-data import documentation.

Adyen also provides a process for importing payment data from another payment service provider.

View Adyen's payment-data migration documentation.

Whether this is possible in an individual migration depends on both the outgoing and incoming providers and the payment methods involved.

Can stored card data be exported when you leave a provider?

This needs to be established with the provider concerned and by reviewing the relevant contractual and technical arrangements.

Different payment businesses have different migration processes.

Stripe, for example, currently states that its customers own the sensitive payment data entrusted to Stripe and that it can securely transfer eligible card data to another qualifying payment processor.

The receiving processor must meet Stripe's stated PCI DSS and secure-transfer requirements.

View Stripe's payment-data export process.

Businesses should establish their existing provider's approach before signing a replacement payment contract.

How is stored card data transferred securely?

Sensitive card information should not simply be downloaded by the merchant and emailed to its new payment provider.

Formal payment-data migrations are generally handled through secure processes between the relevant payment providers.

Depending on the providers involved, this may include:

• encrypted files
• PGP encryption
• secure provider-to-provider transfer
• PCI DSS validation of the receiving environment
• controlled import and mapping processes.

Stripe's current migration documentation warns merchants not to send sensitive card information directly and instead requires the use of its formal migration process.

Adyen likewise publishes technical and compliance requirements for payment-data migrations.

The migration should therefore be planned with the payment providers and relevant technical teams rather than treated as a normal customer-data export.

What happens to recurring payments when you change payment provider?

Moving recurring payments can involve more than transferring stored card information.

The business may also need to migrate or recreate:

• customer records
• subscription plans
• billing dates
• payment amounts
• customer references
• payment-method references
• merchant-initiated transaction information
• relevant historic transaction references
• retry settings
• failed-payment processes.

This is why payment-method migration and subscription migration should be treated as separate parts of the same project.

A merchant may successfully move customer card details but still need to rebuild or migrate the billing instructions that determine when and how those cards are charged.

For more information, see our Subscription Payment Processing guide.

Payment processor vs subscription platform

Some businesses use the same provider for both payment processing and subscription billing.

Others use separate systems.

For example, the payment stack might look like:

Website → subscription platform → payment gateway/processor → acquirer

In that setup, changing the payment processor does not necessarily mean changing the subscription platform.

Equally, changing the billing platform may involve a different migration project from changing the underlying processor.

Before starting the switch, identify:

• which system controls the subscription schedule
• which system stores the payment credentials
• which system holds the customer record
• which system initiates recurring charges
• which provider handles acquiring.

This payment map makes it much easier to understand what actually needs to move.

Do recurring-payment permissions move with the card data?

Businesses should not assume that moving the underlying card data or payment token alone contains everything needed to continue future recurring or merchant-initiated payments.

Recurring-payment processing can depend on additional information relating to the original customer payment and subsequent stored-credential transactions.

Migration planning should therefore establish what additional payment information the receiving provider requires.

Depending on the setup, relevant information can include:

• customer references
• stored-credential information
• original transaction references
• network transaction IDs
• authentication information
• recurring-payment classifications.

Stripe's current payment-method migration guidance, for example, includes specific requirements and considerations for migrated card data and recurring payments.

View Stripe's payment-method migration documentation.

What about cards that are updated during the migration?

A stored-card database is constantly changing.

During the migration period, customers may:

• replace lost cards
• receive replacement cards after expiry
• update their card details
• change their preferred payment method.

This creates a potential problem if the merchant takes a snapshot of payment data and then completes the migration several weeks later.

Updates made through the old provider during that period may not automatically be included within the original migration file.

Stripe specifically highlights this issue in its migration documentation and recommends planning for updates to saved payment methods during the transition.

This is one reason larger migrations may use a staged approach.

What is a staged payment migration?

Rather than moving every transaction and customer at exactly the same moment, businesses may operate the old and new systems alongside each other temporarily.

A staged migration could look like:

1. build and test the new gateway integration
2. send new customers through the new provider
3. continue charging some existing stored customers through the old provider temporarily
4. securely migrate existing payment credentials
5. map old customer and token IDs to the new provider
6. test migrated recurring payments
7. move remaining recurring transactions
8. retire the old payment setup.

Adyen's current migration guidance requires merchants to be able to perform tokenisation and recurring charging through two PSPs during the migration process.

This type of phased approach can reduce the risk of changing every element of the payment stack simultaneously.

Find Your New Processor

How long does a payment-data migration take?

There is no universal timeframe.

The time required can depend on:

• the outgoing provider
• the incoming provider
• the number of customer records
• payment methods involved
• quality of existing data
• encryption and compliance requirements
• integration work
• subscription complexity
• testing.

Payment-data migration should therefore be considered before the commercial cancellation date of the existing provider.

As provider examples, Adyen currently states that payment-data migration usually takes 10 days or more because of the technical and compliance work involved. Stripe notes that a previous processor may take from several days to several weeks to transfer the required data and currently says it typically completes its own import within 10 business days after receiving the correct files.

These are provider-specific examples rather than universal migration times.

Can every type of stored payment method be migrated?

No.

Businesses should identify exactly which payment methods are stored rather than assuming every credential can be transferred in the same way.

Migration support can vary for:

• standard stored cards
• Apple Pay
• Google Pay
• provider-specific wallets
• bank debits
• PayPal agreements
• Buy Now, Pay Later arrangements
• other local payment methods.

Stripe's current documentation provides an example of these differences.

Stripe states that payment credentials saved through Link cannot be transferred between processors. Its current import documentation also explains that cards stored through Google Pay cannot be migrated in the same way as standard card data, while Apple Pay has its own migration requirements.

View Stripe's payment-data export documentation.

View Stripe's payment-method import documentation.

This is another reason to complete a full inventory of payment methods before committing to a new provider.

Can you change acquirer without changing payment gateway?

Sometimes.

If the existing gateway supports the proposed new acquirer, the merchant may be able to change its acquiring relationship while retaining the gateway itself.

This can substantially change the migration project because parts of the checkout and payment infrastructure may remain in place.

Whether this is possible depends on:

• gateway compatibility
• the new acquirer
• Merchant IDs
• gateway contract
• token setup
• 3D Secure configuration
• technical integration.

Read our Acquirer-Agnostic Payment Gateways guide for more information about separating gateway and acquiring relationships.

Can you change payment gateway but keep the same acquirer?

Potentially.

The acquiring provider may support several gateway connections.

In that situation, the merchant account could remain in place while the technical gateway is changed.

Stored credentials and tokenisation may still need to be addressed because existing tokens could be tied to the old gateway or vault.

Changing only one part of the payment stack can therefore still require a payment-data migration.

What if you change both gateway and acquirer?

This is generally the more complex scenario.

The project can potentially involve changes to:

• merchant account
• Merchant ID
• payment gateway
• stored-payment vault
• tokens
• 3D Secure
• fraud configuration
• settlement
• reporting
• reconciliation
• recurring billing.

The technical, commercial and underwriting parts of the change should therefore be planned together.

Changing payment gateway for a subscription business

Subscription businesses should be particularly careful about payment-provider migration.

A business with a large number of active subscribers does not simply have a list of customer records.

It may also have:

• stored-payment relationships
• multiple subscription products
• different billing dates
• different pricing plans
• failed-payment states
• discounts
• customer credits
• retry schedules
• historic recurring-payment information.

The migration plan should therefore distinguish between:

moving the payment credentials

and:

moving the subscription logic.

Stripe, for example, treats payment-data migration and subscription migration as separate stages within its current documentation.

View Stripe's subscription migration documentation.

Changing payment gateway: migration checklist

1. Map your existing payment setup

• Who is the gateway?
• Who is the processor?
• Who is the acquirer?
• Who controls recurring billing?
• Where are card details stored?
• Which systems hold customer IDs?

2. Identify every stored payment method

• cards
• wallets
• bank payments
• PayPal or other agreements
• local payment methods.

3. Ask the existing provider about exports

Confirm:

• whether payment data can be exported
• which fields are available
• which payment methods are excluded
• how the secure transfer works
• how long the process normally takes.

4. Ask the new provider about imports

Confirm:

• which payment data can be imported
• how new tokens are created
• what recurring-payment data is required
• how customer records are mapped
• what testing is required.

5. Understand your subscription setup

Identify whether subscription schedules are managed by:

• the processor
• the gateway
• a separate billing platform
• your own software.

6. Plan for the migration window

Decide what happens to:

• new customers
• existing recurring customers
• customers updating their cards
• failed payments
• refunds
• chargebacks.

7. Test before closing the old account

Do not assume that a successful payment-data import means the complete migration has worked.

Test:

• new payments
• stored-card payments
• recurring transactions
• 3D Secure
• refunds
• reporting
• settlement
• reconciliation.

8. Agree the final cutover

Only retire the old payment setup once the business understands which transactions, customers and operational processes have successfully moved.

Find Your New Processor

Questions to ask a new payment provider before switching

• Can you import our existing stored card data?
• Which payment methods can and cannot be migrated?
• Will our customers receive new payment tokens?
• How do we map old references to new tokens?
• Can existing recurring customers continue without re-entering their cards?
• What recurring-payment information do you need?
• What transaction or authentication references need to be migrated?
• What happens to Apple Pay, Google Pay and other wallet credentials?
• How will card updates during the migration window be handled?
• Can we run the old and new providers alongside each other during migration?
• How long should we allow for the migration?
• What happens if some payment credentials fail to import?
• Who is responsible for the secure data transfer?
• How do we test migrated recurring payments?
• What happens to our payment data if we leave you in future?

That final question is worth asking before joining a provider rather than when trying to leave it.

Why payment portability should be considered when choosing a gateway

Most businesses choose a payment gateway based on what they need today.

It can also be worth considering how easy the payment setup would be to change later.

Before committing to a gateway, a growing business may want to understand:

• whether stored payment data can be exported
• whether the gateway is tied to one acquirer
• whether tokens are provider-specific
• whether multiple acquirers are supported
• whether subscription data is portable
• whether reporting data can be exported
• what happens to customer payment credentials if the contract ends.

These questions may not seem important when a payment account is first opened.

They can become extremely important several years later when the merchant has a large number of stored customers.

For a wider comparison of gateway structures, see our Best Payment Gateways for UK Businesses guide.

Payment orchestration and provider independence

Businesses with more complex payment requirements may choose to separate payment credentials from individual processors through a broader payment-orchestration or provider-independent vaulting strategy.

This can reduce some of the technical dependency created when customer credentials are held solely within one provider's ecosystem.

However, orchestration itself introduces another technology layer and should solve a genuine business requirement rather than simply add complexity.

Read our Payment Orchestration guide for more information.

How Merchant Advice Service helps businesses change payment provider

Merchant Advice Service helps businesses understand both the commercial and technical requirements involved in changing payment provider.

For businesses with stored cards or recurring payments, this can include looking at:

• existing gateway
• existing merchant account and acquirer
• stored-payment setup
• tokenisation
• subscription platform
• recurring-payment requirements
• website or software integration
• transaction volumes
• customer countries
• payment methods
• new-provider compatibility
• migration requirements.

The aim is to understand the whole payment setup before changing one part of it.

A lower transaction rate can have limited value if moving provider results in unexpected development work, lost recurring-payment functionality or customers having to re-enter stored payment details.

Businesses can also read our Compare UK Payment Providers guide.

About Merchant Advice Service

Merchant Advice Service is a UK business-to-business payments information, comparison and provider-matching service.

Founded in 2016, MAS helps businesses understand their payment requirements and identify payment providers or specialist partners that may be relevant to the way they operate.

Our payment guidance covers areas including:

• merchant accounts
• payment gateways
• provider switching
• integrated payments
• higher-risk merchant accounts
• international payments
• recurring payments
• specialist payment integrations
• more complex provider requirements.

Merchant Advice Service is not an acquiring bank or payment processor and does not make final underwriting decisions.

The MAS information, matching and introduction service is free to businesses. MAS may receive commission or a referral fee from some commercial partners where an introduction results in a completed product or account.

For full information about how the service operates, provider matching, independence and commercial relationships, read How Merchant Advice Service Works.

Find Your New Processor

Sources and reference links

Payment-data migration information in this guide was checked against primary payment-provider documentation in August 2026.

Stripe — payment-data imports

Stripe documentation covering secure migration of customer and stored card information from another payment processor.

Stripe: Request a Payment Data Import

Stripe — payment-data exports

Stripe documentation explaining secure export of eligible stored customer card data to another qualifying payment processor.

Stripe: Request a Payment Data Export

Stripe — payment-method migration

Technical guidance covering card imports, recurring payments and wallet migration considerations.

Stripe: Import Payment Method Data

Stripe — subscription migration

Stripe documentation covering migration of subscription data separately from the underlying payment information.

Stripe: Migrate Subscriptions

Adyen — payment-data migration

Adyen documentation covering migration of payment data from another payment provider.

Adyen: Import Data From Another Payment Provider

Adyen — network tokenisation

Adyen documentation explaining the distinction between provider tokenisation and network tokenisation.

Adyen: Network Tokenisation

SumUp — online and recurring payments

SumUp documentation covering Hosted Checkout, Payment Widget, APIs, stored cards and recurring online payments.

SumUp: Online Payments

SumUp: Hosted Checkout

Editorial and commercial disclosure

Merchant Advice Service is an independent payments information, comparison and provider-matching service.

Our editorial content may reference payment providers, technology companies and financial institutions regardless of whether Merchant Advice Service has a commercial relationship with them.

Where providers are named for comparison, research or technical examples, inclusion does not constitute a recommendation and should not be taken to mean that Merchant Advice Service can introduce businesses to that provider.

Stripe, Adyen and SumUp are referenced within this guide because their publicly available information provides useful examples of payment functionality or payment-data migration processes.

MAS may receive commission or a referral fee from some commercial partners where a business chooses to proceed following an introduction. Commercial relationships do not determine which providers may be referenced within our independent educational content.

Providers have not paid for inclusion in this article unless explicitly stated.

Payment-data portability, token migration, subscription migration and provider-switching processes vary according to the providers, payment methods and technical configuration involved.

Businesses should confirm migration requirements with both their existing and proposed payment providers before cancelling an existing payment service.

Merchant Advice Service does not make merchant-account underwriting decisions or guarantee provider acceptance.