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

EMV ARQC & ARPC — How Payment Card Cryptograms Work

Last updated: August 2026

When you tap or insert a chip card at a terminal, two cryptograms are the heart of the security exchange: the ARQC (Authorization Request Cryptogram) generated by the card, and the ARPC (Authorization Response Cryptogram) generated by the issuer. This guide explains exactly how they are computed, what they prove, and why they matter.

What Is ARQC?

ARQC stands for Authorization Request Cryptogram. It is an 8-byte value computed by the EMV chip card during an online transaction. The ARQC proves to the issuer that:

• A genuine EMV chip was present (not a mag-stripe clone)
• The transaction data has not been tampered with
• The card's internal counter has advanced (replay protection)

Without ARQC, the issuer has no cryptographic assurance that the transaction originated from a real chip.

What Is ARPC?

ARPC stands for Authorization Response Cryptogram. It is an 8-byte value computed by the issuing bank's host security module (HSM) and returned to the card. The ARPC proves to the card that:

• The real issuer authorized the transaction (not a man-in-the-middle)
• The response corresponds to this specific ARQC (not a replayed authorization)

The card verifies the ARPC before accepting the issuer's response. If the ARPC does not match, the card rejects the transaction.

The Online Authorization Flow

Terminal                   Card                    Issuer
   |                        |                        |
   |-- Generate AC (ARQC) ->|                        |
   |                        |                        |
   |<--- ARQC + TVR + etc --|                        |
   |                        |                        |
   |--- Authorization Request -------------------->  |
   |    (ARQC + transaction data)                     |
   |                        |                        |
   |                        |     Validate ARQC      |
   |                        |     Compute ARPC        |
   |                        |                        |
   |<--- Authorization Response ---------------------|
   |    (ARPC + response code)                       |
   |                        |                        |
   |-- External Authenticate (ARPC) ->|              |
   |                        |                        |
   |                        |--- Verify ARPC ---->  |
   |                        |    Card accepts/rejects |
   |<--- Transaction result --|                     |

How ARQC Is Computed

The ARQC is computed using the Application Cryptogram function defined in EMV Book 2. The algorithm depends on the card's cryptographic type:

For SDA (Static Data Authentication) Cards

SDA cards do not generate true ARQC. They use a SDA cryptogram (sometimes called AAC — Application Authentication Cryptogram) that is pre-computed and stored on the card. SDA provides no dynamic authentication — the terminal can verify that the card data was signed by the issuer at personalization time, but cannot detect cloning.

For DDA (Dynamic Data Authentication) Cards

DDA cards generate the ARQC using the card's unique ICC Private Key. The computation involves:

1. Assemble the transaction data — a concatenation of specific EMV tags
2. Generate or increment the Application Transaction Counter (ATC) — a 2-byte counter that increments with each transaction
3. Generate an unpredictable number — 4-byte random value from the terminal
4. Compute the cryptogram over the transaction data using the card's secret key

The key inputs to ARQC computation:

The Cryptographic Algorithm

For most EMV implementations, ARQC is computed using DES-based cryptography (specifically, the EMV GENERATE AC command uses a variant of CBC-MAC with the card's AC session key):

// Simplified ARQC computation
session_key = derive_key(MDK_AC, PAN + PSN)
ARQC = MAC_des_CBC(session_key, transaction_data_block)

Where MDK_AC is the card's Application Cryptogram Master Key, and the session key is derived using the PAN (card number) and PSN (PAN sequence number).

Some modern implementations use AES instead of DES for the MAC computation, but the logical structure remains the same.

How ARPC Is Computed

The issuer receives the ARQC and transaction data, then computes ARPC as follows:

ARPC = MAC(session_key, ARQC || ARC || CSU)

Where:

• ARQC — the cryptogram received from the card
• ARC — Authorization Response Code (2 bytes, e.g., "00" for approved)
• CSU — Card Status Update (optional, 0-8 bytes)

The card verifies the ARPC by computing the same value locally using its stored session key. If the values match, the card knows the response genuinely came from the issuer.

Offline vs Online: When ARQC Is Used

Not all EMV transactions go online. The terminal decides based on risk management:

The GENERATE AC command tells the card which type of cryptogram to produce. The terminal's decision is based on the TVR (Terminal Verification Results) and the card's Issuer Application Data.

SDA vs DDA vs CDA — Security Comparison

CDA (Combined DDA/Application Cryptogram) generates the cryptogram and the dynamic authentication in one step, covering more transaction data. This is the current best practice for contact and contactless EMV.

Practical: Testing ARQC with APDUs

To trigger ARQC generation yourself, you need a smart card reader connected to your computer. The ACR122U is the standard choice for EMV development — it supports both contact (ISO 7816) and contactless (ISO 14443) cards, and works with pcscd on Linux, macOS, and Windows out of the box. Check Price on Amazon — If you prefer USB-C and faster transaction speeds, the ACR1252U is a newer alternative. Check Price on Amazon

With a reader and a test EMV card, you can trigger ARQC generation using the GENERATE AC command:

// GENERATE AC (ARQC requested)
// P1=0x80 (ARDA + CDOL1 data), P2=0x00
CLAINS  = 80 AE
P1      = 80    // ARQC requested (ARDA=1)
P2      = 00
Lc      = length of CDOL1 data
Data    = CDOL1 values (amount + date + TVR + UN + ...)
Le      = 00

// Expected response:
// SW1SW2 = 9000 (success)
// Data   = cryptogram info byte + ATC + ARQC (8 bytes) + ...

Use our APDU Command Builder to construct this command, and EMV Cryptogram Calculator to verify the results.

Common Pitfalls

• Missing unpredictable number: If the terminal always sends 0x00000000 as the UN, ARQC replay attacks become possible. Always generate a proper random UN.
• ATC not advancing: The card's ATC must increment for every transaction. If it stays at 0, the card may not be properly initialized.
• Confusing TC and ARQC: A TC is generated for offline-approved transactions. It is not verified by the issuer and cannot be used for online authorization.
• SDA cards with "ARQC": Some SDA cards return a value labeled ARQC, but it is not dynamically computed — it is derived from static data and offers no replay protection.

Key Takeaways

• ARQC proves the chip card is genuine and the transaction data is fresh
• ARPC proves the issuer authorized the specific transaction
• DDA and CDA cards generate true dynamic ARQC; SDA cards do not
• The ATC and unpredictable number are critical for replay protection
• Always test ARQC flows with real or simulated online authorization