In short
- The EMV liability shift is a card network rule, not a US law. Visa, Mastercard, American Express and Discover each announced their own domestic shift dates around October 2015, and each publishes its own operating regulations.
- Liability follows the weakest party in the transaction. If a counterfeit card is presented and the merchant could not read the chip, the merchant generally absorbs the loss instead of the card issuer.
- Fallback is the expensive failure mode. When a chip read fails and the terminal drops to a magnetic stripe swipe, the transaction usually loses the chip protection the store paid for.
- Contactless is chip technology, not stripe technology. A tap that completes normally carries the same counterfeit protection as an inserted chip, which is why tap adoption quietly reduces exposure.
- Most of the risk is operational. Broken readers, stale terminal software, expired certifications and staff workarounds create far more liability than exotic fraud techniques.
Ask a store manager who pays when a fraudulent card is used at the register and you will usually get one of two answers: “the bank” or “we do, through chargebacks.” Both are sometimes right. Which one applies on any given transaction depends almost entirely on how the card was read at the terminal, and that detail is decided in a few hundred milliseconds by hardware and software most retail teams never think about.
This article explains how in-store fraud liability is allocated under the card network rules, why fallback transactions are the most common way stores lose that protection, and what a floor team can actually control. It sits inside our broader guide to payment fraud and chargeback prevention for online retailers, which covers the card-not-present side of the same problem.
What the EMV liability shift actually moved, and to whom
EMV is a set of technical specifications for chip-based payment cards, maintained by EMVCo, a body owned jointly by the major card networks and payment providers. The specifications themselves are neutral engineering documents. They say nothing about who pays for fraud.
The liability allocation comes from a separate layer: the operating rules each card network publishes for its own participants. Around October 2015, Visa, Mastercard, American Express and Discover each implemented a domestic shift in how counterfeit card-present fraud losses are allocated in the United States. Fuel dispensers and some ATM categories followed on later dates set by each network. Anyone who needs the exact dates and categories for a specific business should read the current rules published by the relevant network rather than relying on secondary summaries, including this one.
The rule in plain language
Before the shift, when a counterfeit card was used at a US store, the issuing bank generally absorbed the fraud loss. The merchant was made whole. After the shift, the general principle became simpler and harsher: the party that has not adopted the more secure technology bears the loss.
In practice that produces three common outcomes. If the issuer sent a chip card and the merchant accepted it through a working chip interface, the issuer generally retains counterfeit liability. If the issuer sent a chip card but the merchant processed it as a magnetic stripe transaction, liability generally moves to the merchant. If the issuer never issued a chip card at all, the issuer generally keeps the liability regardless of what the merchant did.
Why “liability shift” is a misleading phrase
Nothing shifted permanently. The rules created a conditional test that is applied transaction by transaction, and the condition is evaluated automatically from data in the authorization message. A store can be protected on one sale and exposed on the next sale five minutes later at the same lane, because a chip read failed.
That conditional nature is what makes the topic operational rather than strategic. There is no project a retailer completes once. There is a read-quality metric that either stays healthy or quietly degrades over a couple of years as readers wear out.
What the shift does not touch
The counterfeit liability rules address one fraud type: a cloned or counterfeit card presented in person. They do not resolve lost or stolen card disputes, which follow different reason codes and different tests. They do not cover card-not-present fraud, which is governed by its own framework and, increasingly, by 3-D Secure 2 and its own liability shift. And they say nothing about whether a cardholder genuinely made the purchase and later regretted it, which is a separate problem entirely.
Chip, contactless and the fallback transaction
A payment terminal can read a card several ways, and each read method carries a different security profile and a different liability outcome. Understanding the ladder is most of the battle.
The read methods, ranked
A contact chip read is the reference case. The chip performs a cryptographic operation unique to that transaction, producing a cryptogram that cannot be replayed. Copying the data from a chip transaction does not let a fraudster manufacture a usable card.
A contactless read, whether from a physical card or from a phone wallet, uses the same underlying chip cryptography over a radio interface. It is not a stripe. This is the single most common misunderstanding among store staff, and it matters because a store that pushes customers toward tap is improving its position, not weakening it. Wallet transactions add another layer through tokenization, which we cover in our piece on Walmart turning on Apple Pay and Google Pay after a long holdout.
A magnetic stripe read sits at the bottom. The stripe contains static data. Anyone who captures it can encode a duplicate card. This is precisely the attack the chip was designed to kill.
Fallback: the trapdoor in the middle
Fallback is what happens when the terminal tries to read the chip, fails, and offers the cashier a stripe swipe instead. The transaction is flagged in the authorization message as a technical fallback, so the network knows the chip was attempted and did not complete.
Fallback exists for a genuine reason. Chips fail. Cards get damaged. A merchant should not have to turn away a paying customer because of a scratched contact plate. But fallback is also the exact behavior a fraudster wants, because a counterfeit card with a deliberately damaged or absent chip forces the terminal down the ladder to the read method the fraudster can actually clone.
Under most network rules, a fallback transaction generally does not carry the chip liability protection. The store completed the sale, took the goods off the shelf, and kept the exposure.
| How the card was read | Underlying security | Typical counterfeit liability outcome | Common cause of use |
|---|---|---|---|
| Contact chip (inserted) | Dynamic cryptogram per transaction | Generally stays with the issuer | Normal operation |
| Contactless card or wallet tap | Same chip cryptography, plus tokenization for wallets | Generally stays with the issuer | Customer preference, speed |
| Technical fallback swipe | Static stripe data after a failed chip attempt | Generally moves to the merchant | Damaged card, dirty or failing reader |
| Direct magnetic stripe swipe | Static stripe data, no chip attempted | Generally moves to the merchant | Non-chip terminal, staff workaround |
| Manually keyed entry | No card authentication at all | Treated as card-not-present in most rule sets | Unreadable card, phone order at the counter |
The table describes general principles that appear across the major networks. Specific outcomes depend on the transaction data, the reason code raised, the region and the current version of each network’s operating regulations, so treat it as orientation rather than as a determination for any individual dispute.
Why a broken chip reader becomes a fraud problem
Retail hardware degrades in a specific and predictable way. Contact chip slots accumulate dust, lint, drink residue and bent pins. A slot that reads perfectly in month one might fail on one card in fifty by month thirty, and the store will not notice, because the terminal handles the failure gracefully by offering a swipe.
The failure is silent by design
Nothing on the receipt says “this transaction lost its fraud protection.” The customer taps or swipes, the sale completes, the queue moves. The cost only appears weeks later as a chargeback, and by then nobody connects it to lane four.
This is why fallback rate deserves a place on an operations dashboard rather than in a payments team spreadsheet. A rising fallback rate at a single lane is a hardware ticket. A rising fallback rate across a store is usually a cleaning and training issue. A rising rate across the estate after a software push is a configuration regression.
Fraudsters read the same dashboard you ignore
Organized card fraud is a logistics business. The people running it test which stores accept fallback without friction, and they return to the ones that do. A store that has quietly been swiping through failed chip reads for six months is not an anonymous target. It is a known one.
Some acquirers and networks now monitor merchant fallback rates and raise them with the merchant when they drift above expected levels. If your processor sends you a fallback report, that report is worth more attention than most of the reporting you receive.
The economics rarely favor tolerating it
A replacement countertop terminal is a modest capital item against the cost of a handful of disputed high-ticket sales, plus the staff time to fight them. The calculus changes for large estates where a rollout means thousands of units, but even then the right comparison is the fallback-attributable loss rate, not the sticker price of the hardware.
Contactless limits and cardholder verification
Cardholder verification method, usually shortened to CVM, is how the transaction establishes that the person holding the card is entitled to use it. The options include online PIN, offline PIN, signature, on-device biometric verification for wallets, and no CVM at all for low-value taps.
The floor limit and why it changed
Contactless transactions below a value threshold typically complete with no cardholder verification. That threshold is set by the networks per market and has been revised upward several times, including during the 2020 pandemic period when several markets raised limits to reduce keypad contact. Because these limits change and vary by network and country, current figures should be confirmed with the acquirer or the network’s published rules rather than assumed.
Above the limit, the terminal will normally request verification, which in the United States usually means a PIN or a wallet biometric. Cards issued in the US have historically leaned toward chip-and-signature rather than chip-and-PIN, though the practical difference has narrowed as signature requirements were dropped by the major networks in 2018.
What CVM does and does not change
Verification mostly matters for lost and stolen card disputes rather than counterfeit ones. A chip read defeats cloning. A PIN defeats a thief using a card they picked up. The two protections address different attackers, and a store can be well covered on one and exposed on the other.
This distinction becomes practical when a store sees a cluster of disputes. Counterfeit patterns point at read quality. Lost and stolen patterns point at verification, at high-value goods that resell easily, and sometimes at the store’s own returns policy.
Tap-to-phone and softPOS
Software-based acceptance on a standard smartphone has moved from pilot to production in several markets, using security standards published by the PCI Security Standards Council. For small merchants and for line-busting in larger stores, it changes the cost of adding an acceptance point substantially.
The liability logic does not change. A contactless read on a certified software solution is still a chip read. What does change is the operational surface, because the device is now a general-purpose phone with an operating system that has to stay updated and a battery that has to survive a shift.
Terminal certification and the software you cannot ignore
A payment terminal is not a fixed appliance. It runs an application certified against a specific processor and network configuration, and that certification is a living dependency.
Where certification actually bites
Certification governs how the terminal formats authorization messages, which entitlement indicators it sets and how it handles edge cases like partial approvals and reversals. A terminal running an uncertified or outdated build can complete sales normally while populating fields in a way that weakens the store’s position in a dispute.
The uncomfortable part is that this failure mode is invisible from the sales floor. Everything looks fine. The problem only surfaces in the representment file, where the evidence you expected to have is missing or malformed. Our guide to chargeback representment and building evidence that wins covers what the data needs to look like when it matters.
PCI DSS is adjacent, not identical
PCI DSS governs how cardholder data is stored, processed and transmitted. It is a security standard maintained by the PCI Security Standards Council, and it applies to merchants through their acquiring agreements. Meeting it does not by itself allocate fraud liability, and being EMV-enabled does not by itself satisfy it.
Retail teams frequently conflate the two, which produces a specific failure: a store passes its annual PCI questionnaire, assumes payments are handled, and never looks at read quality or terminal software versions. Those are different programs with different owners.
| Control area | What it governs | Who typically owns it | Signal that it is failing |
|---|---|---|---|
| Chip read quality | Whether transactions complete on the chip interface | Store operations and facilities | Rising fallback rate at specific lanes |
| Terminal application version | Message formatting and entitlement indicators | IT or the POS vendor | Disputes lost on data grounds despite clean chip reads |
| Network certification status | Whether the configuration is approved by the processor | Payments or finance | Processor notices, unexpected downgrades in interchange |
| PCI DSS scope | Handling and storage of cardholder data | Security and compliance | Failed questionnaire items, unmanaged network segments |
| Staff acceptance procedure | What cashiers do when a read fails | Store management and training | Fallback clustering by shift or by employee |
Upgrades create their own window
The riskiest period is often just after a terminal fleet upgrade, when configuration mistakes are fresh and nobody has baselined the new fallback rate yet. Treat the first sixty days after a rollout as a monitoring period with a named owner, not as a completed project.
What EMV does not cover: the online channel and the gray middle
A store’s total fraud exposure is not the sum of its card-present risk. Buy online and pick up in store, curbside handoff, phone orders taken at a counter and returns without a receipt all sit in a middle ground where card-present protections do not apply cleanly.
Order-ahead and pickup break the model
When the card was entered on a website and the goods leave through a store door, the transaction is card-not-present for liability purposes even though a physical handoff occurred. The evidence that helps in a dispute is therefore different: pickup identity checks, timestamps, signature capture and store camera retention, rather than terminal read data.
Retailers who launched pickup quickly during 2020 and 2021 often never revisited the evidence trail, which is why this channel shows up disproportionately in dispute reviews.
Refund and return abuse
Some in-store losses are not card fraud at all. They are returns of goods bought with a stolen card, or disputes filed by genuine cardholders who received their order. The second pattern is common enough to have its own name, and we cover the diagnostic questions in our piece on telling customer regret apart from card theft.
Separating these categories before designing a response is important. A store that tightens its chip acceptance procedure to solve what is actually a returns policy problem will spend money and see no improvement.
Store procedures that keep liability where it belongs
Almost everything a store team can do about EMV liability comes down to a short list of habits. None of them are technically demanding. All of them decay without attention.
Make the chip path the easy path
If tapping or inserting is faster and more obvious than swiping, staff and customers will do it. Terminal placement, cable length, prompt wording and receipt flow all influence this more than any policy document. Where a terminal still exposes a stripe slot that nobody needs, consider whether the hardware refresh cycle can remove the temptation entirely.
Train the fallback response, not just the fallback rule
Telling cashiers “do not swipe” fails at the first impatient queue. A workable procedure gives them a sequence: try the chip again, try the contactless interface, try a different lane if one is free, and only then use the fallback the terminal offers. Give them permission to ask for a second form of payment on high-value items when a card repeatedly fails to read.
Watch three numbers
Fallback rate by lane, keyed-entry rate by lane and dispute volume by store. Each one is boring in isolation. Together they tell you where the money leaks. A weekly glance is enough for most estates, with a threshold that triggers a hardware ticket rather than a discussion.
Keep the evidence you will need later
Transaction logs with terminal identifiers, camera retention long enough to outlast the dispute window, and a documented pickup verification step for order-ahead sales. Evidence gathered after a chargeback arrives is usually evidence you no longer have.
Escalate patterns, not incidents
One counterfeit transaction is noise. Three at the same lane in a week is a signal, and it is worth telling the acquirer. Networks and issuers run their own fraud analytics, and a merchant report can connect to a pattern they are already tracking.
Putting a number on the exposure
Most retail teams never quantify this, which is why it stays unfunded. The estimate does not need to be sophisticated.
Start with the share of card-present transactions that completed as fallback or direct swipe over a representative period. Multiply by average ticket to get the value processed without chip protection. Then apply an observed counterfeit fraud rate, which the acquirer can usually provide for the merchant category, rather than a guessed one.
The output is a rough annual figure that can be compared against the cost of replacing failing readers or funding a training refresh. In most estates the number is small enough to be ignored at store level and large enough to matter at chain level, which explains why it so often falls between the two.
For a fuller view of how in-store exposure interacts with online disputes, chargeback ratios and the monitoring programs that follow them, our guide to payment fraud and chargeback prevention sets out the whole picture in one place. The technical specifications behind chip transactions are published by EMVCo, and the data security requirements that sit alongside them come from the PCI Security Standards Council.
General information, not legal or compliance advice
This article is general information for retail and payments teams. It is not legal, tax, compliance or customs advice, and it does not establish how any specific transaction or dispute will be decided.
Fraud liability in card payments is governed by private operating rules published by Visa, Mastercard, American Express and Discover, by the terms of your acquiring agreement, and in some cases by applicable consumer protection regulation. Those rules are revised regularly, thresholds and dates change, and outcomes vary by region, merchant category and reason code.
Anyone making a decision that depends on these rules should verify the current position with their acquirer or processor and, where the stakes justify it, consult a qualified payments counsel or compliance advisor. Where this article states a rule, date or threshold, treat it as a description of the general framework as of August 2026 and confirm the current figure at the official source before relying on it.
FAQ on EMV liability in store
Is the EMV liability shift a law?
No. It is a set of private operating rules published by the card networks and applied through acquiring agreements. There is no US federal statute that assigns in-store counterfeit fraud liability in this way, which is why the details differ between networks and can change without legislation.
Does a contactless tap carry the same protection as inserting the chip?
Generally yes. Contactless uses the same chip cryptography over a radio interface rather than static stripe data, so a completed tap is treated as a chip transaction for counterfeit liability purposes under the major network rules. Wallet taps add tokenization on top of that.
What exactly is a fallback transaction?
It is a magnetic stripe swipe that happens after the terminal attempted a chip read and failed. The authorization message carries an indicator showing the chip was tried, and under most network rules the transaction generally does not receive chip liability protection.
Can we simply refuse fallback transactions?
Some merchants configure terminals to decline or limit fallback, particularly above a value threshold. Whether this is permitted and how it should be implemented depends on your acquirer, your processor configuration and the applicable network rules, so it is a conversation to have with your acquirer rather than a setting to change unilaterally.
Who pays when a card is lost or stolen rather than counterfeit?
Lost and stolen disputes follow different reason codes from counterfeit ones and turn largely on cardholder verification rather than on how the card was read. A chip read alone does not resolve them, which is one reason PIN and wallet biometric verification matter separately from chip acceptance.
Does buy online, pick up in store count as a card-present transaction?
Usually not. If the card details were entered online, the transaction is card-not-present for liability purposes even though the goods were handed over physically. The evidence that supports a dispute in that channel is pickup verification and timestamps rather than terminal read data.
How high should our fallback rate be before we worry?
There is no universal number, and acquirers apply their own monitoring thresholds. The more useful practice is to baseline your own rate per lane, then investigate any lane or store that drifts materially above that baseline, since relative movement identifies failing hardware faster than an industry average would.
Does being PCI DSS compliant mean we are covered for fraud liability?
No. PCI DSS governs how cardholder data is secured, while fraud liability is allocated by the network operating rules based on transaction data. A merchant can be fully PCI compliant and still absorb counterfeit losses because chip reads are failing at the register.
Where can we confirm the current rules for our business?
Start with your acquirer or processor, who can tell you which network rules apply to your merchant category and what your current fallback and dispute rates look like. The networks publish their own operating regulations, and EMVCo publishes the underlying technical specifications, but the acquirer relationship is where the commercial terms actually live.