Moving Stored Cards Between Processors

There is no portability rule to appeal to

Merchants leaving a provider often assume a network rule entitles them to their vault. Visa's Core Rules and Product and Service Rules, in the 18 April 2026 public edition, do not address the transfer of stored credentials between providers at all. That silence is the finding. The leverage is contractual, which means it exists only if you negotiated it, and the moment to negotiate it is before integration rather than at cancellation. Ask for the exit terms in writing: whether the vault is exportable on request, to which destinations, on what notice, at what cost, in what format, and with what assistance in re-establishing the credentials on the far side. A provider that will not put that in the agreement has told you what the answer will be later.

What is actually in a vault

The PCI Security Standards Council describes tokenisation as a process by which the primary account number is replaced with a surrogate value called a token, and distinguishes single-use tokens, which typically represent one transaction, from multi-use tokens, which represent a specific PAN and always map that PAN to the same token value within the system. “Within the system” is the operative phrase. A multi-use token is meaningful only inside the vault that issued it, so what moves in a migration is not the tokens but the underlying account numbers, re-tokenised by the receiving provider. Network tokens are a different object again: EMVCo describes an EMV payment token as a unique alternative value that is constrained in how it can be used, for example to a specific merchant, device or payment scenario. Ask your provider which kind you hold before assuming anything about what a migration will carry across. Our tokenisation guide sets out the difference and the PCI scope conditions in full.

The credential chain has to survive the move

Visa's Table 5-22 sets out what has to be true of a transaction using a stored credential, and each item is a thing a migration can break. After a cardholder agreement has been completed in writing and before the first transaction occurs, the merchant must submit an authorisation request for the transaction amount, or an account verification if no payment is required, and must not store the credential if that request is not approved. A transaction with a stored credential must use POS entry mode code 10, and for a recurring, installment or unscheduled credential-on-file transaction must use the appropriate indicator in the POS environment field. Before processing a cardholder-initiated transaction the merchant must validate the cardholder's identity, for example with a login ID and password. And the authorisation amount must not exceed the individual transaction amount. A migrated credential that starts submitting on the new platform without the entry mode and indicator set correctly is not a formatting problem — it is a stored credential being processed outside the rule that permits it, and it shows up later as authorisation quality and dispute exposure. Our card-on-file guide covers those processing requirements in detail.

Your customer agreement already said this would happen

Table 5-20 requires the cardholder agreement to disclose the account number that will be used to make payment, last four digits only, “as it may be updated from time to time,” and how the cardholder will be notified of any changes to the agreement. It also requires the merchant to retain that information for the duration of the agreement and provide it to the cardholder or issuer on written request. A vault migration is a good moment to check that what you disclosed is what you are doing, and that you can still produce the agreement for a credential you took four years ago on a platform you are about to switch off. In the Europe Region there is an additional timing requirement for unscheduled credential-on-file transactions: notification of any change in the transaction amount or any other terms of the agreement at least 2 working days before the change.

Decommissioning the old vault is part of the job

The PCI Council's scoping guidance is explicit that all elements of the tokenisation system and process, including de-tokenisation and PAN storage, are in scope, and that for systems to be treated as out of scope one of the conditions is that systems which previously held cardholder data have been examined to confirm all traces were securely deleted. In a migration that condition applies to the provider you are leaving and to anything of yours that touched the export — staging servers, support mailboxes, a spreadsheet somebody made to reconcile the counts. Agree in writing, before the export runs, who deletes what and when, and get confirmation afterwards rather than assuming it. The Council's other recommendations point the same way: limit the existence of PAN to the point of capture and the card data vault, remove all cardholder data from source systems once tokenised, and review your use of tokens as part of annual PCI DSS scope validation.

An illustrative example of what falls through

Illustrative example, made-up round numbers. A subscription business with 5,000 stored cards migrates vaults. The export delivers 5,000 records; 200 have expired since the last successful charge and 100 belong to accounts already cancelled in the billing system but never deleted from the vault. The receiving provider re-tokenises all 5,000, and the first billing run on the new platform submits 300 charges that were never going to succeed. None of that is a migration failure — it is a reconciliation that was owed before the export. Count the credentials you actually intend to bill, match them to active subscriptions, and treat the difference as work to do first. Expect to re-establish, not merely re-point, anything the receiving provider cannot accept, and remember Table 5-22's rule: if the initial authorisation or account verification on the new platform is not approved, the credential does not get stored.