What is the difference between GPO and GENERATE AC?

GPO (GET PROCESSING OPTIONS) is sent first by the terminal to ask the card what data it needs. The card responds with the Application Interchange Profile and Application File Locator. GENERATE AC is sent later to request the cryptogram (ARQC for online authorization, TC for offline approval, or AAC for decline). GPO is the 'what do you need' step; GENERATE AC is the 'prove it' step.

What is an ARQC cryptogram?

ARQC (Authorization Request Cryptogram) is the cryptogram generated by the card during an online EMV transaction. It is computed from the transaction amount, terminal data, and a secret key on the card. The issuer verifies the ARQC to confirm the transaction is genuine before approving it.

Can a contactless EMV transaction complete offline?

Yes. If the card generates a TC (Transaction Certificate) instead of an ARQC, the transaction is approved offline by the terminal's risk management. This is common for small-amount contactless payments where the terminal has a floor limit that allows offline approval.

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

GPO vs GENERATE AC — The Two APDUs That Run Contactless Payments

Every EMV contactless transaction — whether you tap a Visa, Mastercard, or Amex — involves two critical APDU commands: GET PROCESSING OPTIONS (GPO) and GENERATE AC. GPO is the terminal asking the card "what do you need from me?" GENERATE AC is the terminal saying "prove this transaction is genuine." Together, they form the backbone of the EMV contactless protocol.

This guide compares these two commands in detail: their roles, APDU structure, data exchange, cryptogram types, and the decision logic that determines whether a transaction goes online or completes offline.

The EMV Contactless Transaction Flow

1. SELECT AID (e.g., A0000000041010 for Visa Debit)
   → Card returns PDOL (Processing Options Data Object List)

2. GET PROCESSING OPTIONS (GPO)
   → Terminal sends PDOL data (amount, terminal country, etc.)
   ← Card returns AIP + AFL

3. READ RECORD (for each AFL entry)
   → Terminal reads card data records
   ← Card returns TLV data (PAN, expiry, CDOL1, CDOL2)

4. DATA AUTHENTICATION (SDA/DDA/CDA)
   → Terminal verifies card's static/dynamic data

5. GENERATE AC (First AC)
   → Terminal sends CDOL1 data + requests cryptogram
   ← Card returns ARQC (online) or TC (offline) or AAC (decline)

6. [If online] EXTERNAL AUTHENTICATE
   → Terminal sends issuer's ARPC response
   ← Card verifies issuer authorization

7. [If online] GENERATE AC (Second AC)
   → Terminal requests final cryptogram
   ← Card returns TC (approved) or AAC (declined)

GPO: GET PROCESSING OPTIONS

GPO is the terminal's way of asking the card what data it requires to process the transaction. The card's response tells the terminal which application data records to read and what capabilities the card supports.

GPO Command APDU

CLA: 80
INS: A8
P1:  00
P2:  00
Lc:  [length of PDOL data]
Data: [PDOL data — amount, terminal country code, etc.]
Le:  00

Example (Visa payWave):
80 A8 00 00 23 83 21
  00 00 00 00 10 00     // Amount = $1.00
  00 00                // Terminal country code
  00 00 00             // Terminal type, etc.
  00                   // Transaction currency code

GPO Response

Response TLV:
  80 [length] [AIP (2 bytes)] [AFL (variable)]

AIP (Application Interchange Profile):
  Bit 8-7: SDA support
  Bit 6: DDA support
  Bit 5: CDA support
  Bit 4: Online PIN
  Bit 3: Offline PIN (plaintext)
  Bit 2: Offline PIN (enciphered)
  Bit 1: No CDA

AFL (Application File Locator):
  Points to the card's data records to be read
  Format: [SFI] [Record start] [Record end] [Offline auth]

GPO is the negotiation step. The card says "I support these features (AIP) and here's where my data lives (AFL). The terminal then reads the records pointed to by the AFL to get the PAN, expiry date, certificates, and CDOLs (Cardholder Verification Data Object Lists).

GENERATE AC: The Cryptogram Request

After reading all card data and performing risk checks, the terminal sends GENERATE AC to request a cryptogram. This is the security-critical step — the card signs the transaction data with its secret key.

