How Does an EMV Contact Chip Card Payment Work? The Transaction Flow Step by Step

When you insert an EMV chip card into a payment terminal, the terminal powers the chip, picks a payment application on it, reads the card’s data, checks that the card is genuine and that you are the cardholder, and then asks the chip to produce a one-time cryptogram that either approves the sale on the spot, declines it, or is sent to the card issuer for an online decision. The money itself moves later, when the merchant’s bank clears and settles the transaction through the card network.

This page walks through that flow for a contact card at a point-of-sale terminal: who acts at each stage, what is exchanged, why it matters, and what typically goes wrong. It is written for developers, testers and product people who need a working mental model before they open a transaction log.

Scope. This is a high-level explanation built from published research papers and public network, industry-forum and processor guidance. The normative rules (command formats, data-object lists, verification-method encodings, terminal and issuer action logic) are defined in EMVCo specifications and in each card scheme’s own rules; they are deliberately not reproduced or paraphrased here. Real terminals skip, reorder or repeat steps depending on how the card and terminal are configured.

How many steps does an EMV transaction have?

There is no single “official” step count you need to memorise. How you slice the flow is a presentation choice. Murdoch, Drimer, Anderson and Bond describe a chip-and-PIN payment as three phases: card authentication, cardholder verification and transaction authorisation. Basin, Sasse and Toro-Pozo, who built a formal model of the standard, use four: initialisation, offline data authentication, cardholder verification and transaction authorisation. Both are accurate. This article uses a finer split so that each stage maps to something you can see in a log or on a terminal screen.

The parties are always the same:

• The card: a chip holding one or more payment applications, keys shared with the issuer and, on most modern cards, its own key pair for signatures.
• The terminal and PIN pad: they drive the conversation with the chip, hold the certificate-authority public keys and apply the merchant’s and acquirer’s settings.
• The acquirer (or its processor): the merchant’s bank, which forwards authorisation requests and later the clearing records.
• The card network: routes messages between acquirers and issuers. It can also answer on the issuer’s behalf (“stand-in”) when the issuer is unreachable.
• The issuer: the cardholder’s bank, which approves or declines and later pays.

The whole flow on one page

The sequence below shows a typical online-authorised contact transaction. If the terminal and card agree to approve offline, everything from “auth request” to the second GENERATE AC is skipped. The first request then asks for an approval cryptogram directly, and nothing goes upstream until clearing.

 CARD (chip)          TERMINAL + PIN PAD        ACQUIRER / NETWORK      ISSUER
     |                        |                         |                  |
     |<--- power, reset ------|                         |                  |
     |---- ATR -------------->|                         |                  |
     |<--- SELECT: which -----|                         |                  |
     |     apps do you hold?  |                         |                  |
     |---- candidate apps --->| match against own list, |                  |
     |                        | ask shopper if needed   |                  |
     |<--- SELECT chosen app -|                         |                  |
     |<--- GET PROCESSING ----|                         |                  |
     |     OPTIONS            |                         |                  |
     |---- what I support, -->|                         |                  |
     |     which records      |                         |                  |
     |<--- READ RECORD (n) ---|                         |                  |
     |---- PAN, expiry, ----->|                         |                  |
     |     certificates,      |                         |                  |
     |     CVM list           |                         |                  |
     |<--- challenge ---------| A. offline data auth.   |                  |
     |     (DDA cards only)   | B. processing limits    |                  |
     |---- signed reply ----->|                         |                  |
     |<--- VERIFY ------------| C. cardholder verif.    |                  |
     |---- PIN ok / n left -->|    (offline PIN only)   |                  |
     |                        | D. terminal risk mgmt   |                  |
     |<--- GENERATE AC -------| E. first decision:      |                  |
     |     (txn data, nonce)  |    approve / decline /  |                  |
     |                        |    go online            |                  |
     |---- ARQC ------------->|---- auth request ------>|---- routed ----->|
     |                        |     + chip data         |   check ARQC,    |
     |                        |                         |   PIN, funds,    |
     |                        |                         |   fraud rules    |
     |                        |<--- response + ARPC ----|<--- approve/ ----|
     |                        |                         |     decline      |
     |<--- ARPC (+ scripts) --|                         |                  |
     |<--- 2nd GENERATE AC ---|                         |                  |
     |---- TC or AAC -------->| "remove card", receipt  |                  |
     X  card leaves           |                         |                  |
                              |                         |                  |
           ... later, in batch or by message ...        |                  |
                              |---- clearing record --->|---- clearing --->|
                              |<=== funds (settlement) =|<=== settlement ==|

