Visa 10.2 Chargeback: EMV Liability Shift — Non-Counterfeit Fraud

Map the payment path from card read to authorization

Start with terminal ID, entry mode, chip/contactless record, cardholder-verification result where retained, authorization response, and transaction reference. Put them in time order and confirm they all refer to the same disputed sale.

If the system contains multiple attempts, show each attempt separately. A failed chip read followed by swipe, fallback, or manual entry can materially change the analysis, and an order-level 'paid' badge may hide that sequence.

Keep verification results precise

Where the merchant retains a cardholder-verification method or result, present the actual field and its meaning according to processor documentation. Do not convert a PIN, signature, no-CVM, or other indicator into a claim that the named cardholder personally made the purchase.

Verification data can strengthen the transaction story when combined with chip and authorization records, but it remains one component. The submission should distinguish what the terminal proves from what the merchant merely infers.

Check processor liability indicators

Many merchants see liability or authentication indicators in the processor dashboard. Capture the original value and the provider's explanation. If the indicator is missing, contradictory, or not documented, escalate internally before building a strong liability claim around it.

Do not reuse a liability screenshot from another transaction or assume all chip transactions receive the same treatment. The disputed transaction's data and current rule set are what matter.

Use supporting purchase evidence sparingly

An itemized receipt, signed service record, loyalty account, or pickup record can help identify the commercial event, especially when the processor case asks for supporting context. Keep these exhibits after the technical payment records so the logic remains clear.

Prior legitimate purchases may provide context but are not a substitute for the disputed transaction's EMV evidence. If used, explain exactly what continuity they show and avoid stating that similar behavior proves the same person used the card.

Look for configuration inconsistencies

Compare terminal capability with the transaction entry mode and any fallback indicators. If a chip-capable terminal repeatedly records unexpected swipe or keyed transactions, investigate device health, software, staff behavior, or routing before treating every dispute as customer fraud.

A second reviewer should be able to reproduce the merchant's conclusion from the raw fields. If the conclusion depends on an undocumented assumption, either obtain the missing processor explanation or soften the claim.

Close with a current-rule check

Build the cover note around the actual processing facts and cite the corresponding exhibits. Then compare the packet with current Visa merchant dispute materials and the processor's live action options before filing.

Keep the outcome with the terminal and processor data. Over time, 10.2 cases can become a useful control signal for terminal configuration and transaction-path quality, not just a dispute win/loss metric.

Example: contactless transaction with no-CVM result

A Visa 10.2 case shows contactless processing with a no-CVM result under the transaction conditions. The merchant should report the terminal and verification fields exactly as recorded, without converting 'no CVM' into a statement that the cardholder was unverified in a broader sense.

Pair the transaction result with authorization and processor liability indicators. The technical record should be interpreted through current Visa/processor documentation, not assumptions about what a customer should have done at the terminal.

Interpret non-counterfeit EMV cases from the exact verification path

Visa 10.2 should be reconstructed from card read through authorization. Preserve entry mode, contact/contactless path, cardholder verification result where available, terminal capability, authorization, and any processor liability indicator. Non-counterfeit fraud can involve stolen or otherwise misused genuine cards, so the technical question is not identical to counterfeit fallback. Keep the transaction-specific provider record intact rather than applying a generic 'chip used = protected' rule.

Contactless and no-CVM transactions deserve precise wording. A no-CVM result can be normal for certain transactions under network and terminal rules, but it should not be presented as proof that the cardholder verified identity. If PIN, signature, device authentication, or another method was used, state exactly what the record shows. The merchant's evidence should explain the observed verification path without implying stronger authentication than occurred.

Check processor liability information against the live case. Liability can depend on multiple transaction attributes and current rules, and processor dashboards may expose a specific shift or protection status. Preserve that status and its underlying transaction identifiers. If the provider does not show a clear liability result, escalate internally or to the processor rather than inserting an assumed conclusion into the response.

Use losses to inspect terminal configuration. Review contactless limits, CVM configuration, manual overrides, fallback, terminal certification, and transaction routes that unexpectedly bypass the normal chip path. Segment by location and device. A payment stack that produces inconsistent verification records will create both fraud exposure and weak dispute evidence, so the remediation belongs with payments operations as much as with the dispute team.

Separate card-present verification from post-purchase customer recognition

A customer may later recognize the purchase after initially reporting fraud, or may continue to deny it despite a normal chip/contactless path. Preserve any later customer communication, but do not let it rewrite the technical record. The transaction should still be documented with the actual entry and verification method.

Conversely, a normal terminal path does not prove the customer knowingly authorized the purchase if the card was stolen or misused. Internal decisions should consider both payment controls and customer evidence without allowing either to become an absolute identity claim.

Review card-present high-risk products separately from ordinary store traffic

Lost or misused genuine cards may concentrate in easily resold, high-value merchandise. Segment 10.2 exposure by product category, amount, location, and transaction path. A store may have normal contactless performance overall while one high-risk SKU generates disproportionate fraud. Operational controls can then be targeted—additional verification, staff review, or pickup restrictions—without imposing the same friction on every customer. The dispute code becomes a signal for merchandising risk as well as terminal behavior.

EMV liability analysis should stay tied to the actual transaction path. Preserve terminal capability, chip-read or fallback indicators, entry mode, cardholder-verification method where available, and the processor's transaction record. Do not infer the payment path from a paper receipt or from the terminal model alone. If fallback occurred, document why and whether the terminal or chip was reported as failing. If staff keyed the card after a failed read, keep that event visible rather than presenting the sale as an ordinary chip transaction. These details matter because the dispute is about the transaction's authentication and liability context, not the fact that the customer later received merchandise. Fulfillment evidence may still be useful background, but it should not replace the payment-path evidence that the reason code calls into question.