Card token portability: moving saved cards between payment providers

Saved cards are the part of a payment stack that is hardest to move. A merchant can sign a new provider in a month and switch new customers to it in a day, but the thousands of customers who saved a card last year are still tied to the old provider’s vault. If those cards cannot follow, every renewal and repeat order either stays where it is or asks the customer to type the card again.

This article explains what token portability means in practice: which tokens can move and which cannot, how a card export works at Stripe, Adyen and Braintree, what the contract should say before you need it, and how to keep recurring payments approved through the move. For the wider plan of adding a provider, see adding a second PSP; for the difference between token types, see network tokens vs PSP tokens.

What actually moves when saved cards move?

Card numbers, not tokens. A token is a reference that only its issuer can resolve, so a migration always goes back to the underlying PAN and expiry date, moves those, and creates new tokens on the other side. Where the card data sits decides how hard that is.

Where the card number sits	Token you hold	Can another provider charge it?	What a move involves
One PSP’s vault	PSP token	No	Formal export of card data to a compliant receiver
Scheme token service, requested by a PSP	Network token	Usually only through that requestor	New tokens provisioned by the new requestor
A vault independent of the PSPs	Vault token	Yes, through every connected provider	Nothing, as long as the vault stays

EMVCo, which maintains the framework for network tokens, describes them as constrained in how they can be used, for example to a specific merchant, device or payment scenario. That restriction is what makes them safe, and it is also why they rarely travel. Adyen’s documentation is a concrete case: its network tokenization applies only to payments acquired by Adyen, although merchants can forward network tokens to a PCI-compliant third party such as another provider, and can use network tokens they already collect themselves.

How does a card data export work?

Through an encrypted file sent from one PCI DSS compliant party to another. The details differ by provider, so read the old provider’s rules before you choose the new one.

Step	Stripe (export)	Braintree (export)	Adyen (import)
Receiver requirements	PCI DSS Level 1 processor with an AOC or Visa registry listing	Attestation of PCI compliance from a qualified provider	Adyen is the receiver
Encryption	Receiver’s PGP key, 4096 bits or more, hosted over HTTPS on a domain in its AOC or listing	GPG-encrypted CSV, after Braintree verifies the receiver’s public key	File encrypted with a PGP key from Adyen
Transfer	Secure transfer arranged with the new processor	SFTP, SCP or FTP over SSL	Sent to Adyen; format rules include UTF-8 CSV, up to 1,000,000 lines and 1 GB
Number of exports	Not stated	No more than two: bulk and switchover	One result file per import, each line marked Success or Skipped
Fees	Not stated	None	None

Timelines depend on both ends. Stripe says a previous processor might take a few days or several weeks to transfer data, and that it typically imports within 10 business days of receiving correct data. Adyen says migrating payment data usually takes 10 days or more. Braintree says timelines vary with the complexity of the integration and are confirmed once all the required information is in.

Two details from these documents matter more than they look. Braintree does not run periodic backup exports, so a merchant who wants an up-to-date copy elsewhere has to arrange it another way. And Stripe warns that if customers update a saved card with the old provider between the data transfer and the import, those changes are lost unless the integration handles them.

What does not move?

More than most teams expect.

• CVV. The PCI SSC says card verification codes cannot be retained once the transaction they were collected for has been authorized, that storing them for card-on-file or recurring use is prohibited, and that a customer’s consent does not change this. No export contains a CVV, and none should.
• Payment history and subscriptions. Stripe says its export excludes payment history, subscriptions and other objects. Braintree says it cannot migrate subscription or transaction information. Billing schedules have to be rebuilt on the new side.
• Wallet credentials. Braintree excludes Apple Pay and Google Pay payment methods because the tokens behind them are not transferable between providers. Stripe excludes credentials saved through Link. Customers who paid with a wallet will pay with it again at the next checkout; see our article on Apple Pay and Google Pay.
• Network tokens requested by the old provider. Usually the new provider provisions its own from the migrated card numbers. Stripe’s import guide notes that some migrated data may be missing initial card validation details, such as the network token or the original transaction ID.
• Authentication results. 3-D Secure outcomes belong to past payments. Stripe’s import guide lists authentication_required among the declines that can follow when initial validation details are missing, so expect some issuers to ask for authentication again.