Simplified, original diagram. Command names are the ones used in the open literature cited below; the data inside each message is intentionally abstracted. With CDA there is no separate challenge step: the card’s signature comes back with the cryptogram in the GENERATE AC response.

Stage by stage

Insertion, power-up and the Answer to Reset

Nothing happens on a contact card until the reader applies power and resets the chip through the contact plate. The chip answers with an Answer to Reset (ATR), a short string of bytes (a few dozen at most) that tells the reader how to communicate with it. PC/SC smart-card APIs expose exactly this life cycle: a card is present, then powered, then reset, and finally running a specific ISO 7816-3 transmission protocol (T=0 or T=1). From that point on, every exchange is a command/response pair called an APDU. Our APDU commands reference shows what those pairs look like on the wire.

Visa’s merchant guidance stresses the practical consequence: a contact card must stay inserted for the whole transaction, and pulling it out early ends the transaction.

Choosing the payment application

A single card can carry several applications (debit, credit, a domestic scheme, ATM-only functions), each with its own keys. The terminal first asks the card which payment applications it holds. On contact cards it typically does this by selecting a payment directory, then compares the answer with the application identifiers (AIDs) it is configured to accept. If more than one application is possible, the terminal may ask the cardholder to choose. Visa’s merchant guide notes that this prompt only appears when card and terminal share more than one application, or when the card requires it.

The selection logic is covered in depth on two companion pages: how application discovery and selection work and implementing application selection. Identifiers are listed in our AID reference.

Starting the transaction and reading the card

Once an application is selected, the terminal formally starts the transaction with a GET PROCESSING OPTIONS command. If the card asks for them, the terminal includes transaction details such as amount, currency, date and an unpredictable number. The card replies with two things: a profile of what it supports (for example which offline authentication method and whether cardholder verification applies) and a map of the records the terminal should read.

The terminal then issues READ RECORD commands. The records typically include the card number (PAN) and expiry date, a magnetic-stripe-equivalent data copy, the issuer’s certificate chain, the card’s list of acceptable cardholder-verification methods, and lists telling the terminal which transaction data the card will need later. Everything arrives as BER-TLV data objects. Our tag reference and TLV parser walkthrough help when you are decoding them.

Offline data authentication: is this a genuine card?

Before trusting any of that data, the terminal checks it against a public-key chain. The terminal holds the payment schemes’ certificate-authority public keys (see our CA public key list). The card supplies the issuer’s certificate signed by that authority and, for cards with their own key pair, a card certificate signed by the issuer. Three variants exist:

• SDA (static data authentication): the terminal verifies an issuer signature over fixed card data. This proves the data was not altered, but a copied card presents the same signature, so SDA does not stop cloning.
• DDA (dynamic data authentication): the card signs a fresh challenge from the terminal with its own private key, which a skimmed copy cannot do.
• CDA (combined data authentication): like DDA, but the card’s signature also covers the transaction cryptogram and is returned with it in the GENERATE AC response, binding the card’s identity to this particular transaction.

Anderson’s history of the scheme explains why the industry moved from SDA towards DDA and CDA: SDA cards were cheap but left room for counterfeit “yes cards”. The differences are compared in more detail on our SDA vs DDA/CDA page.

Processing restrictions: may this card be used here, now?

The terminal also checks whether this card application is allowed for this transaction. Typical questions are whether the application versions are compatible, whether the card is inside its validity dates, and whether the issuer’s usage rules allow this kind of transaction (for example domestic or cross-border, goods or cash). Visa’s merchant guide frames the whole chip transaction as card and terminal agreeing on the application, “any processing restrictions”, the verification method and the card authentication. The detailed checks are defined in the EMV specifications and are not reproduced here. A failed check does not necessarily stop the transaction. It is recorded and weighed in the decision stage.

Cardholder verification: is this the right person?

