EMV Contactless Payment Flow Visualizer

Understanding Contactless Payment Flow

The contactless transaction flow follows the EMVCo Contactless Communication Protocol specification. When a card enters the terminal's RF field, a sequence of protocol steps occurs before any payment application logic begins. The terminal first performs anti-collision and activation per ISO 14443-3, then selects the payment application via PPSE (Proximity Payment Systems Environment), and finally executes the EMV contactless kernel to process the transaction.

PPSE and Application Selection

The terminal sends a SELECT command targeting the PPSE AID (2PAY.SYS.DDF01). The card responds with an FCI (File Control Information) template containing a list of available payment applications and their priority indicators. The terminal selects the highest-priority application and retrieves the PDOL (Processing Data Object List), which specifies what terminal data the card needs to proceed.

GPO and Data Reading

The terminal sends GET PROCESSING OPTIONS (GPO) with the PDOL data. The card returns AIP (Application Interchange Profile) and AFL (Application File Locator). The AFL tells the terminal which records to read using READ RECORD commands. Each record contains EMV data objects like PAN, expiry date, CDOL1, CVM List, and Application Usage Control.

Cryptogram Generation

After reading all application data, the terminal sends GENERATE AC with CDOL1 data. The card responds with a cryptogram: ARQC (Authorization Request Cryptogram) for online transactions, TC (Transaction Certificate) for offline approval, or AAC (Application Authentication Cryptogram) for decline. The CID byte (9F27) indicates which cryptogram type was returned. For online transactions, the issuer validates the ARQC and returns ARPC, which the card verifies before issuing a final TC.

Contactless vs Contact Transaction Differences

While both use the same EMV application layer (SELECT, GPO, READ RECORD, GENERATE AC), the contactless path adds several protocol layers below it. The card first goes through ISO 14443-3 anti-collision (REQA/WUPA, ANTICOLLISION, SELECT) before activating ISO 14443-4 transport protocol (R-PDU/I-PDU framing). The terminal must handle protocol parameter negotiation (FSDI/CID/NAD) and may need to switch between T=CL block chaining modes. A key optimization in contactless EMV is that the PPSE response, AID selection, and GPO can sometimes be combined using the EMVCo Contactless Communication Protocol's "alternate command set" to reduce round trips — crucial for the sub-500ms transaction time target.

Visa payWave vs Mastercard PayPass vs Amex ExpressPay

Each payment scheme implements the EMV contactless kernel differently. Visa payWave uses a "Quick Chip" approach that streamlines GPO and allows data reading after cryptogram generation. Mastercard PayPass (now M/Chip) uses the M/Chip Advance kernel with unique handling of M-CHIP-based IAD (tag 9F10) format and a specific CDA signature. Amex ExpressPay uses the EMVCo common kernel but adds ExpressPay-specific CVM rules (like "no CVM required" for small amounts). All three expose the same high-level steps visible in the flow visualizer above, but the PDOL contents, IAD structure, and CVM processing differ significantly. When debugging a contactless transaction, check the AID in the PPSE response to determine which kernel is active.

Transaction Time Budget and Optimization

The EMVCo specification targets a total contactless transaction time under 400-500ms from field activation to card removal. Each APDU round trip consumes roughly 20-40ms, so the 6-step flow above typically takes 150-250ms. Terminal-side processing (risk management, CVM evaluation, issuer host communication) must fit within the remaining budget. To accelerate transactions, some kernels pre-select the AID without PPSE (known AID fast path), combine READ RECORD commands for multiple records, or skip CDA signature verification for small-amount transactions (relying on online ARQC verification instead). The AFL optimization flag (byte 4 of each AFL entry) tells the terminal which records contain static data that can be cached across transactions.

Debugging Contactless Failures

Common contactless transaction failures include: no PPSE response (card not in field, wrong protocol, low battery on mobile); no GPO response (wrong PDOL data format — check byte order and encoding); 6A82 on READ RECORD (AFL points to a record that doesn't exist — card may be misconfigured); declined by AAC (card risk management declined the transaction — check CVR in tag 9F52, ATC in 9F36, and terminal risk parameters). Use the APDU Debugger to decode each response, and the EMV TLV Parser to inspect the raw response data byte by byte.