Network tokenisation is sold on authorisation rates and card lifecycle updates, both of which are real. The more consequential property is barely discussed: depending on how it is set up, it either deepens your dependence on your gateway or provides the only clean way out of it.
Both major schemes run tokenisation services - Visa Token Service and Mastercard Digital Enablement Service. Instead of your provider storing a card number and giving you an internal reference, the scheme itself issues a token that stands in for the card across the network.
Two benefits are immediate and measurable.
Authorisation rates go up. Issuers treat network tokens as lower risk because provisioning involved a verification step. The uplift varies by issuer and geography, but on recurring billing it is the difference between a payment going through and a dunning sequence starting.
Cards update themselves. When a customer's card is reissued - lost, expired, replaced after fraud - the token keeps resolving to the new card. For a subscription business this removes an entire category of involuntary churn. You stop losing customers to the fact that their bank sent them a new card.
Tokens are provisioned against a Token Requestor ID. That identifier belongs to whoever enrolled with the scheme, and it determines who can use the resulting tokens.
In the common arrangement your gateway is the token requestor. They enrolled, the tokens sit under their TRID, and the tokens are therefore theirs. You get the authorisation uplift and the lifecycle updates, and you are exactly as locked in as you were before - arguably more, because the improved auth rate is now something you would lose by leaving.
In the other arrangement the merchant is the token requestor, or the provider supports merchant-owned tokens explicitly. The tokens are yours, they resolve across acquirers, and changing provider stops being a card migration project.
Same technology, opposite outcome. Whose name is on the Token Requestor ID decides whether tokenisation locks the door or opens it.
Ask during procurement. "Are network tokens provisioned under your Token Requestor ID or ours, and if we leave, what happens to them?" It is a short question and the answer tells you a great deal - both about the product and about how the relationship will run. Ask it while you still have leverage.
Get the answer in writing. Token portability is rarely covered in standard terms. If it matters to you, it needs to be explicit rather than assumed from a sales call.
Consider becoming a token requestor yourself. It means enrolling with the schemes directly and carries real operational weight, so it is not right for most merchants. At sufficient volume, where a migration would otherwise be a multi-quarter project, it changes the calculation.
Do not treat it as a substitute for the abstraction. Portable tokens solve one of the three lock-in problems. Webhook semantics and provider vocabulary in your schema are untouched by it. You still want your own payment model.
Tokenisation is a good example of a pattern worth watching for in payments generally: a feature that is genuinely beneficial, and whose default configuration happens to increase switching costs. Nobody is being underhanded. Defaults get set by whoever built the integration, and they are naturally set in the builder's favour.
The defence is the same each time. Know which decisions are configurable, ask before you sign, and keep the things that are genuinely yours - your states, your events, your tokens - under your own name.
We audit payment setups including tokenisation arrangements, and run gateway migrations where tokens have to move. If you are not sure who owns your cards, that is worth establishing before you need to know.