The card carries the issuer’s policy as a CVM list: which methods to try, in what order and under what conditions. The terminal works through that list, skipping methods it cannot perform. An unattended kiosk cannot collect a signature, and a terminal without a PIN pad cannot take a PIN. The public merchant guidance names four outcomes:

• Offline PIN: the PIN pad sends the PIN to the chip, which compares it with its stored value and answers “correct” or “wrong, n tries left”. In the enciphered variant the PIN is encrypted under the card’s public key before it leaves the PIN pad. The PIN itself never goes to the issuer.
• Online PIN: the PIN pad encrypts the PIN and it travels with the authorisation request to the issuer, which verifies it. The card is not involved.
• Signature: verification happens on paper or a screen, outside the protocol.
• No CVM: usually reserved for low-value or low-risk transactions.

PIN pads are security-evaluated hardware; the PCI Security Standards Council runs a PIN Transaction Security (PTS) programme for these point-of-interaction devices. A real-world caveat from the research literature: on many cards the chip’s “PIN correct” answer was not itself authenticated. Murdoch and colleagues showed that a man-in-the-middle device could make the terminal believe a PIN had been verified when the card had never checked it.

Terminal risk management

Next the terminal applies its own risk rules. The best-known one is the floor limit, an amount above which the transaction should not be approved without asking the issuer. Floor limits predate chip cards: merchants once used them to decide when to phone for authorisation. Today they still let some terminals keep trading during a network outage. Many markets now operate “online-preferring” terminals that send almost everything online. The EMV Migration Forum describes the U.S. this way, and ATMs generally run online-only.

The first decision and the card’s cryptogram

The terminal now combines everything it has learned with rules set by the issuer on the card and by the acquirer in the terminal. What it has learned covers the authentication result, any restriction failures, the verification outcome and its own risk checks, all recorded in the TVR. The rules are the action codes. From these it decides what to ask for. It then sends GENERATE AC with the transaction data the card asked for earlier, requesting one of three application cryptograms: a TC to approve offline, an ARQC to go online, or an AAC to decline.

The card has the final say in one direction only. It can return what was asked for, or something more cautious: an ARQC when a TC was requested, or an AAC instead of either. It cannot upgrade an online request into an offline approval. The cryptogram is a message authentication code over the transaction details. It is computed with a key that only the card and issuer share and tied to an application transaction counter (ATC) that increases with every transaction. The merchant cannot verify it, but the issuer can. Because the terminal’s unpredictable number goes into the calculation, a weak random-number generator in the terminal undermines the whole design. Anderson’s “pre-play” case study describes terminals and ATMs whose “unpredictable” numbers were effectively counters.

Online authorisation: acquirer, network, issuer

If the card returns an ARQC, the terminal builds an authorisation request. The request carries the usual card-present data plus the chip data: the cryptogram, the counter, the data it was computed over and the terminal’s verification results. In ISO 8583-family messages this chip data sits in a dedicated field, data element 55, as a TLV structure. The request goes to the acquirer, across the network and on to the issuer. The issuer validates the cryptogram, checks any online PIN, the account status, available funds and its fraud models, and answers approve or decline.

U.S. Payments Forum troubleshooting guidance lists the chip-specific reasons an issuer declines. Typical ones are a cryptogram that fails validation (often a key mismatch) and chip data that was dropped or altered by some system along the route. Its rule of thumb: once a cryptogram is generated, no one in the path should modify it.

Back at the card: issuer authentication and scripts

The issuer’s response can include an authorisation response cryptogram (ARPC), computed from the ARQC and the response code. The terminal passes it to the card. By checking it, the card learns that the answer really came from its issuer and was not invented by the terminal. The response may also carry issuer scripts: commands that update data inside the chip while it is in the field, the classic example being unblocking or changing the offline PIN. The terminal is only a conduit for these scripts and does not interpret them.

Finally, the terminal sends a second GENERATE AC, and the card returns a TC to accept the outcome or an AAC to decline. The issuer can approve and the card still decline, for example if issuer authentication fails. In that case the transaction has to be reversed upstream.

Completion and card removal

The terminal shows the result, prompts the cardholder to remove the card and prints or displays a receipt. It keeps the final cryptogram and related chip data, because they go into clearing and are the evidence if the transaction is disputed later.

