EMV Payment Card Architecture
How chip-based payment transactions work.
EMV Payment Card Architecture
EMV — the global standard for chip-based payment cards published and maintained by EMVCo — defines how a payment card, terminal, and acquirer cooperate to authorise a transaction securely. Deployed in over 10 billion cards worldwide, EMVEMVApplicationGlobal chip payment card standard.Click to view → replaced magnetic stripe transactions by moving cryptographic verification onto the card's secure element.
Use the APDU Builder to construct and inspect EMV command sequences for testing or educational purposes.
EMV Stack and Kernel
The EMV specification suite has four volumes: Book 1 (application-independent ICC to terminal protocol), Book 2 (security and key management), Book 3 (application specification — the "EMV kernel"), and Book 4 (cardholder, attendant, and acquirer interface).
The EMV kernel is the terminal-side software state machine that drives the transaction using APDU commands standardised in Book 3. Kernel variants exist for contactless (EMV Contactless Books A–D, also called kernel IDs 1–6 for specific payment brands).
Transaction Flow
| Step | Terminal action | Card action |
|---|---|---|
| 1. Application selection | SELECT AIDAIDProtocolUnique identifier for card applications.Click to view → (AID) | Return FCI (file control info) |
| 2. Initiate application | GET PROCESSING OPTIONS (PDOL) | Return AIP, AFL |
| 3. Read records | READ RECORD (by AFL) | Return EMV data objects |
| 4. Offline data authentication | Verify static/dynamic signature | Provide signed data / RIDRIDProtocolFirst 5 bytes of AID identifying provider.Click to view → |
| 5. Processing restrictions | Check application version, usage | N/A |
| 6. Cardholder verification | VERIFY (PIN), signature | Verify PIN; return SW |
| 7. Risk management | Check velocity, floor limits | N/A |
| 8. Terminal action analysis | Terminal computes TAC/IAC | N/A |
| 9. Card action analysis | GENERATE AC | Return TC / ARQC / AAC |
| 10. Online authorisation | Send ARQC to issuer | N/A |
| 11. Completion (online) | EXTERNAL AUTHENTICATE | Verify ARPC; return TC/AAC |
| 12. Script processing | APDUAPDUProtocolCommunication unit between card and reader.Click to view → scripts from issuer | Execute scripts |
The card's crypto coprocessor computes the Application Cryptogram (ARQC for online requests, TC for approved offline, AAC for declined) using 3DES3DESCryptographyLegacy triple-DES symmetric cipher in payment smart cards.Click to view → or AESAESCryptographyNIST symmetric block cipher for smart card encryption.Click to view → under a card-unique derived key — a key-derivation scheme so that compromise of one card does not expose others.
Cardholder Verification Methods (CVM)
EMV defines a CVM list stored on the card, processed in priority order:
| CVM | Description | Risk level |
|---|---|---|
| Enciphered PIN (online) | PIN transmitted to issuer encrypted | Highest assurance |
| Enciphered PIN (offline) | PIN verified by card chip | High assurance |
| Plaintext PIN (offline) | PIN verified by card, not encrypted | Medium |
| Signature | Paper receipt signed | Low (manual check) |
| No CVM | Contactless low-value | Lowest (floor-limit governed) |
| Fail CVM | Decline if no match | — |
Modern contactless low-value transactions skip PIN using a No CVM or Consumer Device CVM (CDCVM) path — the smartphone or wearable authenticates the cardholder locally via biometric before emitting the contactless transaction.
Tokenisation
EMV payment tokenisation replaces the Primary Account Number (PAN) with a payment token — a surrogate value that routes back to the real PAN only within the token service provider's network. Tokens are:
- Domain-restricted: bound to a specific device, merchant, or transaction type
- Cryptogram-protected: each transaction generates a unique cryptogram even when the token is the same
- Network-managed: token requestors (wallets, merchants) interact with the TSP via EMVCoEMVCoStandardBody managing EMV payment standards.Click to view →'s token API specifications
This architecture means that a data breach at a merchant or wallet provider exposes tokens that are useless for transactions outside the original domain — a significant improvement over static PAN storage.
Offline Data Authentication
EMV supports three offline authentication mechanisms in increasing security order:
| Mechanism | Abbreviation | Technique | Vulnerability |
|---|---|---|---|
| Static Data Authentication | SDA | Card signs static data with issuer key | Clone attack possible |
| Dynamic Data Authentication | DDA | Card signs terminal challenge at runtime | Resistant to cloning |
| Combined DDA/Application Cryptogram | CDA | DDA combined with AC generation | Highest assurance |
For more on the cryptographic foundations, see Smart Card Cryptography.
常见问题
EMV stands for Europay, Mastercard, and Visa — the three companies that jointly developed the global standard for chip-based payment cards in the early 1990s. The EMVCo consortium now governs the specifications, with members including American Express, Discover, JCB, and UnionPay. EMV defines the application logic, cryptographic protocols, and terminal interactions for contact and contactless payment transactions worldwide.
EMV cards generate a unique cryptogram (ARQC) for each transaction using a symmetric key stored in the secure chip, making card cloning essentially impossible — the cryptogram cannot be replicated without the on-card key. Magnetic stripe data is static and easily skimmed and cloned. Additionally, EMV supports cardholder verification via PIN (offline or online) and Dynamic Data Authentication (DDA) to prevent both card cloning and replay attacks.
Static Data Authentication (SDA) signs static card data with the issuer's private key, but is vulnerable to pre-play attacks since the signed data never changes. Dynamic Data Authentication (DDA) uses the card's own RSA key pair to sign a terminal-supplied nonce, proving card genuineness per transaction. Combined DDA/Application Cryptogram generation (CDA) merges DDA with the transaction cryptogram in a single card command, providing the strongest protection and is now the recommended standard.
EMV 3-D Secure (3DS) is the EMVCo standard for authenticating card-not-present (online/e-commerce) transactions, replacing the older 3DS 1.0 protocol. 3DS2 uses rich contextual data (device fingerprint, transaction history, purchase context) to enable risk-based authentication, often completing low-risk transactions frictionlessly without a one-time password. It is the technical foundation for Verified by Visa, Mastercard Identity Check, and similar issuer authentication programs.
Our guides cover a range of experience levels. Getting Started guides introduce smart card fundamentals. Security guides address Common Criteria certification and key management. Programming guides target developers working with APDU commands, JavaCard applets, and GlobalPlatform card management.