The Token in Your Phone

19.0 What this chapter gives you#

1. You will be able to explain why the last four digits printed on a phone receipt differ from the last four on your plastic, and prove it to yourself by buying the same coffee twice.
2. You will be able to state exactly what a Payment Token is — 13 to 19 Luhn-valid digits from a real Token BIN Range, carrying its own expiry — and why it therefore crosses the existing network with nobody changing anything.
3. You will be able to say why a stolen token is close to worthless, and name the three separate walls that make it so.
4. You will be able to correct the claim that your card number never leaves the phone, and state the narrower claim that is actually true.
5. You will be able to say who mints the token and who owns the vault, and why many issuers cannot enumerate their own outstanding tokens without calling a network API.
6. You will be able to explain what the Payment Account Reference is for, why the industry had to invent it, and why it cannot itself initiate a payment.
7. You will be able to tell a secure element wallet from a host card emulation wallet by their availability and failure modes rather than by their cryptography.
8. You will be able to explain the green, yellow and red provisioning paths, and why yellow is where the whole design lives or dies.
9. You will be able to say why a reissued card leaves the token working and a lost phone leaves every standing order untouched.
10. You will be able to read a tokenised contactless trace, including why tag 9F6E must be parsed kernel-aware or it will produce plausible nonsense.

The previous chapter left a phone held against a reader, an antenna pulling power out of the air, and a two-byte answer travelling back at 106 kilobits per second. It deliberately did not say what number was in that answer.

Here is the thing almost everybody gets wrong, including people who work in payments: when you tap your phone, your card number is not transmitted. Not encrypted, not obscured, not hashed. It is simply not there. The number the shop receives is a different number, sixteen digits long, beginning with the same digit as your card and looking in every respect like a card number, because it is one — it is just not yours. It was minted for that phone, it works only from that phone, and if somebody steals it they will find it worth almost nothing.

That substitution is called payment tokenisation, and it is the single largest change to card security since the chip. It is also the reason your bank can kill your Apple Pay card at four in the morning and still let you buy petrol with the plastic on the way home. The plastic and the phone stopped being the same credential some time around 2014, and most cardholders have never been told.

This chapter is about that second credential: what it is, who makes it, what stops it being used anywhere else, and why a stolen one is close to worthless.

The plain version#

Think about a hotel.

You check in and they give you a key card for room 412. It opens your room, it opens the pool, and it stops working on Friday. It is not the master key. It has its own serial number printed on the back, and if you lose it in a taxi the hotel does two things: it cancels that serial number, and it cuts you a new card. Room 412 does not change. The lock does not change. Nobody has to re-key the building.

Now suppose you want a second key so your brother can come and go. The hotel does not photocopy your card. It cuts a new card, with a different serial number, which opens room 412 and the pool but not the gym, and only between nine and five. Two cards, two serial numbers, one room, different powers.

Your bank account is room 412. Your plastic card is the first key. The card in your phone is the second key: a different number, cut for a specific purpose, cancellable on its own.

The number is genuinely different#

Say your card is 4659 1234 5678 9011, expiring 11/27. That number is embossed on the plastic, printed on your statement, and known to every shop you have ever typed it into.

When you add that card to your phone, your bank and the card network create a second number for you — say 4658 7712 3456 7892, expiring 03/29. It is stored on a small, sealed chip inside the phone. It is not printed anywhere. You cannot read it out. The phone shows you the last four digits and nothing more.

Both numbers point at the same account and the same money. But they are not interchangeable, and this is the whole idea.

A worked example: £180 of headphones#

You are in a shop in Manchester buying headphones for £180. You hold your phone to the reader and look at it, and your face unlocks the payment.

Three things happen in the two seconds that follow.

First, the phone sends 4658 7712 3456 7892 and the expiry 03/29. It does not send 4659 1234 5678 9011. The shop never learns that number. Neither does the shop’s till software, nor its payment provider, nor the company that stores the day’s takings.

Second, the phone sends a short one-time code — eight bytes of arithmetic, computed fresh for this tap, using a secret key that never leaves the sealed chip and a counter that ticks up by one every single time. Yesterday’s code will not work today. This tap’s code will not work at the next shop. It is the digital equivalent of a wax seal that can only be pressed once.

Third, the phone says: the person holding this device proved who they were, on the device, just now. That is why £180 goes through without a PIN pad, when a plain contactless card would have stopped dead at £100. The reader does not see your face. It simply receives a statement that a face was seen, from a device the bank has decided to trust.