A variant worth knowing about is Visa’s Quick Chip. The terminal runs the card conversation up to the online cryptogram, tells the cardholder to remove the card, and only then sends the authorisation request. The merchant uses the issuer’s online response to decide. Visa describes this as a terminal software change that needs no change to the card.

After the shopper leaves: clearing and settlement

Authorisation only answers “should the merchant hand over the goods?”. Getting money to the merchant is a separate process. In dual-message processing (common for credit), the acquirer later submits a clearing record, which for chip transactions includes the chip data the networks require. The networks then net positions between banks and settle funds, typically a day or more after the purchase. Anderson notes this is “often two or three days later”. Some debit networks use single-message processing, where authorisation and financial posting happen in one exchange.

Phase, actor, exchange and purpose at a glance

Row-level sources are kept in the page’s provenance file; see the Sources list below.

Key terms you will meet in an EMV log

Four concepts come up constantly when you read EMV transaction logs or decline reports. Here is what each one is, explained conceptually; their byte-level encodings and default values are defined in the EMV specifications and scheme rules and are not reproduced here.

What is the TVR (Terminal Verification Results)?

The TVR is the terminal’s running scorecard for the transaction. It is a compact set of flags that the terminal sets as checks fail or noteworthy events occur. The conditions it records include problems with card authentication, an expired card, failed cardholder verification and an exceeded offline PIN try limit. Industry guidance describes it as the result of the risk-management checks the terminal performs, containing “a lot of useful information about what happened at the terminal, from the terminal’s perspective”.

The TVR feeds two decisions. Locally, it is compared with the action codes to choose which cryptogram to request. Remotely, it is typically part of the data the card’s cryptogram covers and travels to the issuer in the authorisation request, so the issuer sees the same picture. For deferred, force-posted or offline-approved transactions, merchants can evaluate it, where card and terminal support it, to spot expired cards, verification failures or counterfeits. One limitation is documented in the research: Murdoch and colleagues showed that the TVR mainly lists failure conditions and does not unambiguously say which verification method succeeded, which is part of what made their PIN-bypass attack possible.

What are terminal and issuer action codes?

Action codes are the policy that turns the TVR into a decision. Issuer action codes (IAC) are written onto the card by the issuer when it is personalised. Terminal action codes (TAC) are configured in the terminal software by the acquirer. Both express the same kind of preference, based on the risk checks recorded in the TVR: when to approve offline, when to decline offline and when to send the transaction online to the issuer. The issuer’s codes travel in the card’s records as three named sets, default, denial and online. The terminal weighs both parties’ preferences against the TVR to decide whether to ask the card for an AAC, an ARQC or a TC. The evaluation rules and the meaning of each set are defined in the EMV specifications and are not reproduced here. In practice, a decline at the terminal usually means a recorded condition matched a rule. It is a policy outcome, not a random failure.

What is GENERATE AC, and what do AAC, ARQC and TC mean?

GENERATE AC is the command with which the terminal asks the chip to produce an application cryptogram over the transaction data. The terminal says which kind it wants, and the card answers with that kind or a more cautious one:

• AAC = decline. The application authentication cryptogram is produced at the end of offline- and online-declined transactions.
• ARQC = go online. The authorisation request cryptogram goes to the issuer inside the authorisation request so it can verify the card and the message.
• TC = approve. The transaction certificate is produced at the end of approved transactions, whether approved offline or online.

In a typical online transaction the command is used twice: the first time the card returns an ARQC, and after the issuer replies the second returns a TC or an AAC. In an offline approval the first request asks for a TC directly.

What is the ATC (Application Transaction Counter)?

The ATC is a counter inside the card application that increases with every transaction. It is part of what the cryptogram is computed over, and the per-transaction session key that produces the cryptogram is derived from the ATC and a master key that the card and issuer share. That gives each cryptogram a sequence number. Issuers use it to recognise duplicates and replays and for reconciliation. A gap or jump is not automatically suspicious, though. Offline approvals and deferred authorisations reach the issuer late, so the counter “will invariably get out of sequence”, and networks caution issuers against declining on sequence alone.

What does “CDA failed” mean?

