Behind a Tap-to-Pay Transaction: A Deep Dive into EMV APDU Communication and Android HCE

Every time a customer taps a phone on a payment terminal, a sophisticated sequence of EMV commands, cryptographic operations, and security validations takes place within a few hundred milliseconds. While the experience appears simple to the user, the underlying payment flow involves NFC communication, Host Card Emulation (HCE), tokenization, cryptogram generation, issuer validation, and multiple EMV protocols working together.

In this article, we’ll explore the complete lifecycle of a contactless payment transaction from the perspective of an Android HCE payment application and understand how APDU commands enable secure communication between a Point-of-Sale (POS) terminal and a mobile wallet.

Table of Contents

1. Introduction to Contactless Payments
2. What is APDU Communication?
3. Android Host Card Emulation (HCE)
4. High-Level Payment Architecture
5. Complete EMV Transaction Flow
6. SELECT PPSE
7. SELECT AID
8. GET PROCESSING OPTIONS (GPO)
9. READ RECORD
10. GENERATE APPLICATION CRYPTOGRAM (GEN AC)
11. Cryptogram Generation Internals
12. Visa Tokenization and Mobile Wallet Processing
13. Online Authorization
14. Transaction Completion
15. Common EMV Tags Explained
16. APDU Sequence Diagram
17. Key Takeaways

Introduction to Contactless Payments

Contactless payments are built on Near Field Communication (NFC) technology and the EMV specification.

When a customer taps their mobile device on a payment terminal:

1. The terminal detects the NFC field.
2. Android routes incoming APDU commands to the wallet application.
3. The wallet behaves like a physical EMV card using Host Card Emulation (HCE).
4. The terminal retrieves payment data.
5. A cryptogram is generated.
6. The issuer validates the transaction.
7. The payment is approved or declined.

Although this process typically completes in less than one second, dozens of EMV data elements and security checks are involved.

What is APDU Communication?

APDU (Application Protocol Data Unit) is the communication protocol used between a payment terminal and a smart card or mobile wallet during an EMV transaction.

Think of APDUs as the language spoken between the POS terminal and the payment application. Every action performed during a contactless transaction is initiated through an APDU command and completed with an APDU response.

When a customer taps their phone on a payment terminal, the terminal does not immediately request payment authorization. Instead, it begins a structured conversation with the mobile wallet by exchanging a series of APDU commands.

Each command serves a specific purpose in the transaction lifecycle.

Common APDU Commands Used in an EMV Transaction

🔹 SELECT

Used to discover and select a payment application, such as Visa or Mastercard. The terminal first selects the Proximity Payment System Environment (PPSE) and then the desired Application Identifier (AID).

🔹 GET PROCESSING OPTIONS (GPO)

Requests the card’s processing capabilities and transaction requirements. In response, the card or mobile wallet typically returns the Application Interchange Profile (AIP) and Application File Locator (AFL), which guide the next steps of the transaction.

🔹 READ RECORD

Retrieves application data specified by the AFL. This may include important payment information such as the Primary Account Number (PAN), Track 2 Equivalent Data, Issuer Application Data (IAD), and Application Transaction Counter (ATC).

🔹 GENERATE APPLICATION CRYPTOGRAM (GENERATE AC)

Requests the generation of a cryptogram using transaction data supplied by the terminal. The card or mobile wallet responds with security data such as the Application Cryptogram (ARQC, TC, or AAC), Cryptogram Information Data (CID), Issuer Application Data (IAD), and Application Transaction Counter (ATC).

Transaction Flow Overview

SELECT
   ↓
GET PROCESSING OPTIONS (GPO)
   ↓
READ RECORD
   ↓
GENERATE AC

At a high level:

• SELECT → Discover and select the payment application
• GPO → Obtain processing capabilities and record locations
• READ RECORD → Retrieve payment and application data
• GENERATE AC → Generate a secure cryptogram for transaction authorization

Why APDUs Matter

These four commands form the foundation of nearly every EMV contactless transaction. Through this structured exchange of commands and responses, the terminal gathers payment data, evaluates card capabilities, and ultimately requests a cryptographic proof that the transaction is genuine.

The mobile wallet processes each APDU command and returns a corresponding APDU response containing payment information, EMV data elements, and cryptographic values. This secure exchange enables the issuer to verify the authenticity of the transaction and helps protect against fraud, replay attacks, and data tampering.

