A different meaning of tokenisation
A payment token in a digital wallet is a substitute for a card’s primary account number, or PAN. It is not a new deposit, a security or a transferable claim on reserves. EMVCo describes restrictions that can limit a token to a merchant, device or payment scenario. The purpose is to reduce the usefulness of compromised payment data outside its intended setting while retaining compatibility with card infrastructure. Its current catalogue lists Technical Framework version 2.4, published July 9, 2026. A new specification date does not establish that every issuer or merchant has implemented the same features. [1]
The economic distinction matters. Monetary tokenisation changes how a financial claim is represented or transferred. Credential tokenisation changes the information used to access an existing card relationship. The issuer still makes an authorization decision, the merchant still needs to receive settlement, and refunds and disputes remain operating processes. A safer credential can improve those processes without replacing them.
Provisioning establishes who may use the credential
Provisioning is the enrollment stage that connects a requested token with an underlying account. Visa’s public implementation description separates eligibility checks, an issuer decision to approve, decline or require additional verification, and subsequent token management. These are described capabilities of one network, not proof that all issuers use identical verification methods. The decision is important because a cryptographically valid credential can still have been enrolled for the wrong person. [2]
Imagine two otherwise identical purchases. In the first, the genuine cardholder enrolled a phone through a sound verification process. In the second, someone obtained a token through a mistaken enrollment decision. Both transactions might carry technically valid token data. The difference originates in the binding of the credential to the person, not in whether the token field has the expected format. This is why stronger transaction cryptography cannot retrospectively correct every identity mistake.
An enrollment control also has a customer cost. A legitimate customer replacing a phone may have less familiar device history at exactly the moment they need access. Requiring more verification can reduce improper enrollment but increase abandonment and support calls. The useful operating question is how much fraudulent enrollment is prevented for a given level of legitimate completion, rather than whether an extra screen was added.
A token and a cryptogram do different jobs
Apple’s public Apple Pay description provides a concrete implementation example. Following approval, the issuer or its authorized provider creates a device-specific account number. Transaction-specific dynamic security information accompanies payments. The persistent substitute identifies the payment credential; the changing security information helps authenticate a particular use. It would be misleading to describe the token number itself as a newly generated number for every transaction. Other token implementations need not use Apple’s device architecture. [3]
A useful analogy is a restricted account identifier combined with evidence about the current request. The identifier answers which credential is being presented. The transaction evidence helps answer whether this presentation is consistent with the authorized method of use. Neither answer, by itself, proves that the merchant will deliver goods or that the customer understood the purchase. Payment security and the commercial legitimacy of the sale overlap, but they are separate problems.
EMVCo’s discussion of using payment-token data in 3-D Secure illustrates that tokenisation and remote-purchase authentication can cooperate. The systems exchange relevant information rather than making one another redundant. The existence of a token therefore should not be treated as a universal reason to omit other authentication or fraud controls. [4]
The lifecycle continues after checkout
Visa documents distinct actions to activate, suspend, resume or delete tokens, as well as updates to the underlying PAN and expiration date. This distinction permits the card relationship and particular credentials to evolve separately. Losing one enrolled device need not be conceptually identical to closing the entire account. Actual behavior depends on the issuer, network and token arrangement. [2]
Consider a hypothetical customer with one underlying card used through a phone and an online merchant. Suspending the phone credential should not automatically be assumed to suspend the merchant’s separate credential. Conversely, replacing the physical card may require coordinated updates even when the customer expects the stored-payment relationship to continue. The operating challenge is to make the intended scope of each event explicit and consistent across participants.
Timing is critical. If an issuer records a suspension but a dependent system has not processed it, the customer’s screen and the payment decision can diverge. If a legitimate renewal does not propagate, a subscription may fail despite the account remaining usable. These are lifecycle synchronization problems. They are not resolved by showing that initial token creation succeeded in a demonstration.
Linking records without restoring broad exposure
EMVCo identifies Payment Account Reference, or PAR, as a way to connect token transactions with their underlying PAN relationship for functions such as fraud analysis, loyalty and transit. That linkage addresses a practical side effect: one account can appear through multiple credentials. PAR’s purpose is association; it should not be mistaken for the payment token or for permission to debit an account. [1]
The analytical benefit has a privacy dimension. Separate credentials reduce some opportunities to reuse payment information, while linkage enables authorized parties to recognize related activity. A dataset can therefore contain less directly usable payment information and still reveal sensitive patterns when joined with other records. Describing tokenisation as complete anonymization would conceal that distinction.
For a merchant, poor linkage can also distort measurement. A card replacement or new wallet enrollment may look like a new customer when it is merely a new credential. Conversely, combining records too aggressively can confuse different relationships. Transaction reconciliation needs identifiers whose meaning and scope are understood, not just a larger collection of fields.
Measuring improvement without inventing an uplift
A hypothetical program processes 100,000 comparable legitimate attempts. If completion rises from 94% to 95%, the difference is 1,000 completed payments, or one percentage point. It is not a 1% increase in revenue unless order values, refunds and other conditions support that conclusion. If the new population includes more returning customers, even the observed completion difference may not be caused by tokenisation.
The relevant economics include avoided fraud loss, fewer involuntary payment failures, support workload, integration costs and network or service charges. Token provisioning success is an early-stage metric; completed, non-fraudulent, non-reversed purchases are further downstream. A program can improve one measure while worsening another, for example by admitting more questionable enrollments to reduce initial friction.
Public specifications and product documentation establish that token systems and lifecycle functions exist. They do not establish a universal adoption rate or a bank’s incremental return on implementation. The sources used here do not support a single cross-industry approval uplift. Any such claim would require a defined population, comparison period and attribution method.
A narrower and more useful security claim
Payment tokenisation limits where exposed credentials should be useful and creates more granular ways to manage them. It does not eliminate provisioning fraud, customer deception, device compromise, merchant misconduct or operational outages. Its strongest explanation is architectural: reduce exposure, constrain reuse, validate each use and maintain the credential throughout its life. The financial benefit follows when those mechanisms produce better completed-payment outcomes at an acceptable operating cost.
Sources
- EMVCo, Payment Tokenisation; framework catalogue and architecture, checked October 4, 2026SourceBack to text: ↑1↑2
- Visa Developer, Token Service Provisioning and Credential Management; implementation capabilitiesSourceBack to text: ↑1↑2↑3
- Apple, Apple Pay security and privacy overview; implementation exampleSourceBack to text: ↑
- EMVCo, 3-D Secure transactions and leveraging payment-token dataSourceBack to text: ↑