Payment Token Migration
Provider B asks one question: What kind of tokens? Until the merchant can answer, the migration plan is largely undefined. They may all appear in databases as strings. That does not make them interchangeable. EMVCo itself distinguishes EMV payment tokenisation from other forms of
Payment Token Migration: How to Move Stored Payment Credentials Between Providers
A merchant has two million stored “card tokens.”
Provider B asks one question:
What kind of tokens?
Until the merchant can answer, the migration plan is largely undefined.
They may all appear in databases as strings.
That does not make them interchangeable.
EMVCo itself distinguishes EMV payment tokenisation from other forms of tokenisation and notes that an EMV Payment Token can be constrained to a specific merchant, device, or payment scenario. EMVCo also defines a Token Service Provider role responsible for issuing those payment tokens.
So payment token migration does not begin with:
export token column → import token column.
It begins with:
What credential does this reference represent, which system can resolve it, under what domain is it valid, and can the destination create a usable payment credential without exposing raw card data unnecessarily?
That is the real migration problem.
Start by retiring the word “token” as a sufficient specification
During migration planning, a data dictionary containing:
customer_id
card_token
is not enough.
The merchant needs to know what card_token means.
At minimum, distinguish four broad credential families.
PSP or processor vault token
A provider-specific reference points to payment credentials held inside that provider's environment.
Conceptually:
Merchant
→ tok_A_123
→ Provider A vault
→ underlying payment credential
Provider B usually cannot infer anything useful from tok_A_123 unless an explicit migration mechanism exists between the relevant systems.
The token value itself may contain no portable payment information.
Its usefulness comes from who can resolve it.
Merchant-controlled or independent-vault token
The merchant may instead store a reference into infrastructure it controls or has deliberately separated from the PSP.
Conceptually:
Merchant payment profile
→ credential_847
→ credential vault
→ underlying account credential
Then different PSP integrations may consume an appropriately released/tokenized version of that credential according to the vault, provider, network, and security architecture.
This can improve architectural portability.
It does not mean the merchant should casually retrieve raw PANs during provider changes.
If merchant systems store, process, or transmit cardholder data, PCI DSS becomes directly relevant. PCI SSC's current PCI DSS page identifies entities that store, process, or transmit cardholder data—or can affect the security of the cardholder-data environment—as within the standard's intended audience.
Network payment token
An EMV payment token is different again.
EMVCo describes payment tokens as alternatives to the PAN that can flow through payment acceptance and authorisation infrastructure while being restricted in how they can be used.
Visa's current token-service documentation provides one concrete implementation example: Visa describes payment tokens that can be limited to a specific device, e-commerce merchant, or other defined use context, with a token requestor participating in provisioning.
That leads to a crucial migration rule:
A network token should not be assumed portable merely because it looks structurally like a payment-card number.
The important questions include:
Who is the token requestor?
What domain controls apply?
Which merchant identity is associated?
Which destination PSP/acquirer can process it?
Does migration require transfer, reassignment, reprovisioning, or creation of a new token?
Those answers are network- and implementation-specific.
Wallet or platform credential
Wallets introduce their own terminology and lifecycle.
Apple, for example, currently distinguishes device-specific Apple Pay payment tokens used for individual transactions from merchant tokens designed for recurring, deferred, and automatic-reload use cases. Apple says a merchant token associates a payment card, merchant, and user and provides lifecycle-management mechanisms for those tokens.
That is another warning against a universal migration strategy.
A wallet credential should be handled according to:
Wallet/platform model
merchant identity
provider integration
transaction type
credential lifecycle
not merely copied because the database field happens to contain a token-shaped value.
Token reference and underlying credential are different objects
This distinction should drive the architecture.
Consider:
Merchant credential ID
↓
Source provider token
↓
Underlying payment credential
After migration, the desired architecture may become:
Same merchant credential ID
↓
Destination provider token
↓
Same underlying customer payment relationship
The merchant identifier can remain stable even when the provider reference changes.
That is usually much safer than allowing every subscription, order, retry job, and customer record to use the PSP token itself as permanent identity.
Conceptually:
merchant_credential_id = cred_847
source_provider_token = tok_A_123
destination_provider_token = tok_B_981
The merchant application continues referencing:
cred_847
The provider adapter resolves the currently usable provider credential.
This is one of the cleanest ways to separate:
customer/payment identity
from:
provider-specific credential identity.
Build a credential inventory before asking whether migration is possible
Do not treat two million stored records as one migration population.
Segment them.
Useful dimensions include:
Token type
source provider/vault
payment network
merchant entity
market
customer/account
one-time versus reusable
recurring relationship
wallet versus direct card
network token versus vault reference
active versus dormant credential
most recent successful use
destination provider compatibility
The first output should therefore not be:
2,000,000 tokens to migrate.
It should look more like:
Credential population
Count
Type
Migration route
Population A
Merchant-specific
PSP vault references
Provider migration process required
Population B
Merchant-specific
Network tokens
Token-domain compatibility must be established
Population C
Merchant-specific
Independent-vault references
Destination provisioning path required
Population D
Merchant-specific
Wallet merchant credentials
Platform/provider compatibility review
Population E
Merchant-specific
Expired/dormant
Business decision before migration
Do not invent migration work for credentials the business no longer needs.
Step 1: identify who can resolve the credential
For every credential population ask:
Which system turns this reference into something usable for payment?
Possible answers include:
Source PSP
independent vault
merchant vault
network Token Service Provider
wallet/platform
another credential service
This is more precise than asking:
Who owns the token?
Ownership can be contractual, technical, or operational.
For migration engineering, the most important fact is usually:
Who has the technical authority and capability to resolve, transfer, reprovision, or re-tokenize the credential?
If the answer is:
only Provider A
then copying the token string to Provider B solves nothing.
Step 2: establish the credential's validity domain
Next ask:
Where is this credential valid?
Possible domains include:
One provider
one merchant
one merchant entity
one token requestor
one device
one wallet
one transaction context
broader network infrastructure subject to network controls
EMVCo's current guidance explicitly emphasizes this domain concept: an EMV payment token is designed so that compromised token information may be unusable outside the merchant, device, or payment scenario for which it was provisioned.
That security property is exactly why portability cannot be assumed.
A token being less portable than the PAN it replaces may be intentional.
Step 3: define the destination capability
Now evaluate Provider B.
Do not ask:
Can Provider B store cards?
Ask:
Can Provider B accept this credential population through an approved migration or provisioning path?
For each population verify:
Credential/token type
supported source
supported card/network population
merchant identity requirements
destination account/entity
import mechanism
required metadata
recurring-payment applicability
validation process
security/compliance prerequisites
There can be several outcomes.
Directly migratable
An approved source-to-destination process exists.
Reprovisionable
The old token itself is not imported, but the underlying credential can be securely transformed into a new destination credential.
Conditionally portable
Only a subset qualifies because of network, merchant, card, geography, or account conditions.
Customer action required
The merchant cannot move the existing credential and needs the customer to provide or reauthorize a payment method.
Not worth migrating
Dormant, expired, or commercially irrelevant credentials can potentially be left behind under an appropriate legacy strategy.
That classification is more useful than:
portable = yes/no.
Export success is not migration success
Suppose Provider A exports:
1,900,000 records.
Provider B imports:
1,880,000 records.
Has the migration succeeded?
Not yet.
Those numbers establish movement of records.
They do not establish that those credentials can successfully support the payment operations for which they are needed.
A stronger migration funnel is:
Eligible credential
↓
Exported
↓
Imported / reprovisioned
↓
Mapped
↓
Technically validated
↓
First intended payment attempted
↓
Recurring/payment continuity validated
Each stage needs its own denominator.
Migration success and payment validation are different
A destination system might accept a credential record syntactically while later payment use fails.
Potential reasons include:
Credential type incompatible with destination use
merchant/token domain mismatch
recurring context unavailable
stale account information
destination configuration
network/provider restrictions
incomplete metadata mapping
So define:
Import success rate
Credentials accepted by destination migration process
÷
eligible exported credentials submitted for import
and separately:
Validation success rate
Imported/reprovisioned credentials that pass the merchant's defined validation procedure
÷
credentials selected for validation
The validation procedure must be designed carefully.
Do not create unnecessary live charges merely to prove token viability.
Use provider/network-supported validation mechanisms and controlled production testing where appropriate.
Do not confuse token migration with subscription migration
This is one of the most important operational boundaries.
A subscription contains more than a payment credential.
It can contain:
Customer
plan
amount
currency
billing cadence
next billing date
trial status
discounts
retry state
cancellation state
merchant consent records
payment credential reference
Moving:
token_A → token_B
does not move:
the subscription.
Conceptually:
Subscription S-123
customer = C-44
plan = PRO
next_bill = ...
credential = cred_847
The migration goal should be to preserve:
cred_847
while changing its usable provider representation.
Then the merchant's subscription system can continue pointing to the same merchant credential identity.
If the subscription itself resides inside Provider A rather than in the merchant's own systems, that becomes a broader provider migration problem.
That public documentation demonstrates why recurring architecture must be inventoried separately from credential architecture: a merchant moving away from a provider-managed recurring product may need to recreate schedule/state as well as address credential portability.
First renewal is a more meaningful migration milestone
For stored credentials used in subscriptions, one of the strongest post-migration measures is:
First-renewal success after migration
Successfully completed first scheduled renewals using migrated credentials
÷
eligible first scheduled renewals attempted using migrated credentials
This should be segmented carefully.
A failed renewal does not automatically mean the credential migration failed.
Renewals can fail for ordinary payment reasons.
Compare results with appropriate baselines and inspect failure classifications.
The purpose is to answer:
Did credentials that were supposed to preserve customer continuity actually function when the business depended on them?
Do not use raw card data as the casual migration fallback
When teams discover provider tokens are non-portable, a dangerous idea can appear:
Let's export the card numbers and upload them ourselves.
That should never become the casual engineering default.
Handling underlying PANs changes the security boundary materially. PCI SSC's current PCI DSS applies to entities that store, process, or transmit cardholder data or can affect the cardholder-data environment.
Sensitive authentication data has still stricter treatment. PCI SSC currently states that card-verification values such as CVV2/CVC2/CID are sensitive authentication data and must not be stored after authorization, even if encrypted.
So a secure migration should favor an approved process involving the relevant:
Source provider/vault
destination provider/vault
qualified payment-security personnel
payment-network or token-service mechanisms where relevant
rather than routing underlying payment-account data through general merchant applications, spreadsheets, object storage, support tickets, or developer laptops.
The migration mechanism is a security design.
Not a CSV operation.
Separate the control file from the credential payload
A useful migration architecture separates:
Migration control data
Merchant-safe identifiers and process status such as:
merchant_credential_id
customer_id
source_reference
migration_population
migration_status
destination_reference
validation_status
from:
Sensitive credential transfer
Handled through the approved secure provider/vault/network mechanism.
This gives Engineering and Operations visibility into the migration without requiring routine access to underlying card data.
A control table might contain:
Merchant credential
Source ref
Destination ref
Status
cred_001
src_9...
dst_4...
Validated
cred_002
src_1...
—
Import failed
cred_003
src_7...
dst_8...
Awaiting validation
The merchant can therefore manage the migration operationally while keeping sensitive transfer mechanics inside the approved security boundary.
Preserve mapping between source and destination credentials
Do not overwrite the old reference immediately.
During migration, retain a mapping:
merchant credential ID
├── source provider credential
└── destination provider credential
At least while operationally required.
Why?
Because the merchant may still need the source provider for:
Legacy transaction lookup
refunds
disputes
pending payments
reconciliation
rollback
The original charge processed through Provider A does not magically become a Provider B transaction because the customer's future credential has moved.
Credential migration affects future reusable payment access.
It does not rewrite historical payment lineage.
Payment state and credential state are separate
A credential can be:
Active
migration-eligible
exported
imported
validation-pending
validated
failed migration
customer re-entry required
retired
while a customer's payments independently move through:
Created
authorized
completed
failed
refunded
Do not use one state model for both.
A useful merchant architecture might contain:
payment_credential
id
customer_id
type
status
credential_binding
credential_id
provider
provider_reference
binding_status
Then one logical merchant credential can have temporary bindings to both source and destination during migration.
That is often cleaner than replacing the token field in-place and losing migration history.
Network-token populations need their own migration plan
Do not mix network tokens and PSP vault tokens in one export batch merely because both represent cards.
For network-token populations, determine:
Network
TSP/token-service context
token requestor
domain controls
merchant identity
destination processing support
lifecycle ownership
reprovisioning requirements
EMVCo's framework explicitly recognizes the Token Service Provider as the entity that issues EMV payment tokens and supports their lifecycle.
Visa's implementation likewise describes token provisioning as involving token-requestor and issuer/token-service interactions, with use potentially constrained to a merchant or device.
Therefore:
Network-token migration may be a token-lifecycle operation, not a database-export operation.
Do not prescribe a universal technique without verifying the relevant network and providers.
Wallet credentials need their own category too
Apple Pay illustrates why the label wallet token is insufficient.
Apple currently distinguishes device-specific payment tokens from merchant tokens that support recurring, deferred, and automatic-reload use cases across a customer's devices.
Its merchant-token management API also exposes lifecycle events and the ability to invalidate merchant tokens associated with the merchant identifier.
A migration inventory should therefore record:
Wallet/platform
token/credential subtype
merchant identity
recurring applicability
provider processing path
lifecycle-management integration
Do not automatically feed wallet credentials into a PSP-vault token migration workflow.
Validate mapping before moving recurring volume
A migration script can produce syntactically valid destination references while pairing one with the wrong customer.
That is one of the worst migration failures because the database may look healthy.
Use strong mapping controls.
Potential merchant-side checks include:
Unique merchant credential ID
unique source reference
destination reference uniqueness
customer/account match
expected card metadata where safely available
token/network metadata where supported
migration batch
cryptographic/file-integrity controls in the approved migration process
reconciliation counts
Never use full PAN as an ordinary business-system matching key.
The mapping needs to prove:
This destination credential belongs to the same merchant customer/payment relationship represented by this source credential.
Do not validate only the easy credentials
Suppose the migration team validates 100 newly stored cards.
All work.
But the population also contains:
Credentials stored five years ago
inactive customers
recurring accounts
several merchant entities
multiple countries
wallet credentials
network tokens
cards last used through legacy integration versions
The validation sample should reflect the actual credential populations.
Use stratification where appropriate:
Source type
age
merchant entity
network
geography
recurring status
destination migration path
Do not publish an arbitrary sample percentage as universally adequate.
The sample needs to test the risks of the actual migration.
Migrate in stages
A sensible credential migration program normally benefits from controlled stages rather than treating the database as one indivisible object.
A conceptual sequence is:
Phase 1 — Inventory
Classify credential populations and dependencies.
Phase 2 — Eligibility
Determine which populations can move and how.
Phase 3 — Migration design
Agree source, destination, security, mapping, and validation procedures.
Phase 4 — Pilot
Move a deliberately selected test cohort.
Phase 5 — Validate
Verify mapping, destination usability, state, and operational tooling.
Phase 6 — Controlled production use
Begin using migrated credentials for an appropriate traffic cohort.
Phase 7 — Expand
Move additional populations according to evidence and guardrails.
Phase 8 — Observe first renewals
Measure actual recurring continuity.
Phase 9 — Customer recovery
Handle non-portable or failed credentials through controlled re-entry/reauthorization.
Phase 10 — Retire source credential dependency
Only once legacy operational requirements are satisfied.
That last step may occur considerably later than:
new-payment traffic moved to Provider B.
Build rollback into the credential mapping
A provider migration can discover problems after destination credentials have already been created.
If the source credential remains valid and contractual/security arrangements permit continued use during the transition, a merchant-controlled mapping can make rollback less destructive.
Conceptually:
cred_847
primary_binding:
Provider B / dst_981
legacy_binding:
Provider A / src_123
That does not mean the merchant should automatically retry failed payments at Provider A.
Routing, retries, stored-credential rules, authentication, and provider contracts still apply.
It means migration architecture has not destroyed the information needed to respond.
Identify customer-action populations early
Some credentials will not migrate.
The mistake is discovering those customers on renewal day.
Classify them before cutover:
No-action population
Migration/reprovisioning path exists.
Validation-required population
Credential moved but needs controlled verification.
Reauthentication/reauthorization population
Additional customer action may be necessary depending on the payment method and rules.
Payment-method re-entry population
Customer must provide another usable credential.
Then the business can decide how to handle customer continuity.
The goal of token migration is not:
zero customer interaction at any cost.
It is:
minimize unnecessary customer disruption while refusing to manufacture portability where the credential architecture does not support it.
Customer re-entry rate should be measured
Define:
Customer re-entry rate
Customers required to supply or reauthorize a payment credential because their existing credential could not be migrated into a usable destination state
÷
customers within the relevant migration population
Segment by reason:
Non-portable provider token
network/domain restriction
stale/invalid credential
import failure
unsupported wallet/credential
customer action required for another reason
This tells the merchant where migration architecture becomes customer friction.
Unmapped credentials are an operational exception
After source export and destination import, every eligible source credential should be accounted for.
Track:
Unmapped credential rate
Eligible exported credentials without a confirmed merchant-to-destination mapping
÷
eligible exported credentials
Do not hide them inside a generic:
migration failed
count.
Investigate whether the cause was:
Duplicate source records
malformed record
missing customer identifier
unsupported credential
destination rejection
transfer-file issue
mapping bug
An unmapped credential is not merely a technical error.
For a recurring merchant, it represents a future payment that may not have a usable credential.
The Payment Token Migration Readiness Matrix
Before migration, complete this for each credential population.
Dimension
Question
Token type
PSP vault token, merchant/vault token, network token, wallet/platform credential, or something else?
Resolver / control point
Which system can convert or use this reference?
Source
Which provider, vault, network, or platform currently controls the usable representation?
Validity domain
Provider, merchant, token requestor, device, wallet, transaction context?
Destination compatibility
Can the destination directly use, import, or reprovision it?
Export method
What approved source mechanism exists?
Import/provisioning method
How does the destination create its usable credential?
Customer action
None, validation, reauthorization, or full re-entry?
Security process
Who handles underlying CHD and under what reviewed controls?
Recurring implication
Does the existing recurring relationship remain usable?
Subscription implication
Does separate billing schedule/state also need migration?
Validation plan
How will merchant prove mapping and usability?
Rollback/legacy plan
When can the source binding actually be retired?
Classification can then be:
READY
Credential type and controlled migration path are understood and tested.
READY WITH REPROVISIONING
The original token cannot simply move, but a supported destination credential can be created.
CUSTOMER ACTION REQUIRED
No acceptable credential-preserving migration path exists.
SECURITY / CONTRACT REVIEW REQUIRED
Transfer may involve underlying account data or rights/processes that have not been approved.
NOT MIGRATION-ELIGIBLE
Credential is expired, dormant, unsupported, or intentionally excluded.
This gives the migration team something far more useful than:
“Provider says token migration is supported.”
Measure the migration funnel
Use separate metrics rather than one inflated success percentage.
Eligible token population
Credential records meeting the defined migration criteria
The denominator should exclude records deliberately outside scope.
Export success
Eligible credentials successfully included in the approved source migration process
÷
eligible credentials scheduled for export
Import / reprovisioning success
Destination credentials successfully created or accepted
÷
eligible source credentials submitted to the destination process
Mapping success
Destination credentials successfully connected to the correct merchant credential identities
÷
destination credentials created/imported
Validation success
Mapped destination credentials passing the merchant's defined validation process
÷
mapped credentials selected/required for validation
First-renewal success
Successful first scheduled recurring payments on migrated credentials
÷
eligible first recurring attempts made using migrated credentials
Do not interpret all payment declines as migration failures without causal investigation.
Customer re-entry rate
Customers requiring credential re-entry or reauthorization
÷
customers in the applicable migration population
Unmapped credential rate
Eligible migrated/exported source credentials lacking a confirmed usable destination mapping
÷
eligible credentials expected to be mapped
Each metric answers a different question.
Decommission only after customer and financial continuity are proven
The source provider may stop receiving new transactions long before its credential infrastructure can be ignored.
Before deleting source mappings or closing migration access, verify:
All planned credential populations accounted for
outstanding mapping exceptions resolved
destination validation complete
sufficient recurring cycles observed for the merchant's risk tolerance
customer re-entry workflow operating
legacy refunds/disputes still supported where necessary
finance/reconciliation dependencies understood
data-retention/deletion obligations reviewed
rollback requirement ended
source provider exit process completed
Credential migration is complete when:
future customer payment relationships no longer depend unintentionally on the source credential system
—not merely when:
the export file was processed.
Portability should become an architecture requirement before the next migration
The most useful lesson from a difficult token migration is not:
next time, negotiate a better export.
It is to examine why the merchant did not know what its credential references meant.
A portable architecture should be able to answer at any point:
What credential types do we hold?
Who can resolve them?
Which PSPs depend on provider-specific references?
Which are network tokens?
Which are wallet credentials?
Which customer/subscription records depend on each?
What would migration require?
Which information belongs to the merchant and which belongs to the provider?
How would we move without exposing raw card data unnecessarily?
That does not require avoiding every provider-specific capability.
A provider-specific token may deliver significant value.
Lock-in becomes an architectural problem when the merchant adopts that dependency without understanding the cost of leaving it.
That broader assessment belongs in Avoiding PSP Lock-In.
The credential should move without rewriting the merchant's payment identity
The cleanest migration does not make the rest of the company care that:
Provider A token
became:
Provider B token.
Customer Support should still see the same customer.
The subscription system should still point to the same merchant credential.
Finance should still distinguish historical Provider A payments from new Provider B payments.
Payment state should still use merchant-controlled identifiers.
The migration layer should absorb the provider-reference change.
Conceptually:
Customer
↓
Merchant Credential ID
↓
Credential Binding
├── Provider A reference
└── Provider B reference
That architecture does not make credentials universally portable.
It makes portability boundaries explicit.
And that is the point.
Final recommendation: classify first, migrate second
The hard part of payment token migration is rarely moving strings.
It is identifying what those strings mean.
A merchant changing providers should therefore resist starting with:
How do we export the tokens?
Start with:
What credential populations exist?
What type is each one?
Which system resolves it?
Where is it valid?
Can the destination use or reprovision it?
What secure mechanism moves the underlying payment relationship?
What merchant identifier remains stable?
What recurring or subscription state is separate from the credential?
How will mapping and usability be validated?
Which customers will still need to act?
When can the source finally be retired?
The governing principle is:
Token migration begins with credential identity and validity—not data export.
A string can be copied anywhere.
A payment credential can only be used where its security model, token domain, provider capabilities, merchant relationship, and applicable payment rules permit it.
Build the migration around those boundaries and the merchant can preserve customer continuity without turning a provider change into an uncontrolled card-data project.
This article provides general information and does not constitute legal, regulatory, security, PCI, card-network, or compliance advice. Token portability, cardholder-data handling, stored-credential requirements, network-token behavior, customer authorization, and migration mechanisms vary by provider, vault, network, payment method, merchant configuration, and jurisdiction. Merchants should verify current requirements and migration procedures with qualified payment-security specialists, relevant payment providers, acquirers, networks, token-service providers, wallets/platforms, and other applicable parties.
🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂
I used the uploaded Editorial Brief 14 — Payment Token Migration as the controlling brief. The article owns reusable payment-credential portability: identifying what the stored token actually represents, determining whether the destination can use it, moving or reprovisioning credentials securely, mapping old and new references, validating them, and preserving recurring-payment continuity. The broader PSP cutover belongs in Migrating Payment Providers, while architectural dependence belongs in Avoiding PSP Lock-In.
Brief interpretation
Editorial decision
Interpretation
Merchant engineering problem
A PSP migration reaches the stored-credential population and the merchant discovers that “token” describes several fundamentally different objects with different portability boundaries.
Evidence anchor
A value that looks reusable may only have meaning inside the provider, vault, token-requestor, merchant, device, or domain that created it.
Primary system boundary
Source credential system → controlled migration mechanism → destination credential system → merchant credential mapping.
Primary distinction
Moving a token reference is not necessarily moving the underlying payment credential.
Unsafe assumption
“A token is a substitute card number, so Provider B should be able to use Provider A's token.”
Editorial position
Identify credential type and validity domain first; design the secure migration second; prove payment continuity before retiring the source.
Merchant decision
Which credential populations are actually portable, by what approved mechanism, with what customer/recurring-payment impact?
Format
Credential-portability workflow + Payment Token Migration Readiness Matrix.
Most important metric
Validation success and first-renewal success—not export success alone.
ARTICLE — PUBLICATION COPY
SEO & EDITORIAL NOTES — NOT PART OF THE ARTICLE
SEO metadata
H1: Payment Token Migration: How to Move Stored Payment Credentials Between Providers
Meta description: Learn how to migrate payment tokens between PSPs by identifying token types, portability boundaries, secure export/import paths, recurring-payment dependencies, validation requirements, and customer re-entry risks.
Suggested URL slug: /payment-token-migration/
Secondary keywords:
migrate payment tokens
credit card token migration
PSP token migration
payment vault migration
stored card migration
payment credential migration
network token migration
migrate recurring payment tokens
Related entities: tokenization, payment credential, PSP token, vault token, EMV payment token, network token, Token Service Provider, token requestor, PAN, card-on-file, recurring payment, credential vault, Apple Pay merchant token, PCI DSS.
Article excerpt: Payment-token migration starts by identifying what each stored credential reference actually represents. PSP vault references, independent-vault tokens, network tokens, and wallet credentials have different validity and portability boundaries. Merchants should classify each population, establish an approved migration path, map old and new references through a stable merchant credential ID, validate destination usability, and measure recurring-payment continuity before retiring the source provider.
Structured data
Recommended:
TechArticle
BreadcrumbList
ImageObject
No generic FAQ is needed. The Payment Token Migration Readiness Matrix should be the central search/editorial asset.
Supporting visual
Payment Token Migration Workflow
STORED “TOKENS”
↓
CLASSIFY CREDENTIAL
↓
┌───────────────┬────────────────┬──────────────┬─────────────────┐
│ PSP VAULT │ MERCHANT VAULT │ NETWORK │ WALLET/PLATFORM │
│ REFERENCE │ REFERENCE │ TOKEN │ CREDENTIAL │
└───────────────┴────────────────┴──────────────┴─────────────────┘
↓
WHO CAN RESOLVE IT?
↓
WHERE IS IT VALID?
↓
DESTINATION COMPATIBLE?
↓
┌────────────────┬──────────────────┬─────────────────┐
│ DIRECT MIGRATE │ REPROVISION │ CUSTOMER ACTION │
└────────────────┴──────────────────┴─────────────────┘
↓
SECURE TRANSFER
↓
MAP TO STABLE MERCHANT CREDENTIAL ID
↓
VALIDATE
↓
CONTROLLED PRODUCTION USE
↓
FIRST RENEWAL / CONTINUITY CHECK
↓
RETIRE SOURCE DEPENDENCY
Prominent side callout:
TOKEN REFERENCE ≠ UNDERLYING CREDENTIAL
And:
IMPORT SUCCESS ≠ PAYMENT VALIDATION
Image alt text: “Payment Token Migration Workflow showing classification of PSP vault tokens, merchant vault references, network tokens and wallet credentials, followed by validity-domain analysis, destination compatibility, secure migration or reprovisioning, merchant credential mapping, validation, first-renewal testing and source retirement.”
Internal-link recommendations
Recommended anchor
Destination
Boundary
migrating payment providers
Migrating Payment Providers
Owns complete PSP transition, traffic ramp, legacy transaction lifecycle and decommission
avoiding PSP lock-in
Avoiding PSP Lock-In
Owns designing provider dependencies and portability before migration is needed
payment state management
Payment State Management
Owns merchant payment IDs and canonical transaction state
recurring payment architecture
Relevant Subscription Operations content
Useful secondary link where credential continuity affects renewals
The first three are the brief's priority links.
Authoritative source recommendations
EMVCo
EMVCo should be the primary neutral technical source for network-token terminology. Its current Payment Tokenisation material distinguishes EMV Payment Tokens from other tokenisation forms, describes the Token Service Provider role, and explains that payment tokens may be constrained to particular merchants, devices, or payment scenarios.
This is strong evidence for the article's central claim:
token form does not establish token portability.
Visa
Visa's current token-service material can be used narrowly as a network-specific example of token provisioning, token requestors, and use restrictions. Visa says its payment tokens can, depending on use case, be constrained to a specific mobile device, e-commerce merchant, or usage context.
Do not generalize Visa's implementation details into rules for other networks.
PCI SSC
Use PCI SSC's current PCI DSS material for security-boundary statements. PCI SSC says PCI DSS is intended for entities that store, process, or transmit cardholder data or affect the security of the CDE.
Its current FAQ also states that CVV/CVC/CID data is Sensitive Authentication Data and may not be stored after authorization.
That is sufficient to support the article's warning against turning migration into ad-hoc raw-card-data handling.
Apple
Apple is useful for demonstrating that even one wallet platform has multiple token concepts. Apple currently distinguishes device-specific payment tokens from merchant tokens for recurring/deferred/automatic-reload use and exposes lifecycle-management capabilities for merchant tokens.
None of those public pages currently proves reusable stored-card token export/import portability.
Technical fact-check items
For each credential population, establish:
Exact token/credential type
Issuing/resolving system
Underlying credential type
Merchant/entity binding
Token-requestor identity where applicable
Network
Wallet/platform where applicable
Reusability
Domain restrictions
Expiration/lifecycle behavior
Source export mechanism
Destination import mechanism
Reprovisioning alternative
Customer-action requirement
Recurring applicability
Required stored-credential metadata
Destination validation process
Deletion/retirement process
Do not label a population simply card_tokens.
Migration and token fact-check items
Before migration, obtain explicit answers from both source and destination parties:
Source
Does the merchant have contractual rights to migrate the credential population?
What credential types can be migrated?
Is migration direct provider-to-provider?
Does the source ever disclose PAN to the merchant?
What secure transfer mechanism is used?
Which metadata accompanies each credential?
How are failed exports reported?
What identifiers remain available after departure?
How long is legacy access maintained?
Destination
Which source providers/vaults are supported?
Which token types can be imported directly?
Which require reprovisioning?
Are network tokens supported?
Are wallet credentials included?
What merchant/entity configuration must match?
How is imported credential identity returned?
How is validation performed?
How are failures classified?
Recurring-payment continuity checks
For recurring populations, verify separately:
Customer authorization/consent basis
merchant/entity relationship
network or payment-method stored-credential requirements
source credential type
destination credential type
recurring transaction indicators
billing schedule ownership
retry state
next payment date
cancellation state
token lifecycle updates
account-updater/network-token behavior where relevant
Do not equate:
credential successfully imported
with:
subscription successfully migrated.
Security fact-check items
A security/PCI specialist should review any design involving:
PAN export
PAN import
de-tokenization
temporary credential staging
encryption keys
secure file transfer
vault-to-vault transfer
logging of migration payloads
backups
test environments
access controls
data deletion after migration
PCI SSC's current framework makes clear that systems storing, processing, or transmitting cardholder data fall within the relevant security boundary.
Also verify that migration data contains no stored CVV/CVC/CID; PCI SSC currently prohibits post-authorization storage of those values.
Do not put underlying card credentials in ordinary spreadsheets, issue trackers, chat systems, source repositories, developer laptops, or general application logs.
Brick supports client-side tokenization.
The documented Brick token on the form-creation page is explicitly one-time and short-lived.
Brick and Checkout provide subscription/recurring-payment functionality.
What are those objects called?
Are they distinct from Brick one-time tokens?
Which source PSPs/vaults are supported?
Under what commercial/security process?
Are network tokens supported?
Can network tokens be retained when the acquiring/PSP path changes?
Can wallet merchant credentials be maintained across processor migration?
Is billing schedule/state export available?
Can recurring credentials be migrated independently from subscription objects?
Which merchant identifiers must remain unchanged?
What validation mechanism exists after import?
What reporting exposes imported credentials?
How are failed imports surfaced?
What is the legacy-refund/dispute process after outbound migration?
Until those questions are answered, avoid statements such as:
or:
The current public sources do not establish those claims.
Payment Token Migration Readiness Matrix
A publication-ready downloadable/checklist version should use:
Population
Token type
Resolver
Validity domain
Destination compatibility
Transfer method
Customer action
Recurring impact
Validation
Status
A
PSP vault
Provider A
Provider A
TBD
Provider process
TBD
High
Pilot + renewal
Review
B
Network token
TSP/network
Merchant/domain-specific
TBD
Lifecycle/reprovisioning
TBD
High
Network/provider test
Review
C
Merchant vault
Merchant/vault
Defined merchant scope
TBD
Vault provision
Low/TBD
Medium
Controlled test
Review
D
Wallet merchant credential
Wallet/platform
Merchant/platform
TBD
Platform-specific
TBD
High
Platform/provider test
Review
Actual provider entries should be added only after verification.
Migration test plan
Data integrity
Count source population
Count eligible population
Validate unique merchant credential IDs
Validate export count
validate destination import count
verify one-to-one or documented one-to-many mappings
account for every exception
Security
Test approved transfer mechanism
verify encryption/authentication
verify access controls
verify logging redaction
verify temporary-data deletion
Functional
Validate destination reference creation
retrieve non-sensitive expected metadata where supported
controlled first payment
recurring payment test
failed credential test
expired credential behavior
Operational
Customer Support can identify migrated status
retry/recovery workflow exists
failed migrations appear in queues/reports
source and destination can be reconciled
Rollback
Merchant can restore intended routing while source bindings remain legitimately available
mapping is preserved
no credential identity is lost
Metric definitions
Eligible token population
Credentials satisfying documented migration criteria
Do not use all database records as the denominator.
Export success rate
Credentials successfully included in approved export
÷
eligible credentials scheduled for export
Import/reprovision success rate
Destination credentials successfully created
÷
eligible exported credentials submitted
Mapping success rate
Correctly linked destination credentials
÷
destination credentials successfully created
Validation success rate
Credentials meeting defined post-migration validation criteria
÷
credentials required/selected for validation
First-renewal success
Successful first recurring attempts on migrated credentials
÷
eligible first recurring attempts
Interpret carefully against ordinary decline baselines.
Customer re-entry rate
Customers requiring payment-method re-entry/reauthorization due to migration
÷
customers in relevant migration population
Unmapped credential rate
Eligible source credentials lacking confirmed destination mappings
÷
eligible source credentials expected to map
Amber-flag claims
Require explicit provider/network evidence before publishing:
“Tokens are portable between PSPs.”
“A token can be used like the original PAN.”
“Provider A can export all stored cards.”
“Provider B can import any PSP's tokens.”
“Network tokens are provider-agnostic.”
“Network tokens automatically survive PSP migration.”
“Merchant-controlled vaulting makes every processor interchangeable.”
“Customers never need to re-enter their cards.”
“Token migration preserves subscriptions automatically.”
“Migration requires no PCI involvement.”
“A PSP token can be converted back into the card number.”
“Wallet tokens migrate like ordinary card tokens.”
Proposed author and reviewers
Recommended author: Payments architect or senior payment-platform engineer with first-hand PSP-migration experience.
Primary technical reviewer: Payment architect.
Required security reviewer: PCI/payment-security specialist.
Recurring-payments reviewer: Subscription/payments product or engineering specialist.
Operations reviewer: Payment Operations lead responsible for migration exceptions and customer-support tooling.
An especially valuable human contribution would be an approved real migration showing how the credential inventory divided into multiple portability populations—for example, provider vault credentials, network tokens, credentials requiring re-entry, and dormant cards.
Do not fabricate population sizes, success rates, or migration timelines.
Cluster sameness-audit fields
Field
This article
Opening device
Two million tokens, followed by “what kind?”
Merchant engineering problem
Token strings mistaken for portable credentials
Integration lifecycle stage
Provider migration / credential continuity
Primary system boundary
Source credential system → destination credential system
Primary technical distinction
Token reference vs underlying credential
Format
Credential-portability workflow
Evidence anchor
Token usefulness depends on issuer/resolver and validity domain
Editorial position
Classify and validate before transferring
Merchant decision
Which credential populations can move without customer re-entry or unsafe CHD handling?
Original framework
Payment Token Migration Readiness Matrix
Primary metric
Validation + first-renewal success
Technical risk
False portability and incorrect credential/customer mapping
Security risk
Pulling PAN into uncontrolled merchant systems during migration
Conclusion
Credential identity and validity come before data movement
Adjacent article deliberately not duplicated
Provider Migration owns overall cutover; PSP Lock-In owns architecture; Payment State owns payment truth
The strongest line to preserve through final editing is:
A token can be copied anywhere; a payment credential can only be used where the security model and validity domain permit it.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