In a recent post I argued that you should replace your debit card and switch to Apple Pay or Google Pay for online purchases. A few people asked the obvious follow-up: why? What actually makes tapping your phone safer than tapping a physical card?
The honest answer is that most people — including me, until I looked into it properly — treat Apple Pay as a convenience feature with vague security benefits. Something about your card number not being transmitted, maybe. The reality is more precise and more interesting than that, and understanding it changes how you think about every card transaction you make.
Start with the problem: the PAN
Your card number — technically the Primary Account Number, or PAN — is the root of most card fraud. It’s a static 16-digit identifier tied to your account. Once someone has it, along with the expiry date and CVV, they can use it. It doesn’t change unless you cancel the card. Every merchant you’ve ever handed it to, or typed it into a checkout form, has at least temporarily held the keys to your account.
That’s not a design flaw in the sense that anyone got it wrong for its time. The card payment system was built when the main threat was someone skimming your details in a restaurant. It was never designed for a world where millions of those static numbers sit in merchant databases, waiting for a breach — or for AI models that can autonomously find and exploit the vulnerabilities in the software protecting those databases.
That last point is the new context. The threat to those static numbers has increased dramatically. Tokenisation is the structural answer to the underlying design problem.
What a token actually is
Tokenisation replaces your PAN with a token — a reference value that maps back to your real account number through a secure system, but has no exploitable meaning by itself. It looks like a card number — same 16-digit format — but it isn’t one. It’s a placeholder. Stolen tokens are worthless.
The critical detail is where the mapping lives. The table that translates a token back to a real PAN is held by the card network — Visa or Mastercard — not by the merchant, and not by Apple or Google. No merchant ever needs to touch your real card number. They receive a token, process it, and the network handles the rest invisibly.
Tokens are also constrained in how they can be used. A token issued for your iPhone cannot be used on a different device. A token issued for in-store NFC payments cannot be replayed for an online transaction. The technical term is Token Domain Restriction — the token is valid only in the specific context for which it was created. This is what makes a stolen token genuinely useless, rather than merely inconvenient to exploit.
What happens when you add a card to Apple Wallet
The setup process is where your real card number travels for the last time.
When you add a card to Apple Wallet, your card details are sent to Apple, which identifies your issuing bank and requests a token from the card network’s Token Service Provider. Your bank verifies the request — typically by sending a code to your registered phone number, or via your banking app. Once approved, the card network generates a Device Account Number (DAN): a token tied specifically to your device.
That DAN is stored in the iPhone’s Secure Element — a dedicated hardware chip physically separate from the main processor, isolated from iOS itself, inaccessible to apps including Apple’s own. Your real PAN is not stored on the device. Apple does not retain it after provisioning. From this point on, your real card number is effectively out of the picture.
What happens at the point of payment
This is where it gets particularly elegant.
When you authenticate a payment with Face ID or Touch ID, two things leave your phone via NFC to the payment terminal:
- The Device Account Number — the token representing your card on this specific device
- A dynamic cryptogram — a unique, one-time code generated specifically for that transaction
The cryptogram is the second layer of protection. It’s created using the DAN, a transaction counter, the payment amount, and other data, combined through cryptographic keys stored in the Secure Element. It is valid for exactly one transaction. Even if someone intercepted the full NFC transmission — DAN and cryptogram together — they would have data that is useless for any subsequent transaction. There is nothing replayable, nothing reusable.
The merchant’s terminal forwards both values to the card network, which validates the cryptogram and authorises the payment. The merchant’s bank never sees your real card number. The merchant never sees it. Nobody in the chain except your own bank and the card network ever handles your PAN — and they already had it.
Google Pay: same idea, slightly different architecture
Google Pay uses the same underlying tokenisation standard — EMVCo, the body behind chip-and-PIN — and the same concept of a device-specific token plus a per-transaction dynamic cryptogram.
The practical difference is in where the token lives. Apple stores the DAN in dedicated Secure Element hardware, and payment authorisation happens entirely on-device with no internet connection required. Google Pay on modern Android devices also uses a Secure Element where available, but some devices use Host Card Emulation — a software approach where token management routes through Google’s servers rather than a hardware chip. Transactions via HCE involve Google’s infrastructure as an intermediary, which introduces a degree of centralisation that Apple’s approach avoids.
In practice, both are vastly more secure than presenting a physical card or typing a number into a form. The token-plus-cryptogram model means merchants receive nothing reusable either way. The architectural difference matters more if you have strong views about cloud-based data handling than if your primary concern is payment fraud.
What this means when a merchant is breached
Return to the original question: if a merchant you’ve paid via Apple Pay suffers a data breach, does it affect you?
The answer is essentially no — and now you can see precisely why.
The merchant’s payment records contain your DAN and a set of already-used cryptograms, each of which was valid for exactly one transaction that has already happened. None of that is actionable. There is no PAN to steal, no static credential to replay elsewhere. The breach may still expose your name, email address, or delivery details if the merchant stored those — and most do — but the payment credential itself is a dead end.
This is the structural difference from entering your card number into a checkout form. That number is your real PAN: static, reusable, and valuable to anyone who obtains it. If it’s in a database that gets compromised, you have a problem. If you paid via Apple Pay, the merchant never had anything worth taking.
What tokenisation doesn’t cover
Worth being precise about the limits.
Tokenisation protects your card number specifically. It doesn’t protect your name, address, email, or purchase history — merchants still hold those and breaches still expose them. It doesn’t protect you from account takeover through your bank’s own systems. And it doesn’t help if you’re socially engineered into authorising a payment yourself.
The threat it defeats is the one responsible for most consumer card fraud at scale: static credentials sitting in merchant databases, waiting for either a direct breach or, increasingly, an automated AI-assisted exploit. For that specific and now significantly elevated threat, it’s a structurally robust defence.
Which is why the advice in the previous article wasn’t “use Apple Pay because it’s convenient.” It was “use Apple Pay because it removes your real card number from the merchant relationship entirely — permanently, by design.” That’s a meaningfully different proposition. Now you know exactly why.
Simon Griffiths 
Leave a reply to Anonymous Cancel reply