Your bank receives all three, notices that 4658 7712 3456 7892 stands for account 4659 1234 5678 9011, checks the one-time code against its own copy of the maths, sees that verification was done on the device, and approves.

Now look at your receipt. The last four digits printed on it will be 7892, not 9011. Most people assume this is a misprint or a strange rounding of their card number. It is neither. It is the token’s last four digits, and it is the easiest way to prove to yourself, tonight, that your phone is not sending your card number: pay for the same coffee twice, once with the plastic and once with the phone, and compare the two receipts. They will end in different digits.

What a thief gets#

Six months later the shop is hacked and somebody walks off with a year of transaction records, including 4658 7712 3456 7892 and 03/29.

They cannot use it. Three separate walls stand in the way.

The number is registered as working only for contactless taps from that one phone. Type it into a website and it is refused before any money is considered, because the network can see that this number is not permitted to be typed into a website. That restriction is baked in at the moment the number is created.

The number is worthless without the one-time code, and the code cannot be produced without the sealed chip in your phone. The thief has the envelope; the seal is in Manchester in your pocket.

And it does not identify you. It is not on your statement, your bank does not use it on the phone to you, and it cannot be traced back to 4659 1234 5678 9011 by anyone outside the network.

Compare that to what a thief gets from a stolen card number: a working credential, usable in dozens of channels, that stays valid until the bank reissues the plastic and posts it to you.

Losing the phone#

You leave the phone on a train. You call the bank.

The bank cancels 4658 7712 3456 7892. That is one row in one table. It takes seconds, needs no post, and costs nothing.

Your plastic card still works. Your card number has not changed. Every standing order, every subscription, every card-on-file at every shop that has your real number is untouched. The direct debit for your gym does not fail. You buy dinner on the way home with the card in your wallet.

This is the practical payoff, and it is the sentence to carry to dinner: the number in your phone can be destroyed without destroying your card, because it was never your card.

Where the plain version stops being true#

The hotel key analogy is sound in outline, and wrong in four ways that matter.

The token is not what makes the transaction safe#

A payment token is, on its own, just a number. It has no cryptography in it. If you place a token in a channel where nobody demands a cryptogram and nobody checks the restrictions, it spends exactly like a card number — that is the point of the design, since the whole scheme was built to travel over infrastructure that already existed and could not be changed.

What makes the tap safe is the combination: a token plus a per-transaction cryptogram plus restrictions enforced by whoever is doing the checking. Take away any one of the three and you have a card number with an unusual value. Merchant card-on-file tokens, which are the same EMVCo mechanism, routinely operate with no per-transaction cryptogram at all; they rely on merchant and channel restriction alone.

So the correct statement is not “tokens are safe”. It is “tokens shrink the blast radius of a breach, and cryptograms stop a stolen credential being replayed, and the two are separate mechanisms that people habitually merge into one word”.

Your card number does leave the phone — once#

Apple’s and Google’s public claims are carefully worded, and the careful wording is doing work.

When you add a card, you type the real number into the phone, or the phone reads it with the camera, or your bank’s app pushes it across. That number is then encrypted and sent to the card network and your bank, because they have to know which account you are asking to tokenise. It leaves the device. It travels.

What is true is narrower and still meaningful: the wallet provider cannot decrypt the token it receives back; the token is written into the phone’s sealed chip; and the wallet’s servers do not store it. Apple states that the Device Account Number is “never stored on Apple Pay servers or backed up to iCloud”. That is a real property. It is not the same as “Apple never sees your card details”, which is what people repeat.

There is also a residue. The wallet keeps an opaque identifier derived from the funding card so that it can tell two tokens on the same card apart from two tokens on different cards. Apple exposes it to apps as primaryAccountIdentifier. It is not the card number, but it is a persistent handle on the card number, and it exists because the ecosystem could not function without one.

The issuer is not really in charge; the network is#

The analogy implies the hotel cuts the keys. In practice, for the overwhelming majority of device tokens, the Token Service Provider is Visa or Mastercard, not your bank. They own the vault. They own the mapping table. They decide the token’s BIN range, they mint the value, they hold the keys used to validate cryptograms, and they perform the substitution back to your real number before the authorisation reaches your bank’s systems.

