EMV Transaction Flow Explained — How Chip Card Payments Work

Every time you insert or tap a chip card at a payment terminal, a complex sequence of cryptographic operations happens in under a second. This tutorial explains the complete EMV transaction flow step by step — from application selection to final authorization — with real APDU traces.

Interactive tools: EMV Contactless Flow Visualizer — see every APDU command and response. EMV Cryptogram Visualizer — step-by-step ARQC generation.

The 8 Steps of an EMV Transaction

Step	Card Command	What Happens
1	—	Application Selection (SELECT AID)
2	GET PROCESSING OPTIONS	Card returns AIP + AFL (what it supports)
3	READ RECORD	Terminal reads card data (PAN, expiry, AUC)
4	—	Cardholder Verification (PIN / signature / CDCVM)
5	GENERATE AC (ARQC)	Card generates online authorization cryptogram
6	—	Online authorization (issuer approves/declines)
7	GENERATE AC (TC/AAC)	Card generates final transaction cryptogram
8	—	Issuer scripts processing (PIN unblock, app update)

Step 1: Application Selection

The terminal discovers what applications the card supports. For contact cards, the terminal sends SELECT PSE (Payment System Environment, AID=1PAY.SYS.DDF01). For contactless, it sends SELECT PPSE (2PAY.SYS.DDF01).

// Contact: SELECT PSE
C-APDU: 00 A4 04 00 07 2PAY.SYS.DDF01 00
R-APDU: 6F.. [PSE FCI with list of supported AIDs] 9000

// Then SELECT the chosen application (e.g., Visa AID)
C-APDU: 00 A4 04 00 07 A0000000031010 00
R-APDU: 6F.. [Application FCI] 9000

The card returns an FCI (File Control Information) that includes the AID, PDOL (Processing Options Data Object List), and other metadata.

Step 2: GET PROCESSING OPTIONS (GPO)

After selecting the application, the terminal sends GET PROCESSING OPTIONS with the PDOL data (amount, currency, terminal type, etc.). The card responds with the AIP (Application Interchange Profile) and AFL (Application File Locator).

// GPO — terminal provides PDOL data
C-APDU: 80 A8 00 00 02 83 00 00
R-APDU: 80 [AIP] [AFL] 9000

// AIP tells the terminal: SDA/DDA/CDA support, CVM capabilities
// AFL tells the terminal: which files and records to READ

The AIP is critical — it tells the terminal whether the card supports SDA (Static Data Authentication), DDA (Dynamic), or CDA (Combined). SDA is considered weak and is being phased out.

Step 3: READ RECORD

The terminal reads the application data specified by the AFL. Each READ RECORD returns EMV tags like:

Tag 5A — PAN (Primary Account Number)
Tag 5F24 — Expiry date
Tag 8C/8D — CDOL1/CDOL2 (data needed for GENERATE AC)
Tag 9F07 — Application Usage Control
Tag 9F0D/9F0E/9F0F — Terminal action codes (issuer-defined risk thresholds)

// Read SFI 04, record 01
C-APDU: 00 B2 01 04 00
R-APDU: 70 [BER-TLV data: 5A, 5F24, 8C, 8D, ...] 9000

Step 4: Cardholder Verification (CVM)

EMV supports multiple verification methods, defined by the card’s CVM List (Tag 8E):

Online PIN — PIN sent to issuer for verification
Offline PIN — card verifies PIN locally (plaintext or enciphered)
Signature — paper signature on receipt
CDCVM — Consumer Device CVM (Apple Pay, Google Pay biometric)
No CVM — for small amounts (contactless under CVM limit)

Decode any CVM list with our EMV CVM List Decoder.

Step 5: GENERATE AC (First — ARQC)

The terminal sends GENERATE AC with the CDOL1 data. The card computes an ARQC (Authorization Request Cryptogram) using the transaction data and its secret key.

// GENERATE AC — ARQC request (AAC=0x80, TC=0x40, ARQC=0x00)
C-APDU: 80 AE 00 00 [CDOL1 data length] [CDOL1 data] 00
R-APDU: 77 [CID=80] [ATC] [ARQC] [IAC] 9000

The ARQC proves to the issuer that the card is genuine and was present for this specific transaction. It’s generated using 3DES-CBC or AES (depending on the card’s algorithm) with a session key derived from the card’s master key.

Step 6: Online Authorization

The terminal sends the ARQC to the issuer via the payment network. The issuer:

Verifies the ARQC using its copy of the card’s key
Checks account balance, fraud rules, velocity limits
Generates an ARPC (Authorization Response Cryptogram)
Returns approval/decline + optional issuer scripts

Step 7: GENERATE AC (Second — TC or AAC)

After online approval, the terminal sends a second GENERATE AC with CDOL2 data. The card validates the ARPC and generates either:

TC (Transaction Certificate) — transaction approved, stored on card
AAC (Application Authentication Cryptogram) — transaction declined

// GENERATE AC — TC (approval)
C-APDU: 80 AE 40 00 [CDOL2 data length] [CDOL2 data] 00
R-APDU: 77 [CID=40] [ATC] [TC] [IAC] 9000

Step 8: Issuer Scripts Processing

The issuer may send scripts to update the card after the transaction:

PIN Try Counter reset — after successful PIN change
Application block/unblock — emergency card management
Data update — change risk parameters, add new AIDs

Contactless vs Contact: Key Differences

Feature	Contact (Insert)	Contactless (Tap)
Speed	5–15 seconds	0.5–3 seconds
CVM	PIN required above limit	No CVM for small amounts
Flow	Full GPO + READ RECORD	Combined GPO (READ RECORD included)
Online	Always for large amounts	Often offline for小额
Standard	EMV Books 1-4	EMVCo Contactless (A/B/C)

Try our EMV Contactless Payment Flow Visualizer to see the complete APDU trace for a tap-to-pay transaction.

Frequently Asked Questions

Why do some transactions go offline while others go online?

The card and terminal decide based on risk parameters: transaction amount, velocity, terminal limits, and random selection. Small contactless payments typically stay offline. Large amounts, first-time cards, or suspicious patterns trigger online authorization. The issuer can also force online via the Action Codes.

What is the difference between ARQC, TC, and AAC?

ARQC = Authorization Request Cryptogram (sent to issuer for online auth). TC = Transaction Certificate (final approval, stored on card). AAC = Application Authentication Cryptogram (decline). The card generates ARQC first, then either TC (approved) or AAC (declined) after the issuer responds.

Can EMV transactions be cloned?

EMV chip transactions generate dynamic cryptograms for each transaction — they cannot be replayed. However, magnetic stripe fallback transactions (when the chip fails) are vulnerable. This is why skimmers still target magstripe data. Contactless-only cards without a stripe eliminate this attack vector.

← EMV Cryptogram Guide EMV Card Decoding →