In simple terms, every successful tap-to-pay transaction is powered by a carefully orchestrated sequence of APDU conversations occurring behind the scenes in just a few hundred milliseconds.

Android Host Card Emulation (HCE)

Android HCE enables a mobile device to emulate a contactless smart card without requiring a secure element.

The Android framework forwards APDU commands to a **HostApduService**.

Typical implementation:

override fun processCommandApdu(
    commandApdu: ByteArray?,
    extras: Bundle?
): ByteArray {
    return apduProcessor.process(commandApdu)
}

The application becomes responsible for:

• Processing EMV commands
• Managing payment credentials
• Generating cryptograms
• Constructing EMV responses
• Handling tokenized card data

High-Level Payment Architecture

┌──────────────────┐
│   POS Terminal   │
└────────┬─────────┘
         │ NFC
         ▼
┌──────────────────┐
│ Android NFC Stack│
└────────┬─────────┘
         ▼
┌──────────────────┐
│ HostApduService  │
└────────┬─────────┘
         ▼
┌──────────────────┐
│  Wallet SDK      │
└────────┬─────────┘
         ▼
┌──────────────────┐
│ Token & Crypto   │
│ Engine           │
└──────────────────┘

Figure 1: High-level communication architecture of an Android HCE payment application.

Complete EMV Contactless Transaction Flow

SELECT PPSE
      │
      ▼
SELECT AID
      │
      ▼
GET PROCESSING OPTIONS
      │
      ▼
READ RECORD
      │
      ▼
GENERATE AC (ARQC)
      │
      ▼
ONLINE AUTHORIZATION
      │
      ▼
ARPC RECEIVED
      │
      ▼
TC / AAC

Figure 2: Typical EMV contactless payment flow.

Step 1: SELECT PPSE

The transaction begins with application discovery.

The terminal selects the Proximity Payment System Environment (PPSE).

Command

00 A4 04 00 0E
325041592E5359532E4444463031
00

Meaning

2PAY.SYS.DDF01

The terminal is asking:

“Which payment applications are available?”

Typical Response Tags

Tag Description 6FFCI Template 84DF Name A5 Proprietary Template BF0C Issuer Data 61 Directory Entry 4F Application Identifier 50 Application Label

Example

A0000000031010

Visa Credit/Debit Application.

Step 2: SELECT AID

After discovering available applications, the terminal selects the desired payment application.

Visa Example

00 A4 04 00
07 A0000000031010
00

Purpose

Select the Visa application for transaction processing.

Response Contains

When the terminal successfully selects the payment application (for example, Visa), the card or mobile wallet returns application-specific information required for the next stages of transaction processing.

Common response elements include:

🔹 84 — Dedicated File (DF) Name Contains the Application Identifier (AID) of the selected payment application, confirming which application has been chosen for the transaction.

🔹 50 — Application Label A human-readable name for the payment application, such as Visa Credit, Visa Debit, or another scheme-specific label.

🔹 9F38 — Processing Data Object List (PDOL) Defines the data elements that the terminal must provide in the upcoming GET PROCESSING OPTIONS (GPO) command. The PDOL acts as a request for transaction and terminal information required by the card or wallet.

🔹 BF0C — Issuer Discretionary Data Contains issuer-specific information and optional data elements that may be used during transaction processing. The contents vary depending on the payment scheme and issuer implementation.

Why This Response Is Important: The SELECT AID response provides the terminal with the information needed to continue the EMV transaction. In particular, the PDOL (9F38) is critical because it tells the terminal exactly what data must be included in the GET PROCESSING OPTIONS (GPO) request, enabling the card or mobile wallet to evaluate the transaction and determine the next processing steps.

Understanding PDOL

PDOL (Processing Data Object List) defines what information the terminal must provide.

Example:

9F66049F02069F3704

Which means:

9F66 — Terminal Transaction Qualifiers (TTQ) Defines the terminal’s capabilities and transaction requirements, such as support for contactless payments, online processing, CDCVM, and mobile wallet transactions.

🔹 9F02 — Authorized Amount Represents the transaction amount that the cardholder is attempting to pay.

🔹 9F37 — Unpredictable Number (UN) A random value generated by the terminal to ensure transaction uniqueness and protect against replay attacks.

What the PDOL Does: The Processing Data Object List (PDOL) acts as a request from the card or mobile wallet, telling the terminal exactly which pieces of information are required before transaction processing can continue. The terminal collects these values, constructs the PDOL data block, and includes it in the GET PROCESSING OPTIONS (GPO) command.