Your bank’s role at provisioning time is to answer one question — approve, decline, or ask for more proof — and its role afterwards is to consume a data feed. Many issuers cannot enumerate their own outstanding tokens without calling a network API. When the network’s token service is degraded, tokens stop working even though the bank is perfectly healthy and the plastic is fine. This is a real operational dependency, and it is not visible from the cardholder’s side of the counter.

“Device token” describes a shrinking share of tokens#

The chapter title says phone, and phones are where tokenisation is most visible. But EMV payment tokens are also issued in enormous numbers to merchants for stored cards, to wallets for e-commerce, and to acquirers on behalf of merchants who never asked. Those tokens live in databases, not secure elements. There is no biometric, no secure chip, no per-tap cryptogram of the kind described above.

The consequence shows up in a place nobody anticipated. Once the same person carried five different numbers at five different merchants, the systems that needed to know “these are all the same account” — fraud scoring, loyalty, anti-money-laundering, transit fare capping — broke. The industry’s answer was to invent yet another identifier, the Payment Account Reference, whose entire job is to undo just enough of the separation to make those systems work again. That is a strange thing to have to build, and its existence tells you the analogy was too clean.

The technical version#

Vocabulary, exactly#

The governing document is the EMV Payment Tokenisation Specification – Technical Framework, published by EMVCo, royalty-free and publicly available. Version 2.4 was published on 9 July 2026, superseding v2.3; v1.0 dates from 2014. A companion document, EMV Payment Tokenisation – A Guide to Use Cases, carries the worked scenarios.

Note the spelling and the scope. EMVCo’s document says tokenisation, and it defines a Payment Token — not a DPAN. The terms this chapter’s title uses are industry vocabulary that grew up alongside the specification:

Apple’s PassKit framework uses both abbreviations openly: PKSecureElementPass exposes deviceAccountIdentifier (documented as an opaque identifier of the DPAN), deviceAccountNumberSuffix (the last four digits of the DPAN), and primaryAccountIdentifier (an opaque identifier of the FPAN). Google’s device tokenisation documentation writes “dynamic primary account number (DPAN) or device token”. When you see DPAN in a scheme manual, check which expansion that manual means; they are not always the same thing.

The roles are stable across versions:

EMVCo runs two registration programmes rather than a certification programme. The TSP Registration Programme assigns a three-digit TSP Code so that every TSP issuing payment tokens is globally identifiable; as of writing the fee is USD 11,500 for initial registration and USD 2,850 per calendar year thereafter. The BIN Controller Registration Programme assigns a BIN Controller ID (BCID), which becomes the first four characters of every PAR that controller generates. EMVCo is explicit that it “does not evaluate, approve or otherwise endorse TSPs”; it maintains a list of codes. There is no EMVCo tokenisation test programme, and EMVCo says plainly that one would be impractical.

The token itself#

Three properties of that last row are load-bearing and frequently misstated. PAR has a one-to-one relationship with the PAN and a one-to-many relationship with the payment tokens issued against it. It cannot be reverse-engineered to obtain either a PAN or a payment token. And it cannot itself initiate a financial transaction. It is an identifier, not a credential.

The Token BIN Range point deserves emphasis for anyone building routing: token BINs are real ISO BINs, carved out of the issuer’s or the TSP’s allocation and published into routing tables. That is precisely why a token traverses the existing network without any acquirer changing anything. It is also why a badly maintained BIN table will route a token to the wrong place and produce a decline that looks like a network fault.

Where the token travels in the message#

In ISO 8583, the payment token occupies the primary account number field, DE 2, and the token expiry date occupies DE 14. Chip data travels in DE 55. Point-of-service entry mode is DE 22; Visa’s own acquirer implementation guidance specifies DE 22 = 07 for a qVSDC contactless chip transaction and 91 for a contactless magnetic-stripe (MSD) transaction.

Payment Account Reference is carried in EMV tag 9F24 within DE 55 for chip transactions. For non-chip transactions the Secure Technology Alliance’s primer places it in data element 56 of the authorisation response. Treat the tag 9F24 path as the reliable one and confirm the DE 56 behaviour against your acquirer’s own manual, because it varies.

The token-specific attributes that the issuer receives — token requestor ID, token assurance data, wallet identifiers, the last four digits of the underlying PAN — travel in scheme-private data elements whose numbering differs between networks and which are specified in each scheme’s own message manual, not in any EMVCo document. Do not carry a field number learned on Visa across to Mastercard. This is the single most common source of integration errors in token projects.