With CDA, the card signs its cryptogram together with transaction data using its own private key, and the terminal verifies that signature through the certificate chain: certificate authority, then issuer, then card. “CDA failed” means that verification did not succeed. Reasoning from how CDA works (this is our troubleshooting reading, not a quoted rule), possible causes include a terminal that lacks the certificate-authority public key the card refers to, a certificate in the chain that does not verify, or a signature that does not match the data the terminal sent, which can also indicate tampering between card and terminal. The terminal records the failure in the TVR. What happens next depends on when the failure is detected (before the cryptogram is requested, or in the card’s GENERATE AC response itself) and on rules in the EMV specifications that are not reproduced here. If it happens on every card of one brand at one terminal, suspect terminal key configuration before suspecting the cards.

What can go wrong

The chip cannot be read: fallback

If the chip read fails, perhaps because of a damaged or dirty chip, a worn reader or a card inserted the wrong way, terminals typically retry. Visa recommends allowing two or three attempts before falling back. After that the transaction may fall back to the magnetic stripe, where scheme rules permit it. Fallback is monitored closely for two reasons. Misconfigured terminals can send everything as fallback, for example when the terminal’s hardware has chip readers but its software is not chip-enabled. Fraudsters also force fallback deliberately with blank chips, taped-over contacts or unsupported applications, so that they can use counterfeit stripe data. A chip card whose application the terminal simply does not support is not a valid fallback case under network rules. Liability consequences are covered on our page on liability shifts and fallback transactions, and the stripe’s service code that tells a terminal “this card has a chip” is explained in the service code chart.

Wrong PIN, or a blocked PIN

With offline PIN, each wrong entry decrements a try counter in the chip. The card reports how many tries remain. When none are left it refuses further offline PIN attempts. The cardholder can usually still pay with another method such as online PIN. The issuer can later reset the counter by sending a PIN-unblock issuer script in an online response, typically after the cardholder has proved they know the PIN in an online-verified transaction.

The card is pulled out too early

Removing a contact card before the terminal says so ends the transaction. If the authorisation request had already gone out, a reversal should follow so that the cardholder’s account is not debited for a sale that never completed. Quick Chip exists to reduce exactly this friction.

No connection, or no answer in time

If the terminal asked for an ARQC but cannot reach the issuer, it can ask the card, via the second GENERATE AC, to approve offline. That only works if both card and terminal support offline approval and the amount is within the merchant’s and the card’s limits. Otherwise the result is an offline decline. The EMV Migration Forum describes two merchant-side alternatives, each with its own risk. With deferred authorisation, the merchant stores the transaction, including its chip data, and sends it when connectivity returns. With force post, the merchant submits the transaction into settlement without any issuer authorisation and may ultimately be responsible for the loss if the transaction is charged back. A related side effect is that offline and deferred transactions arrive at the issuer out of counter order, so issuers are cautioned not to decline purely on ATC sequence.

The issuer declines for a chip reason

Not every decline is about funds. The ARQC can fail validation because of key mismatches at the issuer or at a network acting in stand-in. Chip data can be stripped by a non-EMV system in the path. Or the request may contain an inconsistent combination of entry mode, terminal capability and service code. Each of these produces a decline that looks like a card problem but is really a data-path problem.

Protocol weaknesses researchers have demonstrated

The open literature documents several attacks. SDA “yes cards” replay static data to offline terminals. The unauthenticated PIN-verify response enables PIN bypass. Predictable unpredictable numbers enable pre-play. On some contactless configurations, the card’s verification instructions are not authenticated. These are reasons why DDA/CDA, online authorisation and good terminal random-number generators matter. They are not reasons to distrust a correctly configured modern deployment.

Contact vs contactless: what actually changes

If you are building on the phone side of this, our explainer on NFC card emulation mode covers how a handset presents itself as a contactless card.

Frequently asked questions

What are the steps of an EMV chip card transaction?

In outline: the terminal powers the chip and reads its ATR, selects a payment application, reads the card’s data, authenticates the card offline, checks processing restrictions, verifies the cardholder, applies its own risk rules, asks the card for a cryptogram, sends it to the issuer if needed, returns the issuer’s answer to the card, and finishes. Clearing and settlement follow later. Researchers group these into three or four phases; the exact count is a presentation choice, not a rule.

Why do I have to leave my chip card in the terminal?

