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 on ISO 20022, the structured payment-messaging standard now reshaping the payments stack. 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.

How Apple Pay, Google Pay, Samsung Pay, and Tap to Pay on iPhone Compare

The four mainstream wallet products in the US in 2026 differ less in what they do at the terminal than in who controls the rails, the security architecture, and the economics underneath.

The first three are wallets the buyer uses. Tap to Pay on iPhone inverts the model: the iPhone becomes the merchant terminal that accepts any contactless card or wallet at checkout. The category is the same NFC infrastructure; the role flip is the product.

Frequently Asked Questions

How do Apple Pay and Google Pay achieve global acceptance?

Apple Pay and Google Pay reach global acceptance by riding on top of the existing Visa, Mastercard, American Express, and Discover networks rather than building parallel rails. Every Apple Pay or Google Pay transaction is, from the merchant terminal's perspective, an ordinary EMV contactless card transaction. The token in the wallet behaves identically to a chip card at the point of sale. That means any terminal already certified to accept contactless EMV cards (the vast majority of new terminals deployed globally since 2017) accepts Apple Pay and Google Pay with no software change.

The acceptance footprint differs by region for two reasons. First, contactless EMV penetration is uneven; markets like Australia, the UK, Canada, and the Nordics are functionally contactless-by-default, while the US lagged for years and still has pockets that swipe rather than tap. Second, Apple Pay's issuer-side support depends on banks signing Apple's commercial terms in each country, so the wallet may be technically usable but missing partner card support in some markets. Google Pay's looser model (it can run on a wider Android device base and uses HCE without per-issuer hardware commitments) reaches new geographies faster but with thinner product features.

How do Apple Pay and Google Pay connect to card networks?

Apple Pay and Google Pay connect to card networks through the network tokenization services run by Visa (VTS) and Mastercard (MDES). When you add a card to a wallet, the wallet sends the card number to the issuing bank, which authorizes the addition and then calls the appropriate network's tokenization service to mint a device-specific token, called a Device Account Number (DAN) in Apple's terminology. That token is provisioned to your phone (to the Secure Element on iPhone, or to Google's cloud-backed HCE store on Android) and stored alongside a cryptographic key the device uses to sign each transaction.

At checkout, the wallet transmits the token plus a one-time cryptogram over NFC. The merchant's acquirer routes the token through Visa or Mastercard exactly like any card transaction. The network recognizes the token as a wallet token, validates the cryptogram, and translates the token back to your real card number (the PAN) before passing it to the issuing bank for authorization. The issuing bank approves or declines, the network relays the response, and the terminal confirms the sale. From the bank's perspective, the wallet is a secure routing layer that wraps the existing card network rather than replacing it.

How do contactless wallet payments work over NFC with Apple Pay and Google Pay?

Contactless wallet payments use Near Field Communication, a short-range radio standard operating at 13.56 megahertz over roughly a four-centimeter range. When the phone is held to the terminal, the terminal energizes an NFC field that wakes the wallet, the wallet emulates an EMV contactless card, and the two devices exchange data over the same protocol (ISO 14443) that a physical contactless chip card would use. The terminal does not know, and does not need to know, whether it is talking to a piece of plastic or a phone.

The data exchanged is not the card number. The wallet sends the network token (the device-specific stand-in for your real card) along with a dynamic cryptogram generated by the Secure Element or the HCE container using a key the wallet never reveals. The cryptogram is unique to this specific transaction; even a perfect intercept of the NFC traffic gives an attacker nothing reusable. The phone also authorizes the transaction biometrically (Face ID, Touch ID, fingerprint, or PIN) before transmitting, which is why the wallet does not need a separate signature or chip-and-PIN step at the terminal.

How do mobile wallet payments work at checkout with NFC and Apple Pay or Google Pay?

At checkout, the wallet payment flow runs in under a second across four parties. First, the merchant's terminal signals that it is ready to accept a contactless transaction and broadcasts the EMV contactless polling sequence. Second, the buyer unlocks the wallet and holds the phone to the terminal; the phone wakes its NFC controller, authenticates the buyer biometrically, and selects the appropriate payment application (Visa, Mastercard, Amex). Third, the phone transmits the network token, the dynamic cryptogram, and the transaction details (amount, currency, merchant identifier) to the terminal over NFC. Fourth, the terminal forwards the encrypted payload through the acquirer to the card network, which detokenizes and routes to the issuing bank for authorization.

The terminal shows the approval or decline within roughly half a second of the tap. The merchant's point-of-sale system records the transaction, and the buyer's phone displays a confirmation with the merchant name and amount. The full flow is settled the same way as a contactless chip card transaction, on the same nightly settlement run, with the same interchange. The only step that did not exist for the chip card is the tokenization layer at provisioning, which has already happened before checkout.

What is the difference between Apple Pay, Google Pay, Samsung Pay, and Tap to Pay on iPhone?

Apple Pay, Google Pay, and Samsung Pay are wallets the buyer uses to pay; Tap to Pay on iPhone is a software acceptance product that lets a merchant turn an iPhone into a payment terminal. Apple Pay stores its tokens and signing keys inside a dedicated hardware Secure Element on the iPhone and Apple Watch, and Apple historically restricted NFC access to its own wallet (a restriction that the EU's Digital Markets Act forced Apple to open to third parties in 2024). Google Pay relies on Host Card Emulation, which stores tokens in Google's cloud and presents them through the Android NFC stack, an architecture that is cheaper to scale across the Android device base but more dependent on connectivity for some flows. Samsung Pay uses the Secure Element on Galaxy devices and historically supported magstripe-style transmission (MST) for older US terminals, which Samsung sunset in 2021.

Tap to Pay on iPhone is a different product entirely. Powered by Apple's PassKit framework and offered through processors like Stripe, Square, Adyen, and Shopify, it lets an iPhone (XS or later) read any contactless card or wallet at the point of sale, with the merchant phone playing the role of the terminal. The category is still NFC and EMV contactless; the difference is the role flip. For the buyer, all four products feel like a tap. For the operator behind the counter, the first three are payments arriving on the till, and the fourth is the till itself.

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.