In the ordinary model, the network de-tokenises before the authorisation reaches the issuer’s host: the issuer sees the FPAN in DE 2, plus token metadata alongside. Some issuers host their own TSP and receive the token itself. Establish which model you are in before writing a single line of authorisation logic.

The chip data a phone actually presents#

A tokenised contactless tap is an ordinary EMV contactless transaction whose PAN happens to be a token. The tags below are the base EMV set, defined in the EMV ICC Specifications for Payment Systems, Book 3, Annex A.

Two kernel-specific objects appear in Visa qVSDC flows and are not in Book 3 Annex A:

And then there is 9F6E, which is a trap.

The same tag number carries two entirely different structures depending on which kernel produced the trace. A Visa FFI of 20700000 decodes as version 001, form factor “standard card”, with signature panel, hologram and CVV2 capability set. Feed those four bytes to a Mastercard Third Party Data parser and you will get plausible nonsense. Feed a seven-byte Mastercard value such as 06430000303000 to a Visa FFI decoder and it will either reject the length or truncate it. If your terminal estate handles both schemes, your TLV parser must be kernel-aware, and any documentation that lists 9F6E with a single name is incomplete.

The Form Factor Indicator is where “this was a phone, not a card” is stated in the chip data, which is why it matters to issuers doing risk scoring on tokenised taps.

The secure element#

Apple’s implementation is the best-documented and is worth stating precisely, because it is also the most misdescribed.

The Secure Element is, in Apple’s words, “an industry-standard, certified chip running the Java Card platform, which is compliant with financial industry requirements”. It is “certified in accordance with the EMVCo Security Evaluation process”, for which EMVCo issues unique IC and platform certificates, and it is separately “certified based on the Common Criteria standard”. The Device Account Number lives there, in a payment applet, and Apple’s servers manage those applets without being able to read the number.

The NFC controller sits between the application processor, the Secure Element and the reader, routing frames. Below it is ordinary contactless plumbing: ISO/IEC 14443 Type A or Type B at the radio layer, ISO-DEP (ISO/IEC 14443-4) for the transport, and application protocol data units per ISO/IEC 7816-4 above that. Applications are addressed by Application Identifier — up to 16 bytes, consisting of a five-byte Registered Application Provider Identifier issued by the ISO/IEC 7816-5 registration authority followed by a proprietary extension. A000000003 is Visa and A000000004 is Mastercard, so the credit and debit applications your phone advertises are A0000000031010 and A0000000041010 respectively — the same identifiers a plastic card presents. From the reader’s point of view, a phone is a card.

Authorisation on Apple devices is a two-chip conversation. The Secure Enclave and the Secure Element communicate over a serial interface using a shared secret established at runtime through Elliptic Curve Diffie-Hellman key agreement. When you authenticate, “the Secure Enclave then sends signed data about the type of authentication and details about the type of transaction (contactless or e-commerce) to the Secure Element, tied to an Authorization Random (AR) value”. The AR is generated in the Secure Enclave when the first card is provisioned and persists while Apple Pay is enabled, protected by Secure Enclave encryption and an anti-rollback mechanism. A payment “can be made only after the Secure Element receives authorization from the Secure Enclave”.

The cryptogram itself is “computed using a transaction counter and a key”, with the counter incremented for each transaction, and it incorporates the terminal’s Unpredictable Number for NFC transactions or an Apple Pay server anti-replay value for in-app and web transactions. That last distinction is the answer to a question practitioners ask constantly: an in-app tokenised payment has no terminal and therefore no terminal-supplied nonce, so the freshness has to come from somewhere else.

Host card emulation#

Android took a different route. From Android 4.4 onwards the platform supports host-based card emulation, in which “the data is routed directly to the host CPU instead of being routed to a secure element”. A HostApduService receives command APDUs through processCommandApdu() and returns response APDUs; Android’s implementation supports a single logical channel, so the exchange is strictly single-threaded and half-duplex. AIDs are declared in groups, and Android guarantees that all AIDs in a group route to your service or none do.

The security consequence is direct. Without a secure element, the payment keys are in ordinary application memory on a device that may be rooted. The industry’s answer is not to pretend otherwise but to make the keys nearly worthless: limited-use keys, provisioned over the network and bounded by thresholds — a time-to-live, a maximum number of transactions, a cumulative transaction amount, or a combination — and replenished from the cloud. A key that expires after a handful of taps or a few days is a poor prize.