Step 3: GET PROCESSING OPTIONS (GPO)

The terminal builds PDOL data and sends a GPO command.

Command

80 A8 00 00
<Lc>
83 <PDOL Data>
00

Terminal Data Typically Sent

When the terminal sends a GET PROCESSING OPTIONS (GPO) command, it includes transaction-specific information defined by the Processing Data Object List (PDOL). This data helps the card or mobile wallet determine how the transaction should be processed.

Common PDOL data elements include:

🔹 9F66 — Terminal Transaction Qualifiers (TTQ) Defines the terminal’s capabilities, such as support for contactless transactions, online authorization, CDCVM, and mobile wallet processing.

🔹 9F02 — Authorized Amount The amount of the transaction that the customer is attempting to pay.

🔹 9F1A — Terminal Country Code Identifies the country where the transaction is being performed.

🔹 5F2A — Transaction Currency Code Specifies the currency used for the transaction, such as INR, USD, or EUR.

🔹 9A — Transaction Date The current date of the transaction, provided by the terminal.

🔹 9C — Transaction Type Indicates the nature of the transaction, such as purchase, cashback, refund, or cash withdrawal.

🔹 9F37 — Unpredictable Number (UN) A random value generated by the terminal to ensure that each transaction is unique and protected against replay attacks.

Why This Data Is Important: The card or mobile wallet uses these terminal-provided values to evaluate transaction conditions, perform risk management checks, determine Cardholder Verification Method (CVM) requirements, and prepare for cryptogram generation later in the transaction flow. During the GENERATE AC phase, several of these values are incorporated into the cryptographic calculation of the Authorization Request Cryptogram (ARQC).

GPO Response

The card or mobile wallet returns:

82 — Application Interchange Profile (AIP) Defines the capabilities supported by the card or mobile wallet. The terminal uses this information to determine how the transaction should be processed.

The AIP may indicate support for:

• SDA (Static Data Authentication)
• DDA (Dynamic Data Authentication)
• CDA (Combined Data Authentication)
• Cardholder Verification Methods (CVM)
• Issuer Authentication
• Offline Data Authentication

🔹 94 — Application File Locator (AFL) Specifies which application records the terminal must retrieve using READ RECORD commands.

The AFL contains:

• Short File Identifiers (SFI)
• Record Numbers
• Range of records to be read
• Offline authentication record information

The terminal uses the AFL as a roadmap to determine which records contain important payment data such as the PAN, Track 2 Equivalent Data, IAD, and other EMV tags.

Why the GPO Response Matters: The Application Interchange Profile (AIP) tells the terminal what the card or wallet is capable of, while the Application File Locator (AFL) tells the terminal where to find the required payment data. Together, these two data objects drive the next phase of the EMV transaction and determine which records must be read before cryptogram generation can occur.

AIP (Application Interchange Profile)

Indicates supported capabilities:

• SDA
• DDA
• CDA
• Cardholder Verification

AFL (Application File Locator)

Specifies which records the terminal should read next.

Step 4: READ RECORD

Using the AFL, the terminal retrieves EMV records.

Command

00 B2 <Record Number> <SFI> 00

Example:

00 B2 01 0C 00

Common Data Returned

After receiving the Application File Locator (AFL) from the GPO response, the terminal issues one or more READ RECORD commands to retrieve payment and application data from the card or mobile wallet.

Commonly returned EMV data elements include:

🔹 5A — Primary Account Number (PAN) Contains the card number or tokenized PAN used to identify the payment account.

🔹 57 — Track 2 Equivalent Data Contains payment information such as the PAN, expiration date, and service code in a format similar to magnetic stripe Track 2 data.

🔹 5F24 — Application Expiration Date Specifies the expiration date of the card or payment credential.

🔹 5F20 — Cardholder Name Contains the cardholder’s name, when supported by the payment application.

🔹 9F10 — Issuer Application Data (IAD) Contains issuer-specific information used for risk management, cryptogram validation, and transaction processing.

🔹 9F6C — Card Transaction Qualifier (CTQ) Defines card or wallet requirements for transaction processing, including Cardholder Verification Method (CVM) and online authorization behavior.

🔹 9F36 — Application Transaction Counter (ATC) A transaction counter maintained by the card or wallet that increments with every transaction and helps prevent replay attacks.

