How Mobile Wallets Work: Apple Pay, Google Pay, and the Tech Behind Tap-to-Pay

When you tap your phone at a coffee shop terminal, your actual card number never leaves your device. Not to the terminal. Not to the merchant. Not even to Apple.

Apple built a system where even Apple doesn't know what you bought. Your transaction is invisible to them in the most literal sense — the cryptographic design makes it structurally impossible for Apple to see it.

That's not just clever engineering. It's a business model. Understanding how mobile wallets actually work tells you something important about who controls the future of payments — and why Apple was willing to spend years in regulatory fights to protect it.

The Problem Mobile Wallets Solved

Physical cards have a dirty secret: the 16-digit number on the front is all anyone needs to commit fraud.

The magnetic stripe — invented in the 1960s, still on your card today — encodes your card number, expiration date, and a static verification value. Swipe it, and that data is transmitted in plaintext to the terminal. Anyone with a card skimmer can capture it and clone the card.

The 2013 Target breach made this visceral. Hackers installed malware on Target's point-of-sale terminals and captured card data from 40 million customers in real time, as cards were being swiped. The data was selling on dark web forums within weeks. The card number was the vulnerability — it was both the identifier and the authentication credential, and it never changed.

Card-not-present (CNP) fraud is the same problem in e-commerce. Enter a card number into a website, and that number can be stolen, sold, and used anywhere in the world before you've finished your checkout session.

The payments industry's first answer was EMV chip cards. The chip generates a unique transaction code for every purchase, making card cloning far harder. But the underlying card number was still exposed to merchants and their systems. A breach at a processor could still yield usable data.

Mobile wallets solved this at the root. The real card number never goes anywhere. The merchant never sees it. The terminal never sees it. What the terminal gets is a surrogate number — a token — that is mathematically useless without the network infrastructure to decode it, and valid only for that single transaction.

How NFC Actually Works

Near-field communication operates at 13.56 MHz and works at a range of about 4 centimeters. That range is not an accident. It is a deliberate security parameter.

The underlying standard — ISO/IEC 14443 — was originally designed for contactless smart cards. Apple Pay, Google Pay, and every contactless terminal you've ever tapped are all speaking the same standardized protocol. Your phone is, at the RF layer, pretending to be a smart card.

When you hold your phone near a terminal, both devices go through a rapid handshake. The terminal broadcasts a radio field. The phone detects it and responds with its identifier. They negotiate the communication speed, establish a channel, and then the payment application takes over. The entire handshake takes milliseconds.

The short range is what makes eavesdropping impractical. An attacker would need to be within centimeters of both your phone and the terminal simultaneously to intercept the signal. At the grocery store, that is not a realistic threat model.

The critical thing to understand about NFC is that it is just the transport. It is the pipe. What matters is what travels through it — and that is where tokenization comes in.

Tokenization: The Core Innovation

Tokenization is the idea that replaces your real card number with a surrogate value — a token — that has no intrinsic value outside of the specific context it was issued for.

When you add a card to Apple Pay or Google Pay, your phone sends the card details to the card network (Visa or Mastercard). The network's Token Service Provider — Visa Token Service or Mastercard MDES — generates a Device Account Number, or DAN. This is a 16-digit number that looks like a card number but is not your card number. It is permanently associated with your device and your card, but it cannot be used anywhere else.

The DAN is stored securely on your device. Apple stores it in the Secure Element, a dedicated tamper-resistant chip. Google takes a different architectural approach, which we will get to.

Here is where it gets interesting: every single tap generates a one-time cryptogram, a dynamic security code that is unique to that transaction. Even if someone captured everything transmitted between your phone and the terminal — the DAN plus the cryptogram — they could not replay it. The cryptogram is invalid the moment the transaction is complete.

Walk through a complete Apple Pay transaction and this becomes concrete:

1. You hold your phone near the terminal and authenticate with Face ID or Touch ID.
2. The Secure Element generates a transaction-specific cryptogram using the DAN and a transaction counter.
3. This package — DAN plus cryptogram — is transmitted via NFC to the terminal.
4. The terminal sends it to the merchant's acquirer (the bank that processes payments for the merchant).
5. The acquirer routes it to Visa or Mastercard.
6. The card network's Token Service Provider recognizes the DAN, validates the cryptogram, and maps the DAN back to your real card number.
7. The detokenized transaction — now carrying your real card number — goes to your issuing bank for authorization.
8. The issuer approves or declines and sends the response back through the chain.
9. The terminal displays approved. You pick up your coffee.

Your real card number exists in this flow, but only between Visa's servers and your bank. The merchant, the terminal, and the acquirer only ever see the token. A breach at the merchant level yields nothing useful.

Secure Element vs HCE: Apple vs Google's Architecture

Apple and Google made fundamentally different architectural choices, and those choices reflect fundamentally different business priorities.

Apple's approach: the Secure Element. The SE is a dedicated chip, physically separate from the main processor, running its own operating system. It is tamper-resistant — physically destroying it before extracting data is easier than breaking the encryption. The DAN lives there. The cryptogram is generated there. The SE can operate without a network connection because everything it needs is stored locally. Apple controls what runs on the SE, which is why adding a card to Apple Pay requires Apple's cooperation — and Apple's business terms.

Google's approach: Host Card Emulation (HCE). Instead of a dedicated chip, HCE emulates a card in software, running on the main processor, with tokens retrieved from the cloud. This is more flexible — it works on any NFC-capable Android device without specialized hardware — but it requires a network connection to fetch a fresh token for each transaction. Google's architecture made it far easier for any bank or fintech to build their own Android wallet without going through Google's SE. The trade-off is a slightly more complex token lifecycle and a dependency on connectivity.

Samsung Pay: the third path. Samsung added MST — Magnetic Secure Transmission — to its devices, which can generate a magnetic field that mimics a card swipe. This meant Samsung Pay worked on terminals that had no NFC capability at all, which was a genuine differentiator in markets with older terminal infrastructure. MST is largely irrelevant now as NFC terminal penetration has grown, and Samsung has deprioritized it.

The architectural difference between Apple and Google is not primarily technical. It is political. Apple's SE control let it sit at the center of every iPhone payment transaction and extract rent from everyone who wanted to be there.

Why Apple Charges 0.15% — and Why Banks Paid It

Apple negotiated approximately 0.15% — roughly 15 basis points — of each transaction value from US card issuers for every Apple Pay transaction. In markets like the UK and Australia, the rate was lower. But on a $100 purchase in the US, Apple takes fifteen cents before the merchant, the acquirer, or anyone else gets paid.

For context: US interchange rates average around 2% of transaction value for credit cards. Apple is extracting roughly 7-8% of the issuer's interchange revenue and doing so without touching the transaction economics on any other side.

Banks paid because they had no choice. Apple controlled the Secure Element on every iPhone. If a bank wanted its cards to work with Apple Pay — and customers were increasingly expecting that — the bank had to agree to Apple's commercial terms. There was no way to build a competing wallet on iPhone hardware. Apple had built a toll booth, and the only road went through Cupertino.

The EU saw this clearly. In 2024, under the Digital Markets Act, the European Commission required Apple to open NFC access on iPhones to third-party developers. For the first time, a bank or fintech could build a wallet on iPhone that accessed the NFC chip directly — without going through Apple Pay, without paying Apple's fee, without Apple in the middle at all.

What this means for the ecosystem is still playing out. In Europe, banks have genuine leverage for the first time. In the US, where no equivalent regulation exists, Apple's toll booth stands.

This is worth sitting with: Apple built a business that extracted hundreds of millions of dollars annually from the global banking system by controlling a chip on a consumer device. It did not build a bank. It did not take credit risk. It held a key — the Secure Element — and charged admission.

The Global Wallet Wars

The NFC versus QR code split in global payments is one of the most instructive case studies in how infrastructure shapes product.

China had no incumbent card payment infrastructure to protect. Visa and Mastercard were marginal players. When WeChat Pay and Alipay launched mobile payments, they used QR codes — which require nothing but a smartphone camera and a printed code. No NFC hardware. No Secure Element. No card network in the middle. A merchant could accept payments with a piece of paper.

