Reference

Payment Certification Levels

A practical guide to EMVCo L1 / L2 / L3 terminal certifications, PCI DSS merchant compliance tiers, and the standards that govern every card-present transaction.

EMV Transaction Flow

From card activation to final cryptographic proof — numbered phases, the AC decision branches (TC / AAC / ARQC), the online authorization path, and key reference tables.

Card ↔ terminal · offline processing1 / 13
1
Card ActivationCard inserted or tapped. Terminal applies power & clock. Card returns ATR (contact) or ATQA via 13.56 MHz RF (contactless).
2
Application SelectionTerminal reads PSE / PPSE, finds available AIDs with priorities. Selects highest-priority match. Card returns FCI.
3
Initiate App (GPO)Terminal sends PDOL data: amount, date, currency, terminal caps. Card returns AIP (82) + AFL (94).
4
Read Application DataTerminal reads all files per AFL. Card returns PAN, expiry, CVM list (8E), CDOL, issuer public key cert.
5
Offline Auth + CVMSDA / DDA / CDA signature verification. Cardholder verification: Offline PIN, Online PIN, or Signature.
6
Terminal Risk MgmtFloor limit check, velocity counter, random online selection, exception file lookup. Builds TVR (95).
7
First GENERATE ACTerminal sends CDOL1 data. Card generates Application Cryptogram and decides: TC / AAC / ARQC.
ABC
A
TC
Transaction Certificate

Offline approval. Amount is below floor limit, all checks passed, and the card decides to approve without contacting the issuer.

Transaction Completed Offline
B
AAC
Application Authentication Cryptogram

Offline decline. ODA failed, card or terminal TAC-Denial bit triggered, or card refused the transaction based on its own rules.

Transaction Declined
C
ARQC
Authorization Request Cryptogram

Online authorization required. Card sends ARQC — issuer must validate and respond before the transaction can complete.

8
Authorization Request to IssuerTerminal sends ISO 8583 0100 — DE55 carries ARQC, ATC, IAD, TVR, AIP · DE2: PAN · DE4: amount
9
Acquirer Routes to IssuerAcquirer forwards 0100 via card network (Visa / MC) to the card-issuing bank host system
10
Issuer Validates & DecidesIssuer derives session key, verifies ARQC cryptogram, checks account status & fraud rules → approve or decline
11
0110 Response ReturnedDE39: response code (00 = approved) · DE55: ARPC + optional issuer scripts (tags 71 / 72)
12
Second GENERATE AC (contact) / Finalize (NFC)Contact: terminal forwards ARPC to card; card verifies issuer response, applies scripts, generates final TC or AAC.NFC: card is typically removed — terminal finalizes using issuer response code and kernel rules alone.
TC — Approved
AAC — Declined online

Application Cryptogram Types — AC Reference

AC is the umbrella term. Tag 9F27 (CID) indicates the type; 9F26 carries the 8-byte cryptogram value in all cases.

9F27 = 80
ARQC
Authorization Request Cryptogram

Card requests online authorization. Issuer must validate and return ARPC + decision. Generated when the card deems online auth necessary (amount over floor limit, random selection, ODA inconclusive).

9F27 = 40
TC
Transaction Certificate

Offline approval or final online approval. Cryptographic proof of the completed transaction — stored in clearing batch. Also the expected output of the second GENERATE AC when the issuer approves.

9F27 = 00
AAC
Application Authentication Cryptogram

Offline decline or online decline. Transaction rejected. Generated when the card refuses offline, when ODA fails with TAC-Denial, or after second GAC when the issuer returned a decline.

Why a Second GENERATE AC?

🔐
First GAC → ARQC"Here is my cryptographic authorization request" — card sends ARQC to issuer via terminal
🏛
Issuer Response (ARPC)"Approved / Declined" + ARPC cryptogram + optional scripts and new IAD in DE55
Second GAC → TCCard verifies ARPC is genuine, applies issuer scripts, updates ATC/risk state → final TC (the card's signed receipt)
Why not stop after issuer approval?
  • ARPC authentication — Card must cryptographically verify the issuer response is genuine and not a relay or replay attack
  • Card agreement — The card independently decides to accept or reject the outcome based on its own rules and context
  • Issuer scripts — Scripts in tags 71 / 72 (PIN change, counter reset, card unblock) can only be applied to an inserted card via the second GAC exchange
  • Final cryptographic proof — TC is the card's signed confirmation; used as evidence in dispute resolution
  • NFC exception — In contactless transactions the card is typically removed before the issuer response arrives, so the second GAC is usually skipped; the terminal finalizes using contactless kernel rules

Key EMV Data Elements in This Flow

Tag
Name
Description
9F26
Application Cryptogram (AC)
8-byte cryptogram value — ARQC, TC, or AAC; type determined by 9F27
9F27
Cryptogram Information Data
Indicates AC type: 80 = ARQC · 40 = TC · 00 = AAC
9F36
Application Transaction Counter
Increments each transaction; prevents replay attacks
9F10
Issuer Application Data (IAD)
Card's risk data and key derivation index — used by issuer to validate ARQC
9F37
Unpredictable Number
4-byte terminal random value included in CDOL1; prevents pre-play attacks
82
Application Interchange Profile
Bitmap of card capabilities returned in GPO: SDA, DDA, CVM, CDA support
95
Terminal Verification Results
5-byte bitmap set by terminal during each check; fed into CDOL1
9F66
Terminal Transaction Qualifiers
Contactless only — negotiates online/offline/CVM capabilities with card via TTQ→CTQ exchange
NFC / Contactless key point: In a typical tap-to-pay transaction the card or phone is removed from the RF field immediately after the first GENERATE AC (step 7). The terminal cannot send the issuer response back to the card, so no second GENERATE AC is performed. The terminal finalizes using the issuer response code and contactless kernel rules alone.

Related Tools

Use these tools to work with the cryptographic primitives that underpin terminal and card security.