93% of Companies Don't Own Their Payment Tokens. The Invoice Arrives When You Try to Leave.

You’ve laid the groundwork, planned the contingencies, and you’re ready to start switching payment processors. You send the email that starts the process, then you grind to a halt almost immediately. If you’ve had this experience, you’re far from alone – 93% of companies don’t own their payment token data.

Payment token ownership might not come up much in your day-to-day operations, but it’s the main story when you decide to switch providers. It’s a huge cost and risk vector for any merchant and can be hard to quantify ahead of time. Let’s make sure you have the confidence to know what’s coming and how to navigate it with the least disruption possible.

What a payment token is and why ownership matters

First, let’s make sure we’re on the same page. Payment tokens can mean different things depending on your context and ownership is its own murky area.

What is a payment token?

A payment token is a unique identifier that replaces a customer's actual card number in a transaction. It’s a unique mask for sensitive data, allowing payment credentials to be stored and reused while reducing the risk of exposing the underlying card data.

Each token is merchant-specific, so a customer shopping with Company A will checkout under a different token than when they shop with Company B.

There are two main types of token: gateway tokens (which are held by the processor) and network tokens (which are issued by the payment method’s underlying card network).

The question of payment token ownership has two layers: which type of payment token you use and where the credential lives. To have true ownership of your payment tokens, you would be storing tokens in a processor-agnostic vault.

Gateway tokens versus portable credentials

The kind of tokens you operate on matter a huge amount. Gateway tokens are issued, stored, and owned by your payment processor. They fit into the lock your PSP designed and are useless elsewhere. If you switch to a new PSP, these offer zero payment credential portability.

If you choose to switch PSP, you’ll have to migrate (at a huge technical cost), re-issue (with a huge churn risk), or lose (for guaranteed attrition) your gateway tokens.

Instead, if you run your payment stack on network tokens like the kind issued by Visa and Mastercard, your payment credentials are far more portable.

The tokens you hold (or don’t hold) is the leading factor in determining how much a provider switch will cost you. It could even decide whether a switch is economical.

What the switching cost data measures

In our report with PYMNTS (The Orchestration Advantage: How Routing Architecture Shapes Payments Performance), we detail four key areas that make up the average PSP migration cost. Token ownership shows up across all four.

The four costs that dominate every PSP switch

When switching to a new PSP, companies report the following four challenges most often:

1. Implementation cost (69% of companies)
2. Data migration (67%)
3. Compliance and approvals (65%)
4. Technical integration (56%)

You might find yourself pointing the finger at vendors and their various demands and criteria. Dig a little deeper, however, and it’s clear that all of these issues have roots that run back to one source at an architectural level: token ownership.

Think of it this way: would any of those areas be as challenging for your company if you owned your payment tokens? In some cases, the cost would disappear completely.

Implementation cost: the rebuild starts with credentials

Implementing a new PSP could be as simple as unplugging some APIs and permissions and replacing them. It rarely is.

Implementing a new payment processor when you don’t own your payment tokens means rebuilding your credential infrastructure from scratch. You face exporting token data, re-encrypting it, migrating it to a new format, testing against live transactions, validating recurring billing, and maintaining an auditable trail of all the activity from the previous vendor.

This is more than a Jira ticket or even a sprint. This is a full quarter of engineering work. That’s a substantial cost in and of itself and raises questions about the value of switching.

Data migration: the cost of asking for your own data back

You run your ads, you tweak your nurture sequence, you secure your sales – and yet the last-mile at checkout means none of that customer data is really yours. It gets boiled down to a single token that’s stored outside of your systems.

PSPs know how valuable that data is to you and how carefully it has to be handled.

Extracting your customer payment tokens requires a formal export process. It can stretch as far as involving legally documented requests, encryption via PGP key, SFTP transfer, and compliance review. It involves a lot of effort and it can involve specific fees.

In principle, this is your data. In practice, storing these credentials in someone else's vault means you’re asking for permission to ever touch them. If that’s ownership, we all need to rethink what we’re doing.

Compliance: PCI scope doesn’t disappear during a migration

Start talking about customer data and compliance questions often follow soon after. If you do choose to migrate your payment infrastructure, you’ll be running two payment environments in parallel for at least some of that time. PCI DSS doesn’t care that you’re migrating – in every measurable sense, you are running two in-scope systems at once.

In the best case scenario, this doubles your compliance workload. If something goes wrong with the token export, the new provider setup, or any of your transactions in that time, the challenge increases.

When you own your tokens and store them in a provider-agnostic vault, a change at the processor level is kept completely separate from your credential layer. It’s a layer of modularity that a truly flexible payment stack needs.

The onboarding speed problem that makes this worse

Migrating PSPs is a technical challenge, but the real uncertainty in the process comes from the fact you’re relying on a third party to complete an update to your own systems. On an internal project, your engineers can scope out a clear timeline and process. With a PSP migration, they do their work and then have to cross their fingers that the new PSP can keep up.

No company can onboard a new provider in under two weeks

Even if you solve the token ownership problem, the timeline to activate a new provider is still measured in months for most organisations. In our research for The Orchestration Advantage, we also learned that no companies can onboard a new payment provider in less than two weeks. 93% need at least a month.

It’s a key reason why 58% of companies are consolidating their providers. This decision isn’t being driven by performance or even cost – it’s because adding new providers takes too long, creating too much risk exposure and uncertainty.

Token lock-in and slow onboarding create an inertia that is incredibly hard to break.

What token portability changes about the switching equation

If you do commit to a provider-agnostic token vault, you’re trading a short-term struggle for a long-term advantage.

Make this choice and the process of switching PSPs goes from months of technical building to a configuration change. Your credentials are a module you can pick up and drop into a new PSP, rather than a foundation you need to carefully extract, reseat, and build upon each time.

The entire dynamic shifts: you are no longer approaching a new PSP with a carefully encrypted CSV of credentials. They come to you, plugging their own system into your vault.

All the stress of the old way – the risk of customer churn, the loss of recurring billing, the compliance demand – disappears. It seems impossible until you experience it for the first time.

The performance benefit that ownership also unlocks

Owning your payment tokens isn’t just about avoiding complex and costly migrations. It can offer a real, tangible improvement to your payment performance.

Network tokenization and authorization rate lift

Owning and operating from a provider-agnostic vault allows you to use network tokens across every connected provider.

Network tokens deliver consistently higher authorisation rates, because issuers – for obvious reasons – trust them more. They are dynamic, automatically updated on card reissue, and carry more cryptographic context than standard PAN transactions.

Visa’s own data shows their tokens “have led to a 28 percent reduction in fraud rates and a 3 percent increase in approval rates”. Mastercard reports their tokens cut fraudulent chargebacks almost in half and “a 10.3 ppt increase in transaction approval rates”.

The audit question to ask before the next switch

If you’re in the process of picking a new PSP, forget their rates, forget their merchant tools, forget their perks. Ask where your tokens live.

If your customer credentials are stored in your current processor’s vault, it’s time to assess whether the migration needs to start further down your payment stack. Trust that the costs of migrating tokens to a new PSP can easily negate any gains on offer with their lower rates.

If you’re going to go to the effort of migrating your tokens, let it only be done once – into a vault you own, that flips the dynamic and asks PSPs to come to you.

You’ll enjoy the benefits of owning your payment data long into the future.

‍Download 'The Orchestration Advantage: How Routing Architecture Shapes Payments Performance' for the full data on token ownership, switching costs, and the credential architecture decisions that determine them.