What Actually Happens When You Dip a Chip: The EMV Transaction Flow End-to-End

💡 TL;DR (Too Long; Didn't Read)

The whole transaction in 90 seconds:

• A chip payment is a conversation, not a lookup. The terminal and the card exchange APDUs (command/response pairs) across roughly ten phases, and every phase mutates a shared state that lives in EMV tags.
• The card never says "approved." It hands back a cryptogram (TC, ARQC, or AAC) and lets the terminal — and, when online, the issuer — decide.
• The five moving parts you must be able to name: application selection, GET PROCESSING OPTIONS (which returns the AIP and AFL), READ RECORD (which fetches the data objects), offline data authentication (SDA/DDA/CDA), and GENERATE AC (which produces the cryptogram).
• Everything downstream in this series — TLV parsing, the TVR decision, the ARQC — is one of these phases seen up close. This article is the map; the rest are the terrain.

Dip a chip at a checkout and the whole thing feels instant. It is not instant. In the two-to-four hundred milliseconds between insertion and the beep, the terminal and the card run a structured negotiation with at least a dozen message exchanges, several cryptographic operations, and a decision tree that can send the transaction offline, online, or straight to a decline. Most engineers who work near payments — building the POS app, the acquirer host, the issuer's authorization stack — have never watched that negotiation end to end. They know their slice. This article is the whole slice, in order, with the actual bytes.

I am going to trace a single contact transaction (the dip, not the tap) because contact is the cleanest teacher: it is synchronous, the phases are explicit, and the contactless kernels are essentially optimizations layered on top of this same spine. Everything here is defined in the EMV Integrated Circuit Card Specifications for Payment Systems, Books 1–4 (EMVCo). I will cite the Book and section rather than reproduce spec text — the specs are copyrighted and we do not redistribute them; we build tools and derived knowledge on top of them.

The mental model: a conversation over APDUs

The card is a smartcard. You talk to it with APDUs — Application Protocol Data Units, defined by ISO/IEC 7816-4 and profiled by EMV Book 1. A command APDU is a header (CLA INS P1 P2) plus optional data; the response is optional data plus a two-byte status word SW1 SW2, where 90 00 means "OK" and 61 xx / 6C xx are the usual "more data available / wrong length" nudges.

Hold two ideas in your head for the entire flow. First: the terminal drives. The card is reactive — it answers questions, it never volunteers. Second: state accumulates in tags. Every meaningful value — the PAN, the risk flags, the verification result, the cryptogram — is a BER-TLV data object with a well-known tag. The transaction is really the terminal assembling a picture of the card, tag by tag, until it has enough to make a decision.

Here is the flow at altitude before we walk it.

Now the walk.

Phase 1 — Application selection

The terminal has to pick which payment application on the card to run. There are two ways in. The classic PSE method sends SELECT for the Payment System Environment directory file, 1PAY.SYS.DDF01:

→ 00 A4 04 00 0E 31 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
← 6F ... (FCI Template)  90 00

00 A4 04 00 is SELECT by DF name. The card returns a File Control Information template (tag 6F) that points at a directory the terminal can read to enumerate applications. The modern, more robust method is PSE-less selection: the terminal just tries the AIDs it supports, most-preferred first, with SELECT by AID:

→ 00 A4 04 00 07 A0 00 00 00 03 10 10 00   (Visa credit/debit)
← 6F ...  90 00

A0000000031010 is a Registered Application Provider Identifier plus a proprietary suffix. The terminal builds a candidate list of applications supported by both card and terminal, applies priority (tag 87, Application Priority Indicator), and, if more than one qualifies and cardholder confirmation is required, may present a choice. The output of this phase is a single selected AID and its FCI — including the PDOL (Processing Options Data Object List, tag 9F38) if the card wants transaction context up front.

The most common integration bug lives right here: terminals that hardcode PSE and fall over on cards that only support the AID list, or that ignore the priority indicator and select a co-badged scheme the merchant didn't intend. Application selection is business logic wearing a protocol costume.

Phase 2 — Initiate processing: GET PROCESSING OPTIONS

With an application selected, the terminal issues GET PROCESSING OPTIONS (GPO). If the card gave a PDOL, the terminal must supply those data objects now — things like the amount, terminal country code, transaction currency, the terminal's capabilities, and a freshly generated Unpredictable Number (tag 9F37). The PDOL is the card saying "before I tell you how I work, tell me about this transaction."

→ 80 A8 00 00 <Lc> 83 <len> <PDOL-related data> 00
← 77 ... (AIP 82 + AFL 94)  90 00

The response carries two data objects that steer the rest of the transaction:

• AIP — Application Interchange Profile (tag 82, 2 bytes). A bit field of card capabilities: does it support SDA, DDA, CDA? Is cardholder verification supported? Should terminal risk management be performed? Is issuer authentication supported? (EMV Book 3, Annex C.)
• AFL — Application File Locator (tag 94). A list of 4-byte entries telling the terminal exactly which records to read: an SFI (Short File Identifier), a first and last record number, and how many of those records are covered by offline data authentication.

The AIP is the card's declaration of what it can do; the AFL is the card's index of where its data lives. Nothing else in the transaction makes sense until you have both.

Phase 3 — Read application data: READ RECORD

The terminal now walks the AFL and issues one READ RECORD per record:

→ 00 B2 01 0C 00      (record 1, SFI 1 → P2 = (1<<3)|4 = 0x0C)
← 70 ... (AEF Data Template)  90 00

P2's upper five bits are the SFI, the low three bits are 100 to mean "P1 is a record number." Each response is a 70 template full of the data objects that define this card and this account: the Application PAN (tag 5A), the PAN Sequence Number (5F34), the expiry (5F24), the CDOL1/CDOL2 (8C/8D), the CVM List (8E), the Certificate Authority Public Key Index (8F), the issuer and ICC public key certificates (90, 9F46), and more.

Two of these deserve a flag now because they drive later phases. CDOL1 and CDOL2 are Card Risk Management Data Object Lists: they are the card telling the terminal exactly which tags, in which order, it wants handed to the first and second GENERATE AC commands. And the CVM List is the ordered set of cardholder verification rules the card is willing to accept. You are reading them now; you will use them in Phases 6 and 8. To decode any of these 70-wrapped structures by hand you have to parse BER-TLV — which is Part 2 of this series, and the reason it exists.

Phase 4 — Offline Data Authentication

Here the transaction stops being bookkeeping and starts being cryptography. Offline Data Authentication (ODA) lets the terminal verify, without contacting the issuer, that the card's static data is genuine and, in the stronger modes, that the card itself is not a clone. Which method runs depends on the AIP and the terminal's capabilities:

• SDA (Static Data Authentication). The terminal validates a signature over static card data using a chain of RSA keys: the scheme's CA public key (looked up by RID + the CA PK Index in tag 8F) verifies the Issuer Public Key Certificate, which in turn validates the Signed Static Application Data. Proves the data is authentic; does not prove the card is real. Cloneable.
• DDA (Dynamic Data Authentication). Adds an on-card RSA key pair. The terminal sends a challenge via INTERNAL AUTHENTICATE; the card signs it. A cloned card can't produce the signature without the private key, so DDA defeats simple replay/clone attacks.
• CDA (Combined DDA/Application Cryptogram). DDA fused with the cryptogram generation in GENERATE AC, so the dynamic signature also covers the cryptogram. The strongest and now the default expectation.

The mechanics of that RSA chain — recovering the issuer key, checking the hash and the trailer byte BC, validating certificate expiry — are their own deep dive. What matters for the flow: ODA sets bits in the Terminal Verification Results (tag 95) if anything fails, and those bits feed the decision engine in Part 3.

Phases 5–7 — Restrictions, cardholder verification, risk management

Three quieter phases run before the cryptogram, each contributing to the same accumulating verdict.

Processing restrictions checks that the application versions match, that the Application Usage Control (tag 9F07) permits this kind of transaction (domestic vs international, cash vs goods), and that today falls inside the application's effective and expiry dates. Failures set TVR bits, they don't necessarily stop the transaction.

Cardholder Verification walks the CVM List (tag 8E) in order, evaluating each rule's condition against the transaction until one applies: offline PIN (plaintext or enciphered), online PIN, signature, Consumer Device CVM (the on-phone biometric), or "no CVM required." The result — which method ran and whether it succeeded — lands in the CVM Results (tag 9F34). This is where the "chip and PIN vs chip and signature" cultural divide actually lives: same spec, different CVM List priorities.

Terminal Risk Management is the terminal's own offline sanity check, independent of the card: is the amount over the floor limit? Should this transaction be pushed online by random selection? Does velocity checking (comparing the card's Application Transaction Counter against the Last Online ATC) suggest too many offline transactions have stacked up? Each concern, again, sets a TVR bit.

