Sep 2, 2026

EMV Liability Shift: Who Pays When a Card-Present Transaction Is Disputed?

Chargebacks?
Dat is niet langer jouw probleem.

Haal 4x meer chargebacks terug en voorkom tot 90% van de inkomende betalingen, dankzij AI en een wereldwijd netwerk van 20.000 handelaren.

Meer dan 600 beoordelingen

gratis beginnen

Geen creditcard nodig.

TL;DR:

EMV liability depends on the actual transaction and applicable network rule, not terminal ownership alone.
Separate counterfeit fraud, lost or stolen cards, contactless payments, and technical fallback.
Use acquirer records to verify entry method, verification results, and transmitted chip data.
Fraud liability protection does not eliminate delivery or product-quality disputes.

Ontdek met AI

Openen in ChatGPT

Openen in Claude

Openen in Gemini

Google - Aanbevolen bron

The EMV liability shift is a set of card-network rules that assigns responsibility for eligible card-present fraud based on the card, terminal, verification method, and transaction data. It is not a guarantee that every chip or contactless payment is protected from every chargeback.

Use the rule that applies to the actual transaction and dispute reason. Owning a chip reader, receiving an authorization approval, and qualifying for liability protection are different facts.

Assess Liability by Transaction Scenario

Scenario	What to establish	What not to assume
Contact chip transaction	Whether chip data and required verification were processed correctly.	A chip-capable terminal proves the disputed sale was chip-read.
Contactless card or wallet	The recorded entry method, authentication data, and applicable program.	Every tap protects against every claim.
Technical fallback	Why chip processing failed and how fallback was identified to the network.	Every fallback has the same liability result.
Lost or stolen genuine card	The applicable verification and non-counterfeit fraud rules.	Counterfeit-card rules answer the case.
Online purchase	The relevant remote authentication or token program.	In-store chip protection automatically extends online.
Delivery or product complaint	Evidence addressing fulfillment or the product description.	Fraud liability protection defeats a service complaint.

The card-present fraud guide covers store operations; the counterfeit-card guide focuses on copied credentials and terminal investigations.

Read the Network Condition Before Choosing Evidence

Visa’s public merchant guide separates counterfeit EMV fraud under condition 10.1 from non-counterfeit EMV fraud under 10.2. Its 10.1 response guidance calls for evidence of chip reading and transmission of the required data when that is the merchant’s defense. See the Visa merchant dispute guidelines.

Mastercard’s public guide contains transaction-specific exclusions and technical-fallback provisions. That is why a universal “swipe means merchant always pays” rule is unreliable. Have your acquirer check the applicable condition and submitted transaction data against the Mastercard chargeback guide.

Public guides explain the framework. Your acquirer should confirm the current rules for the transaction’s network, region, and processing date before you accept a liability conclusion.

Collect Evidence About the Disputed Sale

Follow the current case and provider requirements

Build a transaction-specific EMV evidence record

Case and payment

Case and payment references, disputed amount, and merchant response deadline.

Terminal and entry method

Terminal identifier and the transaction’s recorded entry method.

Authorization and clearing

Authorization and clearing records available through the acquirer.

Verification and chip data

Cardholder verification result and relevant chip-data confirmation.

Fallback and service records

Fallback flags, terminal error records, and related service tickets when applicable.

Completed refund or reversal

Any completed refund or reversal linked to the payment.

Ask the acquirer to explain missing or inconsistent data rather than attempting to reconstruct it from a receipt. Do not add sensitive authentication data to an ordinary support ticket. Organize permitted records using a standard evidence structure.

Keep Chip Security Separate From Remote Authentication

EMVCo describes chip technology as part of a layered approach to reducing fraud, with different supported cardholder verification methods. See its EMV chip explanation. The technology makes counterfeit use harder; it does not eliminate every form of payment fraud.

Online 3D Secure and wallet programs have their own eligibility conditions. Review Apple Pay chargeback rules or Google Pay chargeback rules when a wallet is involved. Do not apply an in-store scenario table to an ecommerce sale.

Fix the Processing Cause Alongside the Case

If records reveal unexpected fallback or incomplete chip data, give the terminal or integration issue a separate owner. Correcting future processing does not retrospectively change the disputed transaction. Likewise, buying a new terminal is not evidence that the old sale qualified.

Use chargeback representment when the case permits a response and the records support it. You can connect supported evidence workflows through Chargeflow’s automated recovery.

Continue learning: In-store fraud and liability

Use In-Store Fraud and EMV Liability: Merchant Guides to choose the next merchant task in this topic.

Sources and scope

Source notes updated: October 11, 2026. In-store card payments. EMVCo explains the technology; it does not decide a particular chargeback. Use the network’s applicable regional rules and the acquirer’s case instructions for liability, and preserve terminal entry-mode and fallback records.

For a live case, retain the governing document’s edition or effective date, the relevant provision, and the provider notice.

Veelgestelde vragen

Does the EMV liability shift cover every chargeback?

The EMV liability shift applies to eligible fraud scenarios under card-network rules. It does not automatically resolve delivery, quality, cancellation, or other consumer disputes.

Does technical fallback always make the merchant liable?

Technical fallback does not have one universal liability outcome. The network, transaction coding, reason for fallback, and applicable dispute conditions must be checked with the acquirer.

Does an approval code prove EMV protection?

An approval code does not by itself prove EMV liability protection. Review the actual entry method, verification result, required transaction data, and applicable network rule.