Why READ RECORD Is Important: The data retrieved during the READ RECORD phase provides the terminal with essential payment information required for transaction processing. Many of these data elements are later used during the GENERATE AC command to create the Authorization Request Cryptogram (ARQC) and support issuer-side transaction validation.

Mobile Wallet Specific Processing

Unlike physical cards, mobile wallets perform additional operations:

Token Validation

Verify:

• Token Active
• Token Expiry
• Token Usage Counter
• Token TTL

CDCVM Evaluation

Determine whether:

• Device Unlock Succeeded
• Biometric Authentication Completed
• Consumer Device CVM Performed

CVR Update

Update Card Verification Results based on transaction context.

Step 5: GENERATE APPLICATION CRYPTOGRAM

This is the most security-critical phase of the transaction.

Command

80 AE 80 00
<Lc>
<CDOL1 Data>
00

CDOL1 Data

Typical fields include:

The Card Risk Management Data Object List 1 (CDOL1) defines the transaction data that the terminal must provide to the card or mobile wallet when requesting an Application Cryptogram.

The most commonly used CDOL1 elements include:

🔹 9F02 — Authorized Amount The transaction amount that the cardholder is attempting to pay.

🔹 9F03 — Other Amount An additional amount associated with the transaction, such as cashback or cash withdrawal.

🔹 9F1A — Terminal Country Code Identifies the country where the transaction is being performed.

🔹 95 — Terminal Verification Results (TVR) Contains the results of terminal-side checks and risk management validations performed during the transaction.

🔹 5F2A — Transaction Currency Code Specifies the currency used for the transaction (for example, INR, USD, or EUR).

🔹 9A — Transaction Date The date on which the transaction is taking place.

🔹 9C — Transaction Type Indicates the type of transaction being performed, such as purchase, cashback, or cash withdrawal.

🔹 9F37 — Unpredictable Number (UN) A random value generated by the terminal to ensure each transaction is unique and protected against replay attacks.

Why CDOL1 Matters: During the GENERATE AC command, these data elements are combined with card-specific information such as the Application Transaction Counter (ATC) and cryptographic session keys to generate the Authorization Request Cryptogram (ARQC). This ensures that every transaction produces a unique cryptographic value that can be validated by the issuer.

Cryptogram Generation Process

Transaction Data
       │
       ▼
     CDOL1
       │
       ▼
 Session Key
       │
       ▼
Cryptographic Engine
       │
       ▼
      ARQC
       │
 ┌─────┼─────┐
 ▼     ▼     ▼
ATC   CVR   IAD

Figure 3: High-level ARQC generation flow.

Visa Mobile Wallet Processing

For tokenized Visa transactions, additional wallet-specific processing occurs.

Inputs

• DPAN
• Token Reference
• Token Usage Counter
• LUK
• TTL
• Transaction Data

Internal Processing

LUK
 │
 ▼
Session Key Derivation
 │
 ▼
Cryptogram Generation
 │
 ▼
ARQC

The wallet constructs:

• CVR
• IAD
• CID
• ATC
• ARQC

Important Cryptogram Tags

When the GENERATE AC (Application Cryptogram) command is executed, the card or mobile wallet returns several critical EMV data elements that are used by the issuer to validate the transaction.

🔹 9F26 — Application Cryptogram (AC) The cryptographic value generated during the transaction. Depending on the transaction stage, it can represent an Authorization Request Cryptogram (ARQC), Transaction Certificate (TC), or Application Authentication Cryptogram (AAC).

🔹 9F27 — Cryptogram Information Data (CID) Indicates the type of cryptogram generated and the card’s decision for the transaction, such as requesting online authorization, approving offline, or declining the transaction.

🔹 9F10 — Issuer Application Data (IAD) Contains issuer-specific information used for transaction validation, risk management, and cryptogram verification. It may include data such as CVR, CVN, DKI, and other issuer discretionary information.

🔹 9F36 — Application Transaction Counter (ATC) A transaction counter maintained by the card or mobile wallet that increments with every transaction. It helps prevent replay attacks and is commonly used during session key derivation and cryptogram generation.

Why These Tags Matter: During the GENERATE AC command, the card or mobile wallet combines transaction data, terminal data, cryptographic keys, and the Application Transaction Counter (9F36) to generate the Application Cryptogram (9F26). The issuer later validates this cryptogram using information contained in the Issuer Application Data (9F10) and the cryptogram type indicated by 9F27 (CID), ensuring the authenticity and integrity of the transaction.