WeChat Pay and Alipay now process tens of billions of transactions monthly. They became the operating system for commerce in China — and then expanded to become super-apps where you can hail a taxi, buy insurance, book a doctor, and pay a utility bill. Payments were the entry point to everything else.

This model traveled. Paytm in India, GoPay in Indonesia, M-Pesa in Kenya — all built on the insight that where card infrastructure is thin, QR codes can leapfrog it entirely. India's UPI system took this further, making QR-based, real-time account-to-account payments the default for an economy of 1.4 billion people.

Apple and Google are watching the super-app playbook and trying to replicate it in Western markets where they have the installed base but not (yet) the regulatory permission to offer lending, insurance, and brokerage inside the wallet. Apple launched a savings account in 2023 and a buy-now-pay-later product before quietly shelving it. The ambition is clear even where execution has been bumpy.

The difference between WeChat's success and Apple's ambitions is not product. It is regulatory environment and timing. WeChat built its financial services layer before Chinese regulators built guardrails. Apple is trying to build the same layer in markets that already have fully functional, entrenched financial systems with lobbyists.

Where Mobile Wallets Are Heading

Three trends are worth watching.

Tap-to-phone (SoftPOS). Traditionally, merchants needed dedicated POS hardware to accept contactless payments. SoftPOS turns any NFC-capable Android phone into a payment terminal. A food truck driver or market vendor can accept Apple Pay with no hardware beyond their own phone. Stripe, Adyen, and Visa have all invested heavily here. This expands the addressable market for card acceptance substantially.

Digital identity in wallets. Apple already supports digital driver's licenses in a handful of US states, stored in the Wallet app. The same infrastructure that stores your payment credentials can store government-issued identity. TSA accepts the Apple Wallet ID at select airports. This is a significant expansion of what a wallet is — from a payments device to an identity device. It also gives Apple an entirely new category of leverage over ecosystems.

Account-to-account payments and open banking. The longer-term threat to card-based mobile wallets is not another wallet — it is direct bank transfers. In the UK, Variable Recurring Payments (VRPs) under open banking let apps initiate bank transfers on your behalf. In the US, FedNow and RTP are building real-time settlement rails. If a merchant can take a bank transfer that settles instantly at a fraction of the interchange cost, the card network — and Apple's toll on top of it — can be bypassed entirely. This is early and regulatory complexity is significant. But the direction is clear.

Mobile wallets solved a real problem — card fraud — and built genuine technical sophistication to do it. The Secure Element, tokenization, and dynamic cryptograms are not marketing copy. They represent a meaningful security improvement over the mag stripe world they replaced.

But the business model wrapped around that technology is what makes mobile wallets interesting. Apple used a security feature — Secure Element control — to build a payment toll booth. Google used openness to compete for volume. And the rest of the world used QR codes to skip the infrastructure fight entirely.

The wallet wars are not over. They are just entering a more complex phase.

Key Takeaways

• When you tap your phone to pay, your real card number never leaves your device. A one-time token and a dynamic cryptogram are what actually hit the terminal.
• NFC is just the transport layer — 13.56 MHz radio at 4cm range. Tokenization is the security innovation.
• Apple's Secure Element is a dedicated chip; Google's HCE approach stores tokens in the cloud. The architectural difference is as much about business control as it is about security.
• Apple charges issuers ~0.15% per Apple Pay transaction in the US. Banks paid because Apple controlled the only door into iPhone payments — a toll booth built on hardware control.
• The EU's Digital Markets Act forced Apple to open NFC access to third parties in 2024 — the first significant crack in that model.
• Globally, QR code wallets (WeChat Pay, Alipay, UPI) outpaced NFC in markets without incumbent card infrastructure, proving that the best payment tech wins only when the existing infrastructure lets it.

Related Reading

• How Visa Processes 65,000 Transactions Per Second — The network rails that mobile wallets run on top of, explained.
• What Is a Payment Gateway vs a Payment Processor? — Where the merchant's side of the transaction actually lives.
• How ACH Payments Work — The account-to-account rails that could eventually challenge card-based wallets in the US.