Because on a classic contact flow the terminal may still need the chip after the issuer replies: to deliver the issuer’s response cryptogram, pass on any scripts and obtain the card’s final cryptogram. Removing the card early ends the transaction. Terminals configured for Visa’s Quick Chip tell you to remove the card sooner because they finish the card conversation before going online.

Is my PIN checked by the card or by the bank?

Either, depending on the card’s verification list and the terminal’s capabilities. With offline PIN the chip checks it and only the result is reported. With online PIN the PIN pad encrypts it and the issuer checks it; the chip never sees it.

Does every chip card payment go online to the bank?

No. EMV allows offline approval when card, terminal and issuer rules permit, which is useful when connectivity is poor. Many markets prefer online authorisation, though, and ATMs generally operate online-only.

When does the merchant actually get paid?

Not at the moment of approval. Approval only reserves the decision; the money moves when the acquirer submits the transaction for clearing and the networks settle between banks, typically a day or more later.

Related reading on Ambimat

• Smart card APDU commands reference
• EMV application discovery and selection, explained
• Implementing EMV application selection
• Static data authentication (SDA) vs DDA and CDA
• EMV certificate-authority public keys
• EMV and NFC BER-TLV tag reference
• EMV liability shifts and fallback transactions
• Mobile payments: NFC card emulation mode
• Cardholder verification in EMV
• EMV issuer scripts

Sources

• Steven J. Murdoch, Saar Drimer, Ross Anderson and Mike Bond (University of Cambridge), Chip and PIN is Broken, IEEE Symposium on Security and Privacy, 2010; §I–III and Appendix A, pp. 433–436, 445. cl.cam.ac.uk
• David Basin, Ralf Sasse and Jorge Toro-Pozo (ETH Zurich), The EMV Standard: Break, Fix, Verify, arXiv:2006.08249v3, 17 February 2021 (IEEE S&P 2021); §III “EMV Description”, Fig. 1 and Fig. 2. arxiv.org
• Ross Anderson, Security Engineering, 3rd edition (Wiley, 2020), chapter 12 “Banking and Bookkeeping”, §12.5 and §12.6.1–12.6.3, pp. 439–455 (free author copy). cl.cam.ac.uk
• Visa, Visa U.S. Merchant EMV Chip Acceptance Readiness Guide, July 2014; sections on chip card types, chip payment processing considerations, CVM options and acceptance procedures (PDF pp. 6, 12–14, 22). usa.visa.com
• Visa, Quick Chip for EMV: Speed Up Your Chip Card Transactions, April 2016; “What’s Happening Behind the Scenes”. visa.com.au
• Visa, Mitigating Fraud on Chip Fallback Transactions, December 2016; pp. 1–2. usa.visa.com
• Visa, Managing Fallback Transactions, August 2015; flowchart and notes. usa.visa.com
• EMV Migration Forum, Merchant Processing During Communications Disruptions, version 1.0, April 2016; pp. 1–4 (archived copy of 22 January 2022). web.archive.org
• EMV Migration Forum, Implementing EMV at the ATM: PIN Change at the ATM, version 1.0, March 2015; §1 scope, §3.4 Issuer Scripts, §3.7 Unblocking the Offline PIN, §7.2.4 and glossary (pp. 6, 15, 19–20, 32, 39–43; archived copy of 24 December 2015). web.archive.org
• U.S. Payments Forum, EMV Troubleshooting Guide for ATM Owners and Operators, version 1.0, November 2017; §2.1.2 fallback, §3.2.3 issuer declines, §3.2.4 reversals (pp. 6, 8–10). emv-connection.com
• Microsoft, SCardStatusA function (winscard.h), Win32 API reference, updated 20 November 2024; card states and ATR buffer. learn.microsoft.com
• jPOS project, jPOS Common Message Format (based on ISO 8583 v2003); DE-055 “Integrated Circuit Card (ICC) Related Data” and DE-056 “Original data elements”. jpos.org
• PCI Security Standards Council, PIN Transaction Security (PTS) Point of Interaction programme page. pcisecuritystandards.org

Written by the Ambimat engineering team from the public sources listed above. EMV is a trademark of EMVCo LLC; this article is not affiliated with or endorsed by EMVCo or any payment network.