Apple Pay and Google Pay look almost identical at checkout — a face scan or thumbprint, then done — but the two systems are built differently under the hood, and those differences show up in exactly how the payment is secured and how portable it is across devices.
The shared idea: a device token, not your card
Both wallets work the same way at the core: instead of storing your real card number, your phone stores a device-specific token — a "device account number" — that's tied to that specific phone and useless if copied to another device. Every payment sends that token, not the underlying card number, to the merchant.
Where Apple Pay and Google Pay actually differ
Apple Pay leans on hardware — a dedicated Secure Element chip plus Face ID or Touch ID are required, so the token and the authentication both live in isolated, dedicated hardware. Google Pay instead relies more on Host Card Emulation, doing more of that work in software, which is why it can run on a wider range of Android devices without requiring the exact same secure chip — a flexibility trade-off for a slightly different security architecture.
Why merchants see similar benefits either way
Despite the underlying differences, both give merchants the same practical wins: a tokenized number that's worthless if intercepted, biometric authentication instead of a typed card number, and a checkout that's often one tap instead of a full form — which is exactly why wallet transactions tend to convert and authorize better than manually entered cards.
Key takeaways
- Both wallets replace your real card number with a device-specific token.
- Apple Pay relies on a dedicated secure hardware chip; Google Pay uses a software-based approach (HCE), letting it run on more devices.
- Neither wallet exposes your actual card number to the merchant at any point.
- The practical merchant benefit — better conversion, tokenized security — is nearly identical despite the different architectures.