Around this sits EMVCo’s EMV Mobile Payment: Software-Based Mobile Payment Security Requirements and the associated SBMP Security Evaluation Process, introduced in 2018. It evaluates software development kits, trusted execution environments, consumer device cardholder verification methods including biometrics and authenticators, attestation mechanisms and software protection tools. EMVCo issued its hundredth SBMP security evaluation certificate on 29 November 2022, with nine accredited laboratories performing the evaluations.

The practitioner-facing difference between the two architectures is not really cryptographic. It is availability:

A user who leaves an HCE wallet in a drawer for a month and then tries to tap in a car park with no signal will be declined, and the decline will be correct.

Provisioning: green, yellow, red#

Provisioning is the security-critical moment in the whole design. A criminal who successfully provisions a stolen card into their own phone has manufactured a fresh, fully working credential with strong cryptography protecting them.

Apple’s flow uses three server-side calls — Required Fields, Check Card, and Link and Provision — with sessions protected by TLS 1.2 or later. The device sends the card details together with information about the account and the device, and the issuer or its network returns an encrypted Device Account Number along with the key material used to generate the per-transaction codes.

For provisioning initiated inside a bank’s own app, Apple’s PassKit provides PKAddPaymentPassViewController, configured with PKAddPaymentPassRequestConfiguration, which returns a PKAddPaymentPassRequest carrying three fields:

EV_ECC_V2 is the mandatory encryption scheme.

On Android, the equivalent path is Google’s TSP integration with push provisioning from the issuer app. Where a challenge is required, app-to-app identification and verification hands control to the issuer’s app via an Android Intent, with a base64-encoded JSON payload in Intent.EXTRA_TEXT; the issuer app authenticates the cardholder and returns BANKING_APP_ACTIVATION_RESPONSE with a value of approved, declined or failure, optionally accompanied by BANKING_APP_ACTIVATION_CODE. Google’s documentation is explicit that the issuer app must verify the caller using Activity.getCallingPackage() and confirm it is Google Wallet, com.google.android.gms. Skip that check and you have built an activation oracle for anybody who can install an app.

The issuer’s decision is described everywhere in the industry by colour:

Yellow is where the design lives or dies, because a token stuck awaiting activation is a card the customer believes they have added and cannot use. The resolution methods in general use are: a one-time code by SMS; a one-time code by email; a call to the issuer’s contact centre; login to the issuer’s mobile banking app, including the app-to-app flow above; and, for Visa customers, web-based secure authentication. Google’s published guidance is that “well thought out and high performing ID&V processes yield token activation rates of +90% on Google Pay”, and that most issuers route manual provisioning attempts to yellow except on a trusted device. Issuers receive account and device risk scores from the TSP and are encouraged to override them when their own data says the user is legitimate.

The specification’s own vocabulary for what yellow accomplishes is identification and verification (ID&V), with five defined cases: No ID&V Performed; Account Verification; Token Service Provider Assurance; Token Service Provider Assurance with Requestor Data; and Card Issuer Verification of the Cardholder.

One historical correction that catches people reading older material. Version 1.0 of the framework defined a two-digit Token Assurance Level, where “a value of 00 would indicate no ID&V and 99 would indicate the highest level of assurance”. Version 2.0 replaced that concept with Token Assurance Method, based on the type and outcome of the ID&V performed, the entity that performed it, the domain in which the token is used, and supporting token assurance data. If a vendor document still talks about assurance levels as though they were current, that document has not been revised since 2016 and everything else in it should be treated with suspicion.

Mastercard’s Digital Enablement Service exposes the mechanics under its own names: a tokenUniqueReference identifying the token for its lifetime, a panUniqueReference for the funding account, and operations including GET /{id}/token/activate, GET /{id}/token/resendactivationcode and GET /{id}/token/activationmethods. A token awaiting the yellow path carries a provisioning status of “Awaiting Activation”.

Domain restriction, precisely#

EMVCo defines Token Domain Restriction Controls as “a set of parameters that are applied during Token Processing to constrain a Payment Token to the permitted usage scenarios”. Three inputs do the constraining:

Token Requestor ID. Does this token belong to this token requestor? A token minted for Apple Pay presented by a different requestor is refused.

