NFC in Payments
Near Field Communication (NFC) operates at 13.56 MHz over distances up to ~4 cm. In payments, it enables tap-to-pay at POS terminals, transit fare gates, and mobile wallets. The technology is governed by ISO/IEC 14443, ISO/IEC 18092, and NFC Forum specifications — with EMVCo layering the payment protocol on top.
Contactless EMV Transaction Flow
A full contactless transaction from tap detection to authorisation response. Each step maps to specific EMV data elements and protocol commands defined in EMVCo Contactless Books A through D.
RF Field ON
Terminal energises 13.56 MHz field; card powers via inductive coupling
REQA (0x26)Card Tap Detected (< 4 cm)
Terminal RF field activates continuously. When a card or device enters the field, the passive card draws power via inductive coupling and responds with an ATQA (Answer To Request, Type A) or ATQB signal. If multiple cards are present, the anti-collision algorithm resolves them to a single target before proceeding.
Application Selection (Entry Point)
Terminal reads the Payment System Environment (PPSE) — tag 9F60 — to retrieve the list of AIDs (Application Identifiers) supported by the card. Terminal matches this list against its own supported AID list and selects the highest-priority matching AID. This is the Entry Point defined in EMVCo Contactless Book B.
GPO — Get Processing Options
Terminal sends a GPO command containing terminal data: date, time, amount, TVR (Terminal Verification Results) initialised to zeros. The card responds with:
82— AIP (Application Interchange Profile): capabilities the card supports (SDA/DDA/CDA, CVM types)94— AFL (Application File Locator): which files and records to read next
Read Records
Terminal issues READ RECORD commands for each file and record specified in the AFL. Data retrieved includes: PAN (tag 5A), expiry date (5F24), cardholder name (5F20), CVM list (8E), CDOL1/CDOL2 (8C/8D), and issuer application data (9F10).
Offline Data Authentication
Terminal validates the card's authenticity using one of three methods, depending on what the card's AIP declares:
- SDA (Static Data Authentication): Terminal verifies a static issuer signature over fixed card data. Vulnerable to replay — cannot prove liveness.
- DDA (Dynamic Data Authentication): Card generates a unique signature per transaction using its private key. Proves liveness but requires an extra round-trip.
- CDA (Combined DDA + AC generation): Most secure. Card signs both the dynamic authentication data and the AC in one step. Eliminates a round trip and prevents wedge attacks.
CVM Processing
Terminal evaluates the card's CVM list against terminal capabilities and the transaction amount:
- Above contactless CVM limit: may require online PIN or decline contactless entirely
- Below CVM limit: Consumer Device CVM (CDCVM) on phones via biometrics, or No CVM for low-value transactions
- Tap-on-mobile (SoftPOS): CDCVM replaces PIN — device biometrics (Face ID, fingerprint) satisfy the CVM requirement
Terminal Risk Management
Terminal performs its own risk checks before generating a cryptogram. Evaluates: velocity counters (how many consecutive offline transactions), floor limit comparison (is the amount above the configured floor limit?), and random online selection triggers (some fraction of sub-floor-limit transactions are forced online for monitoring purposes).
Terminal Action Analysis — ARQC / TC / AAC
Terminal builds the GENERATE AC command using CDOL1 data (amount, terminal data, TVR) and instructs the card which cryptogram to generate:
- ARQC (Application Request Cryptogram): go online — request authorisation from issuer
- TC (Transaction Certificate): approve offline — issuer risk is acceptable
- AAC (Application Authentication Cryptogram): decline offline
The ARQC is computed using an EMV session key derived from the card's master key via UDK derivation (ATC-based). The session key is unique to this transaction.
Online Authorization (ISO 8583)
Terminal sends an ISO 8583 0100 authorization request to the acquirer. DE55 carries the full EMV data block including the ARQC, AIP, TVR, ATC, unpredictable number, and transaction data. The issuer validates the ARQC against its own session key derivation, then returns a 0110 response with ARPC in DE55 and an authorisation code.
Issuer Script / 2nd TAP — Transaction Complete
If the card supports it, the issuer can send issuer scripts in the authorisation response (tag 71 / 72) — for example to reset PIN try counters or update application counters. For CDA transactions, the card validates the ARPC using its own key and returns a TC (Transaction Certificate) confirming the authorisation. Transaction is now complete and approved.
Related Tools
Use these tools to work with the cryptographic primitives and data formats used in NFC / EMV contactless transactions.