How NFC Payments Work
Tapping your phone or card at a checkout terminal completes a cryptographically secure financial transaction in under 500 ms. The technology behind this is emv Contactless — a global standard developed by Europay, Mastercard, and Visa. This guide explains the full transaction flow, the role of tokenization, and how host-card-emulation enables payment on Android without dedicated secure hardware.
EMV Contactless Architecture
emv Contactless extends the chip-and-PIN standard to the NFC interface. The terminal and card execute a cryptographically bound transaction protocol — no static card number is transmitted in cleartext.
Key participants in an NFC payment:
| Actor | Role | Technology |
|---|---|---|
| Payment card / device | Stores credentials, signs transaction | secure-element or HCE |
| POS terminal | Initiates transaction, routes to acquirer | ISO 14443ISO 14443Standard for contactless smart cards at 13.56 MHz (Types A and B)View full →-4, EMV kernel |
| Acquirer | Processes merchant transactions | EMV network |
| Network (Visa/MC) | Routes, applies tokenization | Token service provider |
| Issuer | Approves or declines | Account validation |
Transaction Flow Step by Step
- Field detection: Terminal activates 13.56 MHz RF field. Phone or card enters card-emulation-mode.
- AID selection: Terminal sends a SELECT command for an Application Identifier (e.g.,
A0000000031010for Visa). The card responds with application metadata. - GPO (Get Processing Options): Terminal sends terminal data (date, country code, amount). Card responds with an Application Interchange Profile (AIP) and Application File Locator (AFL).
- Record read: Terminal reads EMV records (cardholder name, expiry, cryptogram data).
- Cryptogram generation: Card generates an Application Cryptogram (AC) — an ARQC for online authorization or a TC for offline approval — using a key derived from the master key stored in the secure-element.
- Online authorization: Terminal forwards the ARQC to the issuer via the network. Issuer validates the cryptogram and returns an ARPC.
- Completion: Terminal confirms transaction completion to the card.
The entire RF session (steps 1–7) completes in 300–500 ms. The online authorization adds 1–3 seconds of network latency.
Tokenization
In NFC payments, the Primary Account Number (PAN — the 16-digit card number) is replaced by a payment token. The token is a surrogate number that:
- Is valid only for the specific device and merchant category in which it was provisioned.
- Cannot be used for card-not-present (CNP) fraud even if intercepted.
- Expires automatically when the device is lost or the card is re-issued.
Token provisioning flow: Bank app → Network Token Service Provider (TSP) → issues token → token stored in SE or HCE key store. On each transaction, the token + dynamic cryptogram travels over the NFC link, not the real PAN.
HCE: Payment Without a Secure Element
host-card-emulation allows an Android app to emulate an ISO 14443-4 card entirely in software, routing NFC commands to a foreground application rather than a hardware SE. This removes the dependency on SIM carrier approval and enables any bank to offer NFC payment without hardware partnerships.
HCE security model:
| Mechanism | Purpose |
|---|---|
| Limited-use keys (LUKs) | Single-use cryptographic keys provisioned per transaction; a stolen key cannot be reused |
| Token + dynamic data | Even if the token is captured, the cryptogram proves possession of the valid key |
| Remote key provisioning | New LUKs fetched from issuer server when supply runs low |
| Device binding | Keys bound to device fingerprint; cannot be extracted and used on another device |
HCE-based payments are now PCI DSS compliant under the Software-based PIN on COTS (SPoC) and Contactless Payments on COTS (CPoC) standards.
For the underlying card emulation mechanics, see the NFC Compatibility Checker to verify HCE support on target Android versions. For the security comparison between HCE and hardware SE, see NFC Security Deep Dive.