POS Entry Mode. The specification calls for “the use of POS Entry Mode values that are carried in the POS Entry Mode Code field to limit the use of Tokens to only those POS Entry Modes agreed to during Token Requestor Registration”. This is what prevents a contactless device token being keyed into a web form: the entry mode does not match the registration.

Merchant information. “Merchant-related data elements, such as the Card Acceptor ID in a combination with Acquirer-identifying data elements SHOULD be used to limit the use of a Payment Token.” This is the mechanism behind merchant-scoped card-on-file tokens.

To these the framework adds the requirement for a valid token cryptogram in domains where one is expected. Validation may be performed by the TSP or delegated to the issuer; either way, a cryptogram that fails or a transaction that violates the domain controls is refused before the account is even considered.

The critical property, and the one the plain version hides, is that domain restriction is enforced by whoever is checking, and it is only as strong as that party’s implementation.

The clearest public demonstration of this came in 2021. Andreea-Ina Radu, Tom Chothia, Christopher J. P. Newton, Ioana Boureanu and Liqun Chen, of the University of Birmingham and the University of Surrey, published Practical EMV Relay Protection, showing that an iPhone with a Visa card set up in Express Transit mode could be made to authorise £1,000 while locked. Transport for London ticket gates broadcast a non-standard byte sequence before the standard ISO/IEC 14443 wake-up command — the researchers called them the “magic bytes” and deliberately did not publish their value. Replaying that sequence convinced the phone it was at a transit gate, where Express Transit deliberately suppresses the biometric prompt. The attack then set bits in the Terminal Transaction Qualifiers sent in the GET PROCESSING OPTIONS command and set the “consumer device CVM performed” bit in the Card Transaction Qualifiers, so that the shop reader believed a cardholder verification had happened that had not. Relay success improved from roughly 40 per cent to effectively complete once READ RECORD responses were cached. The combination was specific: it did not affect Mastercard on iPhone, or Visa on Samsung Pay. Apple and Visa have since addressed it.

The lesson is not that tokenisation failed. The token worked exactly as designed. What failed was one exemption inside one domain control, on one platform, for one scheme. That is the shape of every real tokenisation failure: not broken cryptography, but a restriction that somebody decided to relax.

Lifecycle: why the token dies and the plastic lives#

Tokens carry state independent of the account. Mastercard’s states are the ones most commonly encountered:

Four lifecycle events are worth committing to memory because they generate most of the support tickets.

The card is reissued. Your plastic is lost and a new card arrives with a new PAN and expiry. The token in your phone keeps working, because the TSP updates the token-to-PAN mapping in the vault. You do not re-add the card. This surprises people and is the correct behaviour: EMVCo’s own material describes tokenisation as reducing “the need for card replacements” and enabling issuers “to control and replace payment tokens for specific merchants, devices or transaction types, often without any interaction from the cardholder”. Note the corollary — if the card was reissued because of fraud, the automatic mapping update means the token survives too, unless the issuer suppresses it. Suppression is a configuration choice, and getting it wrong in either direction produces either angry customers or continued fraud.

The device is lost. The token is suspended or deactivated. The account is untouched. Apple’s implementation lets Lost Mode in Find My suspend the ability to pay, or a remote erase remove it, and Apple notes that the issuer suspends the cards “even if your device is offline and not connected to a cellular or Wi-Fi network” — because suspension happens in the vault, not on the phone.

The token is compromised. A merchant breach exposes tokens. The TSP deactivates the affected tokens and the requestor provisions replacements. No plastic is reissued, no card numbers change, and nothing else the cardholder has set up is disturbed. This is the single largest operational saving in the whole design, and it is the reason issuers accepted tokenisation despite the loss of control described earlier.

The customer deletes the card from the wallet. The token is deactivated and cannot be revived; adding the card again mints a new one, with a new value, a new expiry and a new last four digits.

What it is worth#

Some figures, all dated, all from the schemes themselves.

Visa announced its ten billionth token on 4 June 2024, ten years after launch, stating that tokenisation “can reduce the rate of fraud by up to 60%”, that it had saved USD 650 million in fraud in the preceding twelve months, that 29 per cent of all Visa transactions used tokens as of April 2024, and that tokens contributed a six basis-point increase in global payment approval rates.

Mastercard reported in June 2025 that nearly half of its European e-commerce transactions were tokenised, up by more than a third year on year, and has stated a goal of 100 per cent tokenisation of European e-commerce by 2030 alongside phasing out manual card entry.