Example:

9F26 08 XXXXXXXX
9F27 01 80
9F10 12 XXXXXXXX
9F36 02 0025

APDU Sequence Diagram

POS Terminal                 Mobile Wallet

     │                              │
     │ SELECT PPSE                 │
     ├────────────────────────────►│
     │◄────────────────────────────┤
     │ FCI Response                │
     │                              │
     │ SELECT AID                  │
     ├────────────────────────────►│
     │◄────────────────────────────┤
     │ PDOL                        │
     │                              │
     │ GPO                         │
     ├────────────────────────────►│
     │◄────────────────────────────┤
     │ AIP + AFL                   │
     │                              │
     │ READ RECORD                 │
     ├────────────────────────────►│
     │◄────────────────────────────┤
     │ Card Data                   │
     │                              │
     │ GENERATE AC                 │
     ├────────────────────────────►│
     │◄────────────────────────────┤
     │ ARQC                        │

Figure 4: APDU command exchange during an EMV contactless transaction.

Online Authorization

After receiving the ARQC, the terminal forwards authorization data through the payment network.

POS Terminal
      │
      ▼
Acquirer
      │
      ▼
Payment Network
      │
      ▼
Issuer

The issuer validates:

• ARQC
• ATC
• Token Status
• Risk Parameters
• Card Verification Results

If approved, an ARPC is generated and returned.

Transaction Completion

The terminal may request a second cryptogram.

Possible outcomes:

CryptogramMeaningTCTransaction ApprovedAACTransaction Declined

This completes the EMV transaction lifecycle.

Common EMV Tags Every Payment Engineer Should Know

🔹 5A — PAN (Primary Account Number) Contains the card number or tokenized PAN used for payment transactions.

🔹 57 — Track 2 Equivalent Data Contains card information such as PAN, expiration date, and service code in a format similar to magnetic stripe Track 2 data.

🔹 82 — Application Interchange Profile (AIP) Defines the card’s capabilities, such as support for SDA, DDA, CDA, and cardholder verification methods.

🔹 94 — Application File Locator (AFL) Specifies which application records the terminal should read using READ RECORD commands.

🔹 95 — Terminal Verification Results (TVR) Contains the results of terminal-side risk management and verification checks performed during the transaction.

🔹 9F02 — Authorized Amount Represents the transaction amount being authorized.

🔹 9F10 — Issuer Application Data (IAD) Contains issuer-specific information used for risk management, cryptogram validation, and card verification.

🔹 9F26 — Application Cryptogram (AC) The cryptographic value generated by the card or wallet. Depending on the transaction stage, it may represent an ARQC, TC, or AAC.

🔹 9F27 — Cryptogram Information Data (CID) Indicates the type of cryptogram generated, such as ARQC, TC, or AAC.

🔹 9F36 — Application Transaction Counter (ATC) A transaction counter that increments with every transaction, helping prevent replay attacks.

🔹 9F37 — Unpredictable Number (UN) A random value generated by the terminal and used during cryptogram generation to ensure transaction uniqueness.

🔹 9F66 — Terminal Transaction Qualifiers (TTQ) Describes terminal capabilities, including support for contactless transactions, online processing, and mobile wallet features.

🔹 9F6C — Card Transaction Qualifier (CTQ) Defines card or wallet requirements for transaction processing, including Cardholder Verification Method (CVM) and online authorization rules.

Key Insight: During a typical contactless transaction, tags such as 9F02, 9F37, 95, and 9F36 are combined to generate the 9F26 Application Cryptogram, which serves as cryptographic proof of transaction authenticity.

Key Takeaways

A simple tap on a payment terminal triggers a highly secure sequence of EMV operations involving application discovery, transaction data exchange, token validation, cryptographic processing, and issuer authorization.

The APDU commands — SELECT, GPO, READ RECORD, and GENERATE AC — form the foundation of every EMV contactless transaction. Understanding these commands and the data exchanged between the terminal and the wallet is essential for engineers working with NFC payments, Android HCE, EMV kernels, tokenization platforms, and mobile wallet solutions.

As contactless payments continue to dominate the payment ecosystem, a solid understanding of APDU communication and EMV transaction flows remains one of the most valuable skills for payment engineers and fintech developers.