You add a card to Apple Pay, tap at a café, and a $4.80 flat white goes through. Somewhere in that half-second, a number identified your account to the coffee shop’s bank. It was not the number printed on your card.
Apple says so directly. “Full card numbers aren’t stored on the device or on Apple Pay servers,” and “Neither Apple nor the user’s device shares full card numbers with merchants.” Something else does the job.
Knowing what that something is answers the questions people actually have. Can a hacked merchant drain the card in my phone? What happens when I get a new handset, or the bank sends new plastic? And why is the “virtual card number” my bank offers a completely different thing, even though both are sold as “not your real card number”?
Two numbers, one account
Your card has a PAN — Primary Account Number, the long number embossed on the front. In tokenization language that is the FPAN, the Funding PAN: the number that identifies the account holding the money.
When you add that card to a phone, a second number comes into existence. Apple calls it the Device Account Number; the industry calls it a DPAN, or more generally a network token. Apple’s own description of provisioning is precise: “A unique Device Account Number is created by the card issuer, sent encrypted to Apple, and then stored in the Secure Element.”
Three things follow from that one sentence.
It is not a second account. The DPAN points at the same card, the same balance or credit line, the same statement. Nothing is duplicated except the identifier.
Your bank made it, not Apple. Apple ships your card details to “the card issuer or card issuer’s authorized service provider” and receives a token back. Apple is a courier and a safe, not the vault.
It is shaped like a card number on purpose. Terminals, acquirers, and every message format in between were built to carry an account number of a particular shape. A token that fits that shape travels those rails without anyone rewriting them. That is also why the Device Account Number shown in a card’s Wallet details ends in different digits from the card in your pocket.
Who does what: requestor, token service, issuer
Three roles sit behind every network token.
The token requestor is whoever asks for one. For Apple Pay, that is your device and Wallet, acting through Apple. It does not have to be a phone: a merchant that keeps your card on file, or a payment service provider, can be a token requestor too. Same machinery, different requestor.
The token service provider (TSP) runs the vault that maps token to PAN and back. In practice the card networks operate these, under the issuer’s authority. EMVCo, the body that publishes the tokenisation specification, “manages and assigns TSP Codes worldwide to ensure that each TSP issuing EMV Payment Tokens is uniquely identifiable on a global basis.”
The issuer decides. It approves the request, it creates the token, and — the part that matters most below — it sets the rules the token has to live by. It is the same cast that handles an ordinary card payment, laid out in the four-party model, with one new member: the token service.
Why a stolen token is close to worthless
Two separate locks make a captured token hard to spend. Neither works alone.
Lock one: the token is only allowed to do certain things. EMVCo puts it plainly — a payment token “is constrained in how it can be used. For example, to a specific merchant, device or payment scenario.” Apple’s provisioning documentation gives the concrete version: an issuer can restrict a Device Account Number “to prevent its use on a magnetic stripe card, over the phone, or on websites.”
Read that again, because it is the whole point. The number in your phone can be barred, at the issuer, from ever working in a web checkout box. It is not a card number that happens to be hidden. It is a card number that is not permitted to leave its lane.
Lock two: the token never travels alone. Each tap carries “a payment cryptogram along with a Device Account Number” — a one-time value built from transaction counters and keys provisioned into that device’s Secure Element. Capture the radio traffic and you get a token plus a cryptogram that has already been spent. Present it again and the arithmetic fails.
There is a third gate before either of those: “A payment can be made only after the Secure Element receives authorization from the Secure Enclave.” That is your Face ID, Touch ID, or passcode.
Compare that with a plain card number. A PAN, expiry date, and three-digit code are a bearer credential — anyone holding them can attempt a charge, anywhere the issuer allows. That is why breach headlines are frightening for stored card numbers and boring for stored tokens. The authentication layer on top of typed-in card numbers is a separate mechanism, covered in 3-D Secure and SCA, and the approval message itself is pulled apart in inside a card authorization.
New phone, new card, lost phone
The token’s separateness from the card is what makes life events behave the way they do.
Adding the card to a second device provisions a second token. The name is honest: it is a Device Account Number. Your watch and your phone each hold their own, which is why you enrol each one and why removing a card from one device leaves the other working.
Getting new plastic does not necessarily mean re-adding your card. Because the token and the PAN are two different numbers joined by a mapping held at the token service, the underlying card number can be changed while the token stays the same. Whether your wallet keeps working through a reissue without you touching it depends on your issuer supporting that update. It is a fair question to ask before you rely on a phone as your only card abroad.
Losing the plastic is not the same as losing the token. When an issuer cancels a compromised card it can either re-point the existing tokens at the new PAN or terminate them. Issuers differ. If your phone stops paying the day after a card replacement, that choice is why.
Losing the phone is the case people get wrong. You do not have to cancel the card. Apple’s guidance: placing the device in Lost Mode via Find My suspends Apple Pay, and erasing it means “that device instructs the Secure Element to mark all cards as terminated,” while the Secure Enclave “marks the AR value as invalid so that further payment authorizations for previously enrolled cards aren’t possible.” You can also remove the device from iCloud.com or from your Apple Account. The card in your drawer is untouched.
One more piece keeps all of this coherent. EMVCo defines a Payment Account Reference (PAR) as “a way to link transactions that use EMV Payment Tokens with the PAN for which the Payment Tokens have been issued.” So your issuer, and a merchant that receives it, can still tell that the phone tap, the watch tap, and the plastic swipe are one account — for loyalty, risk scoring, and recurring billing — without any of them handling your card number.
A virtual card number is not an Apple Pay token
This is the confusion worth spending a minute on, because the marketing word is identical and the security model is not.
A virtual card number is a real card number. Your issuer generates it on your existing account, shows you a fresh number, an expiry, and a security code, and you type them into a checkout form like any other card. Its protection comes from scope and revocability: it is often locked to one merchant, capped at an amount, given a short life, and deleted with one tap. If it leaks, whoever holds it can attempt a charge — what stops them is the limits you set, not cryptography.
An Apple Pay token cannot be typed into anything. There is no form field it fits. It only functions alongside a cryptogram that the Secure Element generates for one transaction, and the issuer can forbid it from web and telephone use outright.
There is a third case that belongs on the same shelf. A merchant or gateway can hold a card-on-file network token instead of your PAN — no device, no digits you ever see, but still a scheme-issued token restricted to that merchant. Breach that merchant and the attacker gets something that works nowhere else.
So “tokenized” is being used for at least three arrangements with different failure modes. When a product claims it, the useful questions are: who issued the token, what is it allowed to be used for, and does anything one-time-only travel with it?
Where crypto cards sit
A crypto card shows you a number in an app, and the same questions apply — with one reassuring answer up front.
The wallet layer does not care how your card is funded. Add a stablecoin-backed Visa or Mastercard to Apple Pay and it gets provisioned like any other card: issuer-created token, Secure Element, cryptogram. The conversion from USDT to fiat happens behind your issuer, invisible to the merchant, which is the same reason clearing and settlement look completely ordinary from the outside.
The number inside the provider’s own app is the part to check. Some providers issue genuinely disposable, merchant-scoped numbers. Others show one static PAN for the life of the card and call it a virtual card. Both are legitimate products; only one limits the damage when a merchant you paid six months ago gets breached. Our RedotPay vs Bybit Card comparison looks at how providers differ, and the crypto card guide covers what else to read in the terms.
Tokenization protects the number, not the money. It does nothing about a top-up spread, an FX markup, or a provider that freezes your balance. And it changes nothing about your dispute rights, which come from the card network’s rules rather than the technology — see chargebacks vs crypto. What the merchant pays on that same tap is a separate story again, told in interchange.
Quick answers
- Does the merchant ever see my card number? No. Apple: “Neither Apple nor the user’s device shares full card numbers with merchants.”
- Does Apple see it? At setup it encrypts and routes your card details to the issuer. Full card numbers are not stored on the device or on Apple Pay servers.
- Is the number in Wallet a different account? No — a different identifier for the same account, which is why one statement covers both.
- My phone was stolen. Do I need to cancel my card? Not for that reason alone. Lost Mode suspends Apple Pay and erasing the device terminates the cards held in its Secure Element.
- Is my bank’s virtual card number the same as Apple Pay? No. It is a real card number you type; the security comes from limits and deletion, not from a one-time cryptogram.
- Why do tokenized payments sometimes get approved more readily? The issuer knows the payment came from an enrolled device with dynamic proof attached, which is stronger evidence than digits in a form. The rest of that decision is in the payment authorization guide, and the auth flow demo steps through the round trip.
The short version: your phone holds a number that is useless outside your phone, made by your bank, mapped back to your card by a vault neither you nor the merchant ever touches. The plastic in your wallet is the more dangerous object.