How do you keep recurring payments approved after the move?

By carrying the evidence of the customer’s original consent across with the card. Card schemes link each merchant-initiated payment to the first, customer-initiated one; our article on subscription payment recovery explains the credential-on-file framework. A migration breaks that link unless you move it too.

Adyen’s import format shows what is at stake. For Visa it asks for the Visa Transaction ID from the initial transaction where the shopper signed up, and says Visa stopped supporting a static value after 31 October 2022. For Mastercard it warns that not providing the Trace ID might result in soft declines and non-compliance assessment fees, and says the static dummy Trace ID is not supported after 19 October 2024.

Stripe’s guidance points the same way from the other side. It says imported cards on file must be labelled correctly, otherwise issuers that cannot confirm the cardholder’s consent may decline them, and the cards may be ineligible for card account updater and network tokens. It also warns that retrying many cards after a migration can look suspicious to issuers, and that a changed statement descriptor can trigger issuer risk models.

A sequence that respects all of this:

1. Ask for transaction IDs in the export. Original scheme transaction IDs per card, plus customer IDs and default card flags.
2. Freeze card updates or capture them. Route card changes to the new side during the window, or run a final delta export.
3. Map IDs. Stripe returns a mapping file from old IDs to new ones; update your records before the first billing run.
4. Flag every renewal as merchant-initiated, with the imported transaction ID.
5. Run the first billing cycle in batches, and watch expired card, do not honour and authentication-required declines by batch.
6. Keep the descriptor customers already know.

What should the contract say before you need it?

The time to negotiate an exit is at signing. Our RFP questions cover the evaluation; these are the clauses to put in writing:

Clause	What to ask for	Why
Right to export	Card data exportable on request, during and after the contract	Without it, an export depends on goodwill at exit
Receiver	Any PCI DSS compliant processor or vault you name	A narrow definition can block your preferred receiver
Fields	Card number, expiry, holder name, billing address, customer ID, original scheme transaction IDs	Without transaction IDs, renewals are at risk
Exports	At least a bulk export and a final delta	Braintree, for example, limits a migration to two
Timeline	A stated maximum, in business days	Published ranges run from days to several weeks
Fees	No fee, or a fixed one	Adyen and Braintree say they charge none
Network tokens	Who is the token requestor, and what happens to tokens on exit	Determines whether tokens survive the move
Access after exit	Continued access to transaction records	Stripe keeps data available if the account stays open

Worked example: migrating a subscription base

Example figures, for illustration only.

A software subscription business has 50,000 cards in its old provider’s vault. 3,000 are expired and left out, and 500 are skipped on import for missing data, so 46,500 arrive. 5,500 of those come without the original scheme transaction ID.

Group	Cards	First renewal approval	Approved
With transaction ID, flagged as card on file	41,000	92%	37,720
Without transaction ID	5,500	80%	4,400
Total	46,500	90.6%	42,120

If the 5,500 cards had carried their IDs and approved at 92%, 5,060 would have renewed, 660 more. At a 15 USD monthly plan that is 9,900 USD in the first month alone, before counting customers who never come back to update their card. The fix costs one column in the export file.

What are the common mistakes?

• Asking for the export at exit. By then the old provider has little reason to hurry. Agree the right, the fields and the timeline when you sign.
• Exporting card numbers without transaction IDs. The cards import cleanly and then decline on renewal.
• Expecting CVV, history or subscriptions in the file. They are not there; plan to rebuild billing schedules and keep the old account open for records.
• Forgetting the switchover window. Card updates made between export and import are lost without a delta export or a freeze.
• Retrying the whole base at once. A burst of declines and retries on newly migrated cards can look like fraud to issuers.
• Assuming network tokens come along. Ask who the requestor is; usually the new provider provisions new ones.

How does Omno help with card portability?

Omno Save Card stores cards as tokens in Omno’s PCI DSS compliant environment, at the orchestration layer rather than in one provider’s vault, so a saved card can be routed and cascaded to any eligible provider. Adding or replacing a provider then does not mean asking customers to re-enter cards. Whether a network token is used depends on the connected provider, and moving cards into or out of Omno’s vault still follows the export rules above, so agree those terms with Omno in writing. The tokenization and saved cards page has the details.