The PCI Security Standards Council’s position is the one to quote at auditors: payment tokens are “created by TSPs that are registered with EMVCo”, are “issued to a cardholder in lieu of a PAN”, and “during a Payment Token transaction, the merchant and acquirer do not receive or have access to the corresponding PAN”. That last clause is the compliance argument in a single sentence, and it is why tokenisation is a scope conversation and not only a fraud conversation.

A short field guide to failures#

The chapter in one paragraph#

Payment tokenisation replaces the primary account number with a Payment Token: a 13 to 19 digit Luhn-valid surrogate, drawn from a Token BIN Range of 6 to 12 leading digits, carrying its own expiry, minted by a Token Service Provider registered with EMVCo under a three-digit TSP Code, on behalf of a Token Requestor identified by an 11-digit Token Requestor ID. On a phone the token is written into a secure element — a Java Card platform chip evaluated under the EMVCo Security Evaluation process and Common Criteria — or, where there is no secure element, held in software under limited-use keys bounded by time, count or amount and evaluated under EMVCo’s Software-Based Mobile Payment requirements. Provisioning is gated by identification and verification, whose outcome the industry calls green, yellow or red, and whose rigour the framework records as a Token Assurance Method, having abandoned the older two-digit Token Assurance Level at version 2.0. At the till the token occupies DE 2, its expiry DE 14, and its chip data DE 55, where tag 5A holds the token rather than the account, tag 9F26 holds a cryptogram computed from a key inside the device and a counter that only ever increases, and tag 9F24 may carry a 29-character Payment Account Reference whose first four characters are an EMVCo-assigned BIN Controller ID and which links every token on the account back together without exposing the account. Token Domain Restriction Controls constrain all of it by token requestor, by POS entry mode and by merchant identity, enforced by whichever party is checking — which is why the only serious public break of the model, the 2021 Express Transit relay, was not a break of the cryptography but the exploitation of a deliberately relaxed control. And because the token is a separate credential with a separate lifecycle, it can be suspended or deactivated in the vault in seconds, leaving the plastic, the account, the standing orders and the card-on-file arrangements entirely untouched. That is the whole point. The phone does not carry your card number. It carries a second one, cut for that phone, that the bank can throw away.

19.98 Common wrong ideas#

Wrong: the phone sends your card number in encrypted or obscured form. Right: the card number is simply not there; a different sixteen-digit number, minted for that phone, occupies the account number field.

Wrong: tokens are safe. Right: a token on its own is just a number with no cryptography in it, and safety comes from the token plus a per-transaction cryptogram plus restrictions enforced by whoever is checking — merchant card-on-file tokens routinely run with no cryptogram at all.

Wrong: your card details never leave the device. Right: the real number is encrypted and sent to the network and your bank at provisioning; what is true and narrower is that the wallet cannot decrypt the token it receives back and its servers do not store it.

Wrong: your bank issues and controls the token in your phone. Right: for the overwhelming majority of device tokens the Token Service Provider is Visa or Mastercard, which owns the vault and the mapping table, mints the value, holds the validation keys and de-tokenises before the message reaches the issuer.

Wrong: tokenisation is a phone technology. Right: tokens are issued in enormous numbers to merchants, wallets and acquirers, living in ordinary databases with no secure element, no biometric and no per-tap cryptogram.

Wrong: the Payment Account Reference is a kind of substitute card number. Right: it is a 29-character identifier that cannot be reverse-engineered to a PAN or a token and cannot initiate a financial transaction.

Wrong: a receipt whose last four digits do not match the plastic is a misprint. Right: those are the token’s last four digits, and they are the easiest available proof that the phone is not sending your card number.

Wrong: a reissued plastic card means re-adding the card to the wallet. Right: the TSP updates the token-to-PAN mapping in the vault and the token keeps working, which is also why a fraud reissue needs the issuer to suppress that update deliberately.

Wrong: host card emulation is a software secure element. Right: its keys sit in ordinary application memory and are made nearly worthless by limited-use thresholds, so an HCE wallet left unused and offline will eventually decline — correctly.

Wrong: the 2021 Express Transit attack broke tokenisation. Right: the token and the cryptography worked exactly as designed; what failed was one deliberately relaxed domain control, on one platform, for one scheme.

19.99 Chapter summary in 20 lines#