By the end of Phase 7 the terminal holds a fully populated TVR (tag 95) and a TSI (Transaction Status Information, tag 9B) recording which functions were performed. It is now ready to ask the card for a decision — but the decision is a negotiation, not a command.

Phase 8 — The cryptogram: GENERATE AC

The terminal performs Terminal Action Analysis: it compares the TVR against the Issuer Action Codes (Denial/Online/Default) and the Terminal Action Codes to form a proposal — approve offline, go online, or decline — and encodes that proposal as the cryptogram type it requests in the first GENERATE AC:

→ 80 AE 80 00 <Lc> <CDOL1 data> 00     (P1 = 0x80 → request ARQC)
← 77 ... 9F27 (CID) 9F36 (ATC) 9F26 (AC) 9F10 (IAD)  90 00

P1 requests TC (0x40, approve offline), ARQC (0x80, go online), or AAC (0x00, decline); adding 0x10 requests CDA. The data field is exactly the CDOL1 tags the card asked for back in Phase 3. The card then runs Card Action Analysis — its own risk logic — and answers with a Cryptogram Information Data (tag 9F27) that states which cryptogram it actually generated. Crucially, the card can downgrade the terminal's request. Ask for a TC and the card can still insist on an ARQC (force it online) or an AAC (decline) if its internal risk management disagrees. The card is not a rubber stamp.

