Srikanth Badavath
never leaves your phone.
I pay with Apple Pay probably a dozen times a week without really thinking about it. Double-click the side button, glance at the screen, hold the phone near the terminal — beep. Done. Genuinely faster than pulling a card out of my wallet.
But I started wondering: what just happened? In that half-second, my phone, some hardware chip I've never laid eyes on, a payment network, and my bank all coordinated a money transfer. And my actual card number was never part of the conversation.
That's strange when you sit with it. Here's the whole thing, broken down. (Note: Apple Pay is available in the US and 70+ other countries — this post uses the US credit card and payment network context throughout.)
How a Physical Credit Card Actually Works
A physical credit card is basically a master key to your bank account. That key is your Primary Account Number (PAN) — the 16-digit number printed on the front. (Unrelated to the Indian tax ID by the same name — in the card industry, PAN is standard ISO/IEC terminology for your card number.) Every time you tap, dip, or swipe at a US merchant, you're handing a copy of that key to a stranger: the cashier, the POS terminal, the payment processor, whoever ends up handling the receipt data downstream.
The EMV chip (that gold square) was supposed to fix the worst of this. Instead of blasting your raw PAN to a magnetic reader, it generates a one-time cryptogram proving the card is physically present — much harder to clone. But here's what nobody puts in the brochure: the PAN itself still travels to the terminal. The merchant's processor receives it. Their database often stores it. And if their systems get hit — Target in 2013, Home Depot in 2014, dozens of smaller retailers every year — your actual card number ends up in the wild.
Apple Pay takes the PAN out of the picture completely. The merchant's terminal never sees it. Not the processor, not the acquirer, not anyone on the other side of the counter. That's not a marketing claim — it's a technical fact enforced by hardware. Here's how it works.
Part 1 — NFC: How the Token Reaches the Terminal
NFC sounds exotic but the physics are surprisingly simple. The terminal generates a small alternating magnetic field at 13.56 MHz — the same frequency used by building access cards and London's Oyster card. When your iPhone comes within 4 cm, that field induces a tiny current in the phone's NFC antenna, which powers the NFC controller and kicks off the data exchange. Your phone needs zero internet for this step. It's literally harvesting energy from the terminal's own field to complete the handshake — which is why Apple Pay works fine in airplane mode. The terminal's connection handles the network round-trip, not yours.
Part 2 — The Secure Element: A Vault on Your Chip
Most people don't know this chip exists. Inside your iPhone, physically separate from the main A-series processor, sits a dedicated chip called the Secure Element. It has its own CPU, its own encrypted storage, and its own operating system (JavaCard). iOS cannot access it. Apps definitely can't. Apple's servers can't either.
And here's the part I think is genuinely impressive: if someone physically disassembled your phone and probed the chip's pins directly, it would detect the intrusion and erase its own keys before giving anything up. The hardware self-destructs rather than talk.
inside your iPhone
When you add a card to Wallet, here's what actually happens: Apple sends your card details to your bank. Your bank generates the Device Account Number and writes it directly into the Secure Element over an encrypted channel. Apple's servers never receive the DAN. Apple never sees the mapping. The only places that know "DAN 4784 1209 8823 6641 = your Visa card" are your bank and Visa's Token Service Provider — and that mapping never leaves those two systems.
Part 3 — Tokenization: What the Merchant Actually Receives
When you pay, the Secure Element doesn't just fire the DAN over NFC raw. It assembles a payment token from three ingredients:
- Device Account Number (DAN) — your device's proxy card number
- Dynamic cryptogram — signed with your bank's key, computed from the DAN + a transaction counter + the exact payment amount
That transaction counter is the clever part. It increments every single time you pay. The cryptogram is mathematically bound to DAN + this specific counter value + this exact dollar amount. If someone intercepted it and tried to replay it five seconds later at a different terminal, the bank would reject it instantly — the counter has already moved forward and the cryptogram no longer validates. You can't reuse an Apple Pay token. Architecturally impossible.
The Apple Card — and Why Tapping Is Always Better Than Inserting
The physical Apple Card is a nice piece of titanium with no number on the front — intentionally. It's designed to be used through Apple Pay on your iPhone, not handed to someone. But here's the catch: if you do insert it into a terminal (the reader doesn't support NFC, or you hand it to a waiter at a restaurant), you're right back to the traditional credit card model. Your PAN travels. The security advantage evaporates completely. The titanium is just aesthetic at that point.
The protection lives in the phone — not the card.
Goldman Sachs
Part 4 — The Complete Transaction Flow
Now that the three layers are clear — NFC (how data moves), Secure Element (where keys live), tokenization (what actually gets sent) — here's the full chain from double-click to terminal beep.
The 420 Milliseconds, Broken Down
Credit Card vs Apple Pay — Security Comparison
| Attack scenario | Physical credit card | Apple Pay |
|---|---|---|
| Merchant database breach | Real PAN exposed and usable | Only DAN exposed — device-bound, useless without cryptogram |
| Terminal malware (RAM scraping) | PAN captured in plaintext during processing | Only a spent cryptogram is in RAM — already invalid |
| NFC/contactless skimming | PAN readable via NFC on most contactless cards | DAN + single-use cryptogram — replay attack is impossible |
| Phone stolen (locked) | N/A — card is separate | Requires Face ID / Touch ID — attacker cannot pay |
| Phishing for card number | PAN + CVV obtained → card can be used online | DAN alone is useless online without a live SE-generated cryptogram |
| Merchant sees real PAN | Yes, in every transaction | No — merchant only sees DAN and approval code |
- A physical credit card sends your real card number (PAN) to the merchant's terminal in every transaction. If that terminal or its database is compromised, your card is at risk.
- Apple Pay replaces the PAN with a Device Account Number (DAN) — a 16-digit proxy number stored in the Secure Element and mapped back to your real card only at the bank.
- Every Apple Pay transaction generates a dynamic cryptogram tied to the DAN + a counter + the payment amount. It is valid for exactly one transaction. Replay attacks are architecturally impossible.
- NFC transfers the token over electromagnetic induction at 13.56 MHz. No internet required on your phone — the lookup happens on the terminal's network.
- The Secure Element is a physically separate tamper-resistant chip. iOS cannot read it. Apple cannot read it. Attempted physical extraction triggers self-erasure.
- Face ID / Touch ID authentication runs entirely inside the Secure Enclave — a different isolated processor. No biometric data is transmitted or accessible to any app or server.
- The entire journey — biometric auth, SE token generation, NFC transfer, card network routing, TSP detokenization, bank fraud checks, and approval — takes under 420 milliseconds.