1. When you tap your phone, your card number is not transmitted at all: a different number is.
2. That substitution is payment tokenisation, specified by EMVCo in a royalty-free, publicly available technical framework.
3. A Payment Token is a 13 to 19 digit Luhn-valid surrogate drawn from a real ISO BIN range, which is exactly why it traverses the existing network unchanged.
4. It carries its own expiry date, mapped by the vault to the account’s expiry and not obliged to equal it.
5. It is minted by a Token Service Provider registered with EMVCo under a three-digit code, on behalf of a Token Requestor identified by an eleven-digit ID.
6. The vault holding the token-to-PAN mapping usually belongs to the network rather than to your bank, which is a real operational dependency invisible from the cardholder’s side.
7. On a phone the token is written into a secure element, a certified Java Card platform chip, and the key that signs each tap never leaves it.
8. Every tap produces an eight-byte cryptogram from that key, a counter that only increases and the terminal’s unpredictable number, so it cannot be replayed anywhere.
9. The device also asserts that the holder was verified on the device, which is why a phone pays £180 where a plain contactless card stops at £100.
10. A stolen token is close to worthless because of three separate walls: domain restriction, the missing cryptogram key, and the absence of any link back to you.
11. Domain restriction is enforced by token requestor ID, by POS entry mode and by merchant identity — and only as strongly as the checking party implements it.
12. Your real card number does leave the phone once, at provisioning, encrypted to the network and the issuer, because they must know which account you are asking to tokenise.
13. Provisioning is therefore the security-critical moment, gated by identification and verification whose outcome the industry calls green, yellow or red.
14. Yellow is where the design lives or dies, because a token stuck awaiting activation is a card the customer believes they have added and cannot use.
15. Where there is no secure element, Android’s host card emulation holds keys in application memory and neutralises the risk with limited-use keys bounded by time, count or amount.
16. The practical difference between the two architectures is availability rather than cryptography: an HCE wallet that cannot reach the network eventually stops paying.
17. Because one account now wears many numbers, the industry had to invent the Payment Account Reference to tie them back together without exposing the account.
18. The token has a lifecycle of its own and can be suspended, deactivated or remapped in the vault in seconds, leaving the plastic, the account and every card-on-file arrangement untouched.
19. The only serious public break of the model, the 2021 Express Transit relay, exploited a deliberately relaxed exemption rather than any cryptography.
20. The phone does not carry your card number; it carries a second one, cut for that phone, that the bank can throw away.

Sources: EMV Payment Tokenisation Specification – Technical Framework, EMVCo, v2.4 (9 July 2026) and v2.3 glossary; EMVCo Token Service Provider and BIN Controller ID registration programme pages; EMV ICC Specifications for Payment Systems Book 3 Annex A for base tag definitions; EMV Mobile Payment: Software-Based Mobile Payment Security Requirements and the SBMP Security Evaluation Process, EMVCo; EMVCo Payment Account Reference: A Primer, Secure Technology Alliance, April 2018; EMV Payment Tokenization Primer and Lessons Learned, U.S. Payments Forum, June 2019; Technologies for Payment Fraud Prevention: EMV, Encryption and Tokenization, Smart Card Alliance, October 2014; Industry Perspectives on the Evolution of EMV Payment Tokenization, Federal Reserve Bank of Boston, 2019; Apple Platform Security — card provisioning, Apple Pay component security and payment authorisation; Apple PassKit in-app provisioning documentation; Google Pay device tokenisation developer documentation, including ID&V best practices and app-to-app ID&V; Mastercard Developers, MDES pre-digitisation and customer service documentation; Visa Smart Debit/Credit and Visa payWave U.S. Acquirer Implementation Guide for DE 22 values; Android host-based card emulation developer guide; ISO/IEC 14443, ISO/IEC 7816-4 and ISO/IEC 7816-5; Radu, Chothia, Newton, Boureanu and Chen, Practical EMV Relay Protection, University of Birmingham and University of Surrey, 2021; Basin, Sasse and Toro-Pozo, The EMV Standard: Break, Fix, Verify, IEEE S&P 2021; PCI Security Standards Council FAQ on acquiring, issuer and payment tokens; Visa newsroom, 4 June 2024; Mastercard newsroom, June 2025. Tag collisions on 9F6E cross-checked against EFTlab’s EMV and NFC tag list and emvlab.org.