The cryptogram itself — the Application Cryptogram (tag 9F26) — is a MAC computed under a card key over the transaction data, accompanied by the Application Transaction Counter (tag 9F36) and the Issuer Application Data (tag 9F10). How that MAC is derived, and why it is the anti-fraud keystone of the whole system, is Part 4. For now: the card just returned a cryptographic assertion about this transaction that only the issuer can fully verify.

Phases 9–12 — Online, scripts, completion

If the cryptogram is an ARQC, the terminal cannot approve on its own; it must go online. The acquirer wraps the EMV data — the cryptogram and its supporting tags — into ISO 8583 field 55 and routes the authorization to the issuer. (That ISO 8583 envelope and the field-55 bridge are their own subject, coming later in this series.) The issuer validates the ARQC, makes the accept/decline call, and returns an ARPC (Authorisation Response Cryptogram) plus an Authorisation Response Code, optionally with issuer scripts (templates 71/72) carrying commands like PIN change, application block/unblock, or parameter updates — each protected by its own MAC.

The terminal delivers any scripts to the card, then issues the second GENERATE AC to complete: the card weighs the issuer's response (including whether issuer authentication via the ARPC succeeded) and returns a final TC (approved) or AAC (declined). The beep you hear is the terminal reading that last cryptogram type.

Battle scars

Three failure modes I have watched eat days of engineering time, so you can recognize them faster than I did.

The AFL lies about coverage, and your ODA silently no-ops. Each AFL entry says how many records are covered by offline data authentication. Miscount those, hash the wrong record set, and the signature check fails in a way that looks like a bad key. Verify the covered-records arithmetic before you suspect the crypto.

CDOL order is not tag order. CDOL1 dictates the concatenation order of the values you feed to GENERATE AC, and it is not sorted, not the order the tags appeared in the records, and not negotiable. Build the GENERATE AC data field by walking the CDOL literally, left to right, substituting each tag's current value. A single transposed field produces a perfectly-formatted cryptogram that the issuer rejects with no useful error.

A 90 00 is not "approved." The status word 90 00 means "the card processed your APDU." It says nothing about the transaction outcome. The outcome is the cryptogram type in the CID (tag 9F27). I have seen dashboards that treated 90 00 on GENERATE AC as a success metric; they were counting declines as approvals.

Where this series goes next

You now have the map. Every remaining part of Payments Under the Hood zooms into one region of it. Part 2 — "Reading BER-TLV by Hand" dissects the encoding that every 6F, 70, and 77 template in this walk is built from, because you cannot debug a flow you cannot parse. Part 3 — "The TVR, the TSI, and How a Terminal Decides to Decline You" opens up Phase 8's decision engine bit by bit. Part 4 — "ARQC from Scratch" builds the Phase 8 cryptogram with real (test) keys. And the regional finale takes the same rigor to PIX and the EMVCo QR that all of Brazil taps.

If you want to poke at the artifacts as you read, the gsstk EMV Tag Dictionary resolves every tag named here — 82, 94, 8C, 9F27, 9F26 — with its format, template, and the Book it comes from.

Related Reading on gsstk

• Implementing EMV from Scratch: Complete Guide for Payment Terminals — the flagship deep dive this overview anchors.
• Reading BER-TLV by Hand — and Why You Shouldn't — Part 2: the encoding behind every template in this flow.
• The TVR, the TSI, and How a Terminal Decides to Decline You — Part 3: the GENERATE AC decision engine, up close.
• ARQC from Scratch: Application Cryptograms Without the Black Box — Part 4: building the cryptogram this flow returns.
• PIX, BR Code, and the EMVCo MPM — Part 5: the same discipline as a QR code.

Tools: the EMV Tag Dictionary resolves every tag named here; the AID Parameter Table covers the application-selection step.

Filed under: EMV · Payments · POS · Acquiring · Contactless

This article was human-architected and synthesized with AI assistance under the Nexus (AI) persona.