EMV Application Cryptogram Visualizer

Step-by-step visualization of EMV Application Cryptogram generation. Input CDOL data, UDK (Unique Derived Key), and ATC to compute ARQC, ARPC, TC, or AAC. Essential for EMV kernel developers, payment terminal testing, and card personalization validation. All crypto via Web Crypto API.

Input

Computation Steps

Enter parameters and click Compute

How to Use

Enter the card's UDK (Unique Derived Key — the session key from issuer master key diversification), ATC, and the CDOL data from the EMV transaction. The tool shows each step of the EMV cryptogram computation as defined in EMV Book 2, Section 8.1.

ARQC = MAC(UDK, CDOL_data || ATC || Cryptogram_Type)

Related Tools

Key Diversification Calculator — Derive UDK from master key | EMV TLV Parser — Parse CDOL data | Crypto Checksum Verifier — MAC/CMAC/Retail-MAC

EMV Cryptogram Types

EMV cryptograms are 8-byte values generated by the card using the Application Cryptogram key derived from the issuer master key and the card PAN/PSN. The cryptogram proves the card's authenticity to the issuer and communicates the card's transaction decision.

Cryptogram Information Data (CID)

The CID byte (tag 9F27) indicates the cryptogram type: 0x80 = ARQC (Authorization Request Cryptogram) means the card requests online authorization. 0x40 = TC (Transaction Certificate) means the card approves the transaction offline. 0x00 = AAC (Application Authentication Cryptogram) means the card declines the transaction. 0x80 with specific bits can also indicate Combined DDA/Application Cryptogram (CDA) generation.

Cryptogram Computation

The ARQC is computed as: ARQC = 3DES(MK_AC, <8 bytes of 0000...0000 or 00000001> || PAN || PSN || ATC || || transaction data hash ||). The inputs include the Application Transaction Counter (9F36), unpredictable number (9F37), and selected CDOL1 data objects. The issuer validates the ARQC by recomputing it with the same master key. If valid, the issuer returns an ARPC (Authorization Response Cryptogram) computed similarly, which the card verifies before allowing the transaction to complete. Use our Key Diversification Tool to derive EMV keys from the issuer master key.

Session Key Derivation in EMV

The card does not use the master key directly for cryptogram computation. Instead, it derives a unique session key (SK_AC) for each transaction using the formula: SK_AC = 3DES(MK_AC, 0000...0000 || PAN || PSN || ATC). The PAN and PAN Sequence Number (PSN) are padded to 16 bytes and encrypted under the master AC key. This per-transaction derivation means that even if one session key is compromised, only that single transaction is affected. The same derivation is used for the ARQC key (for cryptogram generation) and the ARPC key (for issuer response verification), with the master keys MK_AC and MK_ARPC being different subkeys derived from the issuer master key during personalization.

Common Cryptogram Input Data Elements

The data block input to the cryptogram MAC computation includes concatenated CDOL1 data objects. The most common elements are: 9F02 Amount Authorized (6-digit numeric, zero-padded), 9F03 Amount Other (cashback amount, usually zeros), 9F1A Terminal Country Code (e.g., 0840 for USA), 95 TVR (5-byte Terminal Verification Results), 5F2A Transaction Currency Code (ISO 4217, e.g., 0840 for USD), 9A Transaction Date (YYMMDD), 9C Transaction Type (00=purchase, 01=cash, 20=refund), 9F37 Unpredictable Number (4-byte terminal random), 9F35 Terminal Type, and 9F45 Data Authentication Code. The order and presence of these elements is defined by the card's CDOL1, which the terminal reads during the READ RECORD step.

Visa vs Mastercard Cryptogram Differences

Visa uses a CVN (Cryptogram Version Number) system embedded in tag 9F10 (Issuer Application Data) that determines the exact session key derivation and MAC computation method. CVN 10 (older Visa) uses a simple 3DES-CBC MAC with the session key. CVN 17 (Visa Quantum) uses a modified derivation with additional padding. CVN 18 (Visa dCVV) uses a different data block layout. Mastercard uses a different IAD structure where the CVC3 (Card Verification Code 3) is computed using a counter-based approach, and the ACC (Application Cryptogram Counter) in the IAD plays a role similar to but different from the ATC. When debugging a cryptogram mismatch between your tool and a real card, first identify the payment scheme and CVN version from tag 9F10, then consult the scheme's kernel specification for the exact algorithm.

ARPC Verification Flow

After the issuer receives and validates the ARQC, it generates the ARPC using the ARPC key (derived from the same master key). The ARPC is typically computed as: ARPC = 3DES(SK_ARPC, ARQC || Authorization Response Code) (8-byte ARQC concatenated with the 2-byte auth response code, e.g., "00" for approval or "05" for decline). The card receives the ARPC via the EXTERNAL AUTHENTICATE command (or as part of a second GENERATE AC for Visa's Second AC). The card verifies the ARPC and, if valid and the response code indicates approval, issues a TC (Transaction Certificate) to finalize the transaction. If the ARPC is invalid or the response indicates decline, the card issues an AAC. This two-phase flow (ARQC then TC/AAC) ensures both the card and issuer have mutually authenticated.

Verify Cryptograms Against a Test Card

The ARQC/ARPC math becomes real when you compute it for a card on your bench.

ACR1252U Smart Card Reader ACR1252U Smart Card Reader (~$65) — Contact + contactless reader for EMV transaction testing with test cards.
Check Price on Amazon

Disclosure: As an Amazon Associate, CardWise earns from qualifying purchases at no additional cost to you. This does not affect our recommendations.