Network rules and reason codes
Fraud Liability Shift Is Not a Defense to Every Chargeback Reason
A fraud liability shift is relevant only when the disputed transaction and allegation fall within its applicable conditions. It does not establish that goods arrived, that a product matched its description or that a recurring charge complied with a cancellation request.
Begin with the current dispute reason and the processor’s transaction-specific protection or authentication record. Do not treat a store setting, an app badge or the fact that authentication was attempted as a blanket defense to every case.
Separate authentication from the disputed obligation
Authentication addresses a payment-related question. Fulfillment, quality, cancellation and credit processing concern different merchant obligations. The same transaction can have a qualifying authentication event while the customer has a separate, potentially valid complaint about what the merchant supplied.
Stripe describes 3D Secure as an authentication mechanism. The transaction’s actual outcome and the applicable fraud treatment still require the processor’s records and rules. Stripe’s 3D Secure documentation
Avoid using “protected” as an undefined label in the response. Ask protected against what, under which program or rule, for which payment and subject to which conditions. A commercial guarantee, an authentication-based liability rule and a provider’s recovery service are different arrangements.
The evidence should identify the relevant record and its meaning. If the case concerns product condition, that record may be background rather than the decisive defense.
Verify the reason before relying on the shift
Read the raw network condition and issuer allegation where available. A broad fraud label should be confirmed against the actual case. If the allegation changes at a later stage, reassess the role of the authentication evidence.
Ask the processor to confirm whether the transaction meets the relevant liability conditions and whether an exception applies. A successful payment is not the same as successful authentication, and a successful authentication record is not by itself a complete statement of liability.
The Visa public rules distinguish fraud conditions from consumer-dispute conditions. That separation is the starting point for checking the scope of a proposed defense. Visa’s public rules
Do not independently infer eligibility from a customer’s recollection of a challenge screen. Use the processor’s linked transaction record and its case-specific interpretation.
Use a defense-boundary matrix
| Current allegation | What authentication may address | What still needs separate evidence |
|---|---|---|
| Unauthorized participation | Relevant fraud treatment, if qualifying | Exact transaction linkage and exceptions |
| Product not received | Payment context | Supply of the disputed goods or service |
| Product not as described | Payment context | Applicable description and item facts |
| Charge after cancellation | Payment context | Cancellation and billing circumstances |
| Credit not processed | Payment context | Credit obligation and processing record |
The matrix does not decide a case. It prevents a merchant from using authentication to answer a question it did not measure. The applicable condition and processor instructions remain controlling for the response.
If the merchant also has a contractual guarantee, evaluate that separately. The guarantee might reimburse specified losses under its own terms, but it should not be described as a network liability shift or assumed to cover every category in the table.
A hypothetical authenticated defective-item claim
A hypothetical merchant has a payment record showing successful authentication. The customer disputes the purchase because a delivered appliance did not perform the advertised function. The merchant’s first draft says the transaction is protected and therefore the chargeback must be reversed.
That argument does not address the allegation. The merchant asks the processor to confirm the reason and reviews the applicable listing, the item supplied and the customer’s documented report. The authentication record remains part of the payment history, but it does not prove the appliance worked.
If the evidence shows the merchant supplied the wrong model, the authentication event does not cure the fulfillment error. If the merchant has a supported product-specific defense, it should present that evidence directly rather than relying on a fraud-related label.
The same boundary applies when a customer acknowledges the purchase but disputes a later renewal. The earlier authentication record does not establish that the renewal was permitted after cancellation.
Record the scope of the provider’s confirmation
Use a short internal note:
Payment: [reference]. Current allegation and condition: [verified values]. Authentication or protection record: [source]. Provider-confirmed treatment: [specific scope]. Conditions and exceptions checked: [details]. Facts outside that scope: [delivery, quality, cancellation or other issue]. Response plan: [evidence addressing the actual allegation].
Keep the provider’s wording and date. A general support article is useful context, but a case-specific question may require a transaction-specific answer. If the provider cannot confirm a material condition, record it as unresolved.
Do not claim that winning a fraud-related case erases every record of the dispute or guarantees protection for future orders. The present task is to establish the scope of the current defense, not to draw broader conclusions about monitoring or account status.
Before submission, remove any sentence that jumps from “authenticated” to “all merchant obligations fulfilled.” A precise response shows what the payment record establishes and supplies separate evidence for the customer’s actual complaint. Liability shift can be a meaningful protection within its boundaries; respecting those boundaries is what makes the merchant’s argument credible.
Explore the Provider Hub if you need help preparing or defending a dispute; confirm the provider supports your processor and case type.
Related reading in this collection:
- Shopify Dispute Labels vs Card-Network Reason Codes: Build a Useful Crosswalk
- Why Chargeback Alerts Alone Do Not Address VAMP Enumeration Monitoring
- Must the Customer Contact the Merchant Before Filing a Chargeback?