GENERATE AC Command APDU

CLA: 80
INS: AE
P1:  [cryptogram type requested]
     00 = AAC (decline)
     40 = TC (offline approval)
     80 = ARQC (online authorization)
P2:  00
Lc:  [length of CDOL1 data]
Data: [CDOL1 data — amount, ATC, unpredictable number, etc.]
Le:  00

The card computes:
  AC = MAC(K_card, [transaction data] || [ATC] || [P1])
  using the card's unique key K_card (derived from master key)

Cryptogram Types

Cryptogram	P1 Value	Meaning	Action
ARQC	80	Authorization Request Cryptogram	Send to issuer for online approval
TC	40	Transaction Certificate	Offline approval by terminal
AAC	00	Application Authentication Cryptogram	Decline (terminal or card rejected)
AAR	60	Authorization Request Response	Card requests issuer referral

Who decides: online or offline? The card makes the decision based on the terminal's risk management data and the card's own risk parameters. If the amount is under the terminal's floor limit and the card's risk counters are normal, the card may generate a TC (offline approval). If the amount exceeds the floor limit or the card detects anomalies, it generates an ARQC (requesting online authorization from the issuer).

GPO vs GENERATE AC Comparison

Dimension	GPO	GENERATE AC
Role	Negotiation: "what do you need?"	Cryptographic proof: "prove it"
INS byte	A8	AE
Input	PDOL data (terminal capabilities)	CDOL data (transaction details)
Output	AIP + AFL (card capabilities + data locations)	Cryptogram (ARQC/TC/AAC) + card data
Cryptographic Operation	None (data exchange only)	AES/3DES MAC with card's secret key
When in Flow	Step 2 (before reading records)	Step 5 (after risk assessment)
Can Complete Offline?	N/A (always executed)	Yes (if card returns TC)
Security Impact	Low (informational)	Critical (transaction integrity proof)

Visa payWave vs Mastercard Contactless Flow Differences

The two major card networks have slightly different contactless implementations:

Aspect	Visa payWave (qVSDC)	Mastercard (PayPass/MCHIP)
GPO	Standard GPO with PDOL	GPO with PDOL (same)
Data Authentication	DDA or CDA	SDA, DDA, or CDA
First GENERATE AC	Always ARQC (online)	ARQC or TC (card decides)
Offline Approval	Limited (fCSDA)	Common (TC for small amounts)
Risk Management	Terminal + card risk	Terminal + card risk

ACR122U NFC Reader — Send GPO and GENERATE AC APDUs to real payment cards for EMV development and testing. PC/SC compatible. — Check Price on Amazon

Why Understanding GPO and GENERATE AC Matters

EMV terminal development: If you are building a payment terminal, you must implement the correct GPO and GENERATE AC APDU sequences for each card network.
Card personalization: The PDOL and CDOL1/CDOL2 must be correctly provisioned during card personalization. Errors here cause transaction failures.
Security auditing: Inspecting the cryptogram (tag 9F26) and the CDOL data reveals whether the transaction was properly authenticated.
Interoperability testing: Different card manufacturers may implement GPO and GENERATE AC slightly differently. Understanding the protocol helps debug cross-vendor issues.

Related Comparisons

TLV/BER-TLV Parser Comparison — parsing the data exchanged in GPO and GENERATE AC
EMV vs Magnetic Stripe — why GPO/GENERATE AC replaced the magnetic stripe read
ATR Parser Comparison — identifying the card before sending GPO
Contactless Card vs Mobile Wallet — how the EMV flow is used by cards vs phones

Summary

GPO negotiates; GENERATE AC proves. GPO is the informational handshake where the card and terminal exchange capabilities and data locations. GENERATE AC is the cryptographic commitment where the card signs the transaction with its secret key, producing the cryptogram that the issuer verifies. Together, they form the core of every EMV contactless payment.

Want to simulate an EMV contactless flow? Try our Contactless Activation Flow Simulator or the EMV Cryptogram Decoder.

← TLV/BER-TLV Parser Comparison GP APDU vs SCP03 →