What makes token portability so operationally difficult for merchants

Payment expert Veronica Cuccu on the mechanics of token portability and the questions that decide how easily a merchant can switch providers.

Why is token migration such an underestimated pain point for merchants today?

Token migration is required when merchants change providers, add capabilities, expand into new markets, consolidate platforms, or redesign their payment architecture. The reason why token migration is often underestimated is quite simple: it does not feel like a problem until it is, and a merchant actually needs to deal with it. 

Over the years, tokenization has become a fundamental part of modern payment infrastructure. What I have seen is that tokenization is often regarded as a standard part of a payment integration rather than a strategic decision. During vendor selection, merchants naturally focus on the areas that are easier to compare – such as transaction costs, payment method coverage, authorisation performance, reporting capabilities, and implementation timelines.

As a result, questions such as how tokens are created, where they are stored, who controls the token lifecycle, and what happens if they need to be migrated are often raised much later, sometimes only when a change in the payment setup is already being discussed.

The challenge is that tokenized credentials become deeply embedded in the customer journey over time. What may look like a simple payment setup at the beginning can become significantly harder to change once years of stored credentials, customer payment preferences, and payment relationships have accumulated.

One common assumption is that ‘a token is a token’. In reality, portability is not automatically guaranteed. The ability to migrate credentials depends on how the tokenization model is designed, how credentials are managed, and whether the ecosystem supporting them is adaptable to future change.

When merchants need to evolve their payment setup, the complexity becomes visible. What appears to be a standard project can require coordination, testing, compliance reviews, and operational planning.

Many merchants only discover the limitations of their tokenization model when they are already planning a significant change, at the exact moment when flexibility becomes most important, and difficult to obtain.

What are the main technical and operational hurdles when moving tokens between gateways, and why do they catch merchants off guard?

Many merchants initially assume token migration is a straightforward technical exercise: export existing tokens from one provider and import them into another. However, in practice, token migration is rarely just a data transfer exercise. A token is not simply a replacement for a card number; it is a reference to payment credentials managed within a specific ecosystem.

There are different token models across the payment ecosystem. In the context of token migration, the most relevant ones depend on how the payment solution has been designed. Payment credentials may be represented by network tokens, provider-managed tokens, or multiple token layers working together behind the scenes.

Depending on the token model, credentials may be created, stored, and managed by different parties across the payment ecosystem – including gateways, PSPs, acquirers, and card networks. A token generated in one environment does not automatically mean it can be recognised or used in another.

Operationally, token migration is not only about moving credentials. Merchants need to ensure that stored credential payment journeys continue to operate correctly, including saved payment methods, COF and merchant-initiated transactions, recurring payments, and related flows.

Beyond the migration itself, merchants need to test payment journeys, validate customer experience, and understand how failures or exceptions will be handled during the transition and the new business as usual. 

Tokenization works quietly in the background, which is why it often becomes a surprise. Once implemented, it becomes an invisible dependency within the payment setup.

How does the way tokens are stored and owned affect a merchant's ability to switch providers later?

One of the biggest misconceptions is that tokenization automatically means portability. Tokenization is not something that simply needs to be enabled during setup, but rather a strategic decision that can impact future flexibility. The key question is not only how payments are processed today, but what happens to those credentials if the payment setup needs to evolve tomorrow.

The answer depends on how tokens are created, stored, and managed across the payment ecosystem. If tokens are held within a provider-specific environment, the merchant may become dependent on that provider’s migration capabilities and processes when a change is required. 

Even where network tokens are used, portability is not always automatic. Factors such as the Token Requestor ID (TRID), which identifies the entity requesting and managing the network token, the way network tokenization has been implemented, and the capabilities of the receiving provider can all influence whether existing credentials can be reused or whether a different migration approach is required. 

For example, a merchant may decide to switch PSPs, but if the new provider cannot support the existing token framework or the migration path associated with it, stored credentials may need to be re-tokenized or migrated through a more complex process.

The merchant may own the customer relationship, but the ability to continue serving that customer can be influenced by how payment credentials have been managed and whether they can be migrated.

Can you explain the difference between network tokens and gateway-specific tokens, and what each means for portability?

Network tokens are issued by card networks and are designed to replace the use of raw card credentials in supported payment flows. They help improve security and support credential lifecycle management across the payment ecosystem.

At the same time, gateways, PSPs, acquirers, and payment orchestration platforms may generate and manage their own tokens within their environments. These tokens are typically used to reference payment credentials within a specific platform while avoiding exposure of sensitive card data.

In practice, these models often co-exist together. A payment provider receives a network token and, depending on how its platform is designed, may use it within its payment flows or create an additional token layer to support its own services and processes.

For example, a merchant may store cards through a PSP. Behind the scenes, the PSP processes network tokens issued by the card networks and, depending on its platform design, may also maintain its own token layer to support its payment flows and services. The merchant may interact only with the PSP-managed token, while additional tokenization layers operate beneath. If the merchant later moves to another provider, the ability to continue using those credentials depends on whether the new provider supports the existing token framework or requires a migration or re-tokenization.

The merchant may see only one token managed by their payment provider, while multiple tokenization layers may exist behind the scenes.

From a portability perspective, network tokens can offer additional flexibility in certain scenarios because they are not tied exclusively to a single provider environment. However, the presence of a network token alone does not automatically mean migration will be straightforward. 

This is because a network token still exists within a broader payment ecosystem, including the token requestor relationship, the way the token is managed within the payment flow, and the capabilities of the providers involved. A merchant may therefore still need coordination between providers, and in some cases credentials may need to be migrated or re-tokenized before they can be used successfully in the new setup.

The practical outcome depends on how the overall payment setup has been designed, how credentials are managed, what capabilities exist across providers, what agreements are in place, and the level of cooperation between the parties involved. 

In an ideal scenario, the payment setup is designed with future flexibility in mind: responsibilities are clear and documented in the agreement and internal SOPs; token management is understood; and the providers involved have a clear process to support changes when required. 

Challenges arise when these topics are not considered up front. For example, a merchant may discover that the existing provider manages credentials in a way that makes the transition difficult; it is not mentioned in the agreement so there is no leverage; the new provider cannot immediately support the same setup, or that additional coordination is needed before stored credentials can continue to work as expected.

What practical steps can merchants take early on to avoid getting locked in down the line?

When selecting payment partners, merchants should look at token management with the same attention they give to pricing, payment, and technical capabilities. Tokenization is often treated as an implementation detail, but the decisions made at that stage can have a significant impact later if the payment setup needs to evolve.

This is why token management, portability, migration capabilities, and operational responsibilities should already be part of the RFP and vendor assessment process.

Some key questions merchants should ask early include:

• what type of tokenization model is being used;
• where payment credentials are stored;
• who manages the token lifecycle, and what visibility and control the merchant has;
• what migration options exist if the payment setup needs to change;
• what responsibilities apply during a transition.

These topics should be discussed and documented contractually rather than relying on a handshake agreement. Having clarity upfront can make a significant difference when a change is required.

Another important point is that payment architectures rarely stay static. As merchants grow, they often add providers, markets, payment methods, and new payment flows. Over time, these decisions create dependencies that may only become visible when a change is needed.

The objective is not to assume every provider relationship will end. It is to ensure the chosen payment setup continues to support business needs while preserving flexibility for future decisions.

About the author

Veronica is a payments leader with more than a decade of experience across fintech, ecommerce, and digital payments. She specialises in payment strategy and transformation, with expertise spanning payment operations, orchestration, vendor management, and risk management.

Combining strategic thinking with hands-on industry experience, Veronica helps organisations improve payment performance, optimise operations, and navigate the complexity of modern payment environments. She is passionate about making payments not just work, but work smarter.