Reference

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.

1 / 16
📱Card / PhonePICC · ISO 14443
🖥️POS TerminalPCD · EMV Kernel
🏦Issuer / NetworkISO 8583
1
RF Field ON
2
ATQA
3
SELECT PPSE
4
PPSE FCI Response
5
SELECT AID
6
Application FCI
7
GET PROCESSING OPTIONS
8
AIP + AFL
9
READ RECORD
10
Card Data
11
GENERATE AC (ARQC)
12
ARQC Cryptogram
13
ISO 8583 0100 Auth Req
14
ISO 8583 0110 Auth Resp
15
EXTERNAL AUTHENTICATE
16
TC — Approved ✓
RF & Anti-collision

RF Field ON

Terminal energises 13.56 MHz field; card powers via inductive coupling

REQA (0x26)
EMV contactless: ~300–500 ms end-to-end|Tap-to-phone (SoftPOS): ~500–800 ms (extra processing on COTS device)
1

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.

2

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.

3

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
4

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).

5

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.
6

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
7

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).

8

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.

9

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.

10

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.