NFC for Payments
How Tap-to-Pay Works Under the Hood
Technical explanation of NFC contactless payments including EMV, tokenization, and SE/HCE architectures. Learn how Apple Pay, Google Pay, and card networks process tap-to-pay transactions securely.
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 14443Standards & ProtocolsStandard for contactless smart cards at 13.56 MHz (Types A and B)Click to view →-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.
Pertanyaan yang Sering Diajukan
NFC payments use ISO 14443 Type A/B at the physical layer and the EMVCo contactless specification at the application layer. The payment terminal acts as an ISO 7816 reader, sending SELECT and cryptographic APDU commands to the phone's Secure Element or Host Card Emulation (HCE) stack. The card application (PPSE — Proximity Payment System Environment) selects the correct payment application (Visa, Mastercard), which generates a transaction-specific AC cryptogram that the terminal sends to the payment network for authorization.
Host Card Emulation (HCE), introduced in Android 4.4, allows an Android app to emulate an NFC smart card by handling ISO 7816 APDU commands directly in software, without a physical Secure Element. The Android OS routes incoming NFC APDUs to the registered HCE service based on the AID (Application Identifier). HCE is used by transit apps, loyalty cards, and some payment implementations — though most bank-issued wallets prefer hardware Secure Elements for PCI compliance.
The EMV cryptogram (Application Cryptogram, or AC) is a unique 8-byte value computed by the payment card's application using 3DES or AES with a key derived from the card's master secret, the transaction amount, currency, date, and a random number from the terminal. Because the terminal nonce and transaction data are different every time, the cryptogram cannot be reused — making replay attacks against EMV contactless transactions computationally infeasible.
EMVCo contactless specifications require the transaction to complete within a nominal coupling distance of up to 5 cm, though most certified terminals and cards operate reliably between 1–4 cm. The short range is an intentional security feature — it ensures the cardholder consciously presents their device or card to the terminal. Relay attacks that extend this range are addressed by transaction time limits and, in newer specifications, proximity-check protocols.
Our guides cover a range of experience levels. Getting Started guides are written for beginners with no prior NFC knowledge. Programming guides target developers integrating NFC into mobile apps or embedded systems. Security guides are for engineers designing secure NFC deployments for payments, access control, or authentication.
Most guides require only an NFC-enabled smartphone (iPhone 7+ or any modern Android device) and a few NFC tags (NTAG213 or NTAG215 recommended for beginners, available for under $1 each). Advanced guides may reference USB NFC readers like the ACR122U or Proxmark3 for development and testing.
Yes. Programming guides include code examples for Android (Kotlin/Java with the Android NFC API), iOS (Swift with Core NFC), and web-based tools (Web NFC API for Chrome on Android). All code samples are tested and include inline comments explaining each step.