Visa condition 10.1 addresses EMV liability-shift counterfeit fraud. This is a payment-technology dispute, so the merchant should focus on chip/EMV transaction data, terminal capability, entry mode, authorization result, and the liability indicators exposed by its processor. Generic proof that the customer received goods is usually secondary to the way the transaction was processed.
Liability-shift rules are technical and can vary with transaction details, product, geography, and current network rules. This guide therefore focuses on organizing the merchant record; the live processor case and current Visa documentation must be used for the actual eligibility decision.
Confirm the terminal was capable of the transaction it claims
Retrieve the terminal identifier, configuration or capability data available to the merchant, and the transaction's entry mode. The case file should show whether the payment was processed as a chip transaction, contactless transaction, fallback, swipe, or keyed event rather than relying on a staff recollection.
If the merchant upgraded terminals or configurations around the transaction date, use the record that applied on that date. A current screenshot of terminal settings may not prove how the device was configured when the disputed sale occurred.
Preserve chip and authorization fields together
Export the chip/EMV data and authorization response available through the processor or terminal system. Keep the transaction identifier, amount, timestamp, and merchant location with those records so the reviewer can link them to the disputed posting.
Do not translate a complex processor field into a stronger claim than the documentation supports. If the processor shows a liability indicator, present the original value and any processor explanation rather than paraphrasing it as 'merchant protected.'
Investigate fallback and manual entry
Fallback, swipe, and keyed transactions deserve separate review because they can change the factual picture. Identify why the terminal did not complete a chip read if the system records the reason, and preserve any error or fallback indicators.
Avoid guessing that a damaged card, customer behavior, or terminal fault caused fallback. If the merchant cannot prove the cause, state only the processing path that the logs show. The strength of the file comes from accurate technical records, not speculation.
Keep fulfillment evidence in the right role
A receipt, itemized order, signed pickup, or delivery record can show the commercial transaction occurred, but it does not replace EMV processing evidence in a liability-shift dispute. Include fulfillment only when it helps identify the sale or the processor specifically makes it relevant.
The cover note should lead with the chip/terminal facts. Putting a shipping screenshot first can signal that the merchant is answering a non-receipt or fraud narrative instead of the technical condition behind the case.
Red-team the technical record before contesting
Check whether terminal entry mode, chip fields, authorization status, and processor liability indicators agree. If one system says chip and another says manual entry, resolve the discrepancy before submission. Preserve raw exports so annotations can be checked against the source.
If the merchant's configuration or processing path appears to have created liability, document that internally and review other transactions from the same terminal population. A weak technical case rarely improves by adding unrelated customer-profile evidence.
Use 10.1 cases to audit EMV operations
Trend these disputes by terminal, store, acquirer route, fallback rate, and software version where the merchant can lawfully and practically do so. A cluster can reveal hardware, certification, training, or integration issues.
Before implementing a rule change, use current Visa and processor documentation. Network liability rules evolve, so an old internal playbook should never be treated as the source of truth for a new case.
Example: chip terminal, magnetic-stripe fallback
A store's device is chip-capable, but the disputed Visa 10.1 transaction records fallback to magnetic stripe after repeated read failures. The merchant should not submit only a photo of the EMV terminal and claim chip protection. The actual entry-mode and fallback indicators are what matter.
Review whether the fallback path was expected, whether the processor shows a liability indicator, and whether the terminal has a pattern of read failures. A single dispute can reveal a hardware or configuration problem affecting many transactions.
Audit EMV capability, entry mode, and fallback as one technical control
For Visa 10.1, the terminal record should establish whether the device was chip capable, how the card was actually read, what verification occurred, and how the issuer authorized the transaction. Preserve terminal ID, entry mode, chip/fallback indicators available from the processor, authorization response, amount, and settlement reference. A merchant should not assume that owning a chip-capable terminal is enough; the disputed transaction must show the relevant path.
Fallback needs an explanation. Magnetic-stripe fallback can be legitimate when a chip cannot be read, but a high fallback rate may indicate device problems, staff behavior, or fraud exposure. Review whether the terminal attempted chip first, whether the device logged an error, and whether manual entry occurred instead. Do not manufacture technical certainty from a receipt line. Use the processor's human-readable transaction details and current Visa/acquirer guidance for liability treatment.
Keep commercial evidence in a supporting role. Receipt, goods, service, or camera records where lawfully retained can show that a sale occurred, but a counterfeit-fraud liability question is primarily about the payment technology path. A delivered product does not change the entry mode. If the payment record itself is weak or inconsistent, a thick fulfillment appendix should not create false confidence.
After the case, audit terminal health and staff procedures. Track fallback, keyed transactions, chip-read errors, terminal firmware or replacement history, and store-level concentration. If one location generates a disproportionate number of 10.1 disputes, inspect hardware and training. EMV disputes are a payment-operations signal; reducing the questionable transaction paths is more sustainable than repeatedly defending them.
Compare disputed EMV paths with normal transactions from the same terminal
Pull a small sample of successful, undisputed transactions from the same terminal and period to see the normal entry mode and chip data. If the disputed event is the only keyed or fallback transaction on an otherwise healthy device, investigate that exception. If the terminal shows widespread fallback, the issue may be hardware or configuration rather than one unusual customer.
This comparison belongs mainly in the internal control review, not necessarily the external packet. It helps the merchant decide whether the disputed transaction reflects a genuine exception, a systemic device problem, or staff behavior that needs correction.
Document terminal software and configuration version for disputed chip events
Two terminals with identical hardware can behave differently after software or configuration changes. Preserve application version, configuration profile, and device maintenance history when a 10.1 case exposes unusual fallback or entry mode. If several disputes start after a rollout, compare affected devices with the previous version. This technical context is mainly an internal diagnostic, but it can explain why a transaction path suddenly differs from historical behavior and helps the merchant fix the source rather than treating each case as isolated fraud.
VERIFY CURRENT RULES
Primary references
Processor interfaces, reason-code mappings, filing windows, and network rules can change. Check the active dispute notice and current official documentation before submitting.