How Apple Pay and Google Pay Use NFC — A Plain-English Walkthrough
Tapping your phone to pay looks the same whether you're on iOS or Android, but the two systems protect your card number in different ways — one in a dedicated chip, one in software. Here's what actually happens during that tap.
Apple Pay and Google Pay both use NFC to send a stand-in for your card number — never the real one — to a payment terminal, plus a one-time code good for that single transaction. Apple leans on a dedicated security chip; Google mostly relies on software. Here's what's happening in the second after you tap.
What It Is: The One-Paragraph Answer
When you tap to pay, your phone isn't handing over your card number at all. Apple Pay generates a Device Account Number using the EMV Payment Tokenization Specification — a substitute number tied to that one device, encrypted, and stored on-phone. Google Pay does the same job with a Device Primary Account Number, or DPAN, swapped in for your card's real Funding Primary Account Number. Both then attach a dynamic security code, freshly generated for that transaction, so the token can't be captured and reused somewhere else. The terminal reads the token and the code — nothing more.
How It Actually Works
The tap itself only works at close range. Your phone and the terminal need to sit within a couple of inches of each other, which is why the underlying radio link is deliberately short — we've written about the physics behind that if you want the full explanation.
Apple Pay keeps its token in a dedicated hardware chip, the Secure Element. Card data arrives encrypted from the card issuer into isolated applets in that chip, using keys nobody outside the issuer and the chip ever holds. During the actual tap, the NFC controller routes traffic directly between the terminal and the Secure Element, bypassing the phone's main processor entirely — your face or fingerprint unlocks the Secure Enclave, which then signals the Secure Element to answer the terminal.
Google Pay mostly takes a software route called host-based card emulation, or HCE. Android added HCE in version 4.4 specifically so any app could emulate a payment card without needing a separate secure chip built into every phone. Under the hood, the terminal and phone exchange the same kind of data packets — APDUs, defined by ISO/IEC 7816-4 — that a physical smart card would use, except they're handled by your phone's main processor instead of a chip. An Application ID tells the phone which app should answer a given tap, which is how the system knows to hand the transaction to Google Pay rather than some other card-emulating app.
Where You'll See It
Both work at any contactless-capable point-of-sale terminal — look for the sideways Wi-Fi-like symbol at checkout — plus inside apps and websites with an "Apple Pay" or "Google Pay" button. On the Google Pay side, adding an eligible card to Google Wallet automatically creates a virtual card; that's the DPAN doing its job. Google also blocks tap-to-pay on rooted phones or unlocked bootloaders, since those change what the OS can guarantee about token handling.
Separate this from the NFC you'll run into elsewhere. A payment terminal and an NFC tag on a business card or Wi-Fi sticker share the same radio band, but only one of them involves a bank.
Tips, Gotchas, and a Quick How-To with NFCore
NFCore doesn't read, write, or store payment tokens — it's built for the plain NDEF tags you own: a Wi-Fi password on a sticker by your router, a vCard on a business card, a trigger tag by your front door. Those tags hold a static, unencrypted record you wrote yourself, a very different thing from the live encrypted handshake your phone runs with a bank on every tap.
If you're curious what an NFC tag you already own actually contains, open NFCore and scan it — you'll see exactly what's stored, in plain view.
Frequently Asked Questions
Does Apple Pay or Google Pay ever send my real card number to a store?
No. Both send a tokenized, device-specific number instead — a Device Account Number on Apple Pay, a DPAN on Google Pay — plus a one-time code good for that single transaction only.
What's the difference between Apple Pay's Secure Element and Google Pay's HCE?
Apple Pay keeps the token in a dedicated hardware chip, isolated from the main processor. Google Pay mostly uses host-based card emulation — software Android added in version 4.4 that skips the separate chip. Same goal, different route.
Can someone intercept my tap the way they might skim a card's magnetic stripe?
It's far harder. The security code is generated fresh per transaction and isn't reusable, and NFC's short range limits interception attempts in the first place. There's no reusable card number to steal even if a tap were somehow captured.
Is this the same NFC that NFCore reads and writes?
Same radio technology, different use. Apple Pay and Google Pay run an encrypted, tokenized handshake with a bank. NFCore reads and writes plain, unencrypted NDEF data on tags you own — there's no card data involved at all.
Conclusion
Apple Pay and Google Pay solve the same problem two ways: keep your real card number out of a merchant's hands, whether that protection lives in a dedicated chip or in sandboxed software. Either way, what leaves your phone is a token and a one-time code, never your card. Curious why the tap has to happen so close? The NFC range and distance breakdown covers the physics.