Network rules and reason codes
Visa Compelling Evidence 3.0: Verify Eligibility Before Building the Case
Verify Visa Compelling Evidence 3.0 eligibility before assembling prior-purchase records. CE 3.0 is a condition-specific evidence route with defined transaction-history and matching-data requirements. A repeat customer, a familiar address or several successful orders does not automatically qualify a dispute.
Start with the actual network condition and processor support. Confirm that the case remains actionable and that your provider can submit the qualifying data through its supported workflow. A merchant-created PDF labeled “CE 3.0” does not establish that the provider will process it as such.
Confirm the eligible condition and implementation
Identify the Visa transaction and the raw reason code from the processor. Then ask which CE 3.0 route the provider supports for that account and case. Do not assume that capabilities documented for an independent Stripe account apply to Shopify Payments.
Stripe’s documented implementation identifies Visa reason 10.4 and requires qualifying prior paid, undisputed transactions using the same payment method. Its current page also specifies the supported historical window and matching-data combinations. Those are Stripe workflow requirements, not permission to infer eligibility across every processor. Stripe’s CE 3.0 documentation
Check the effective Visa rules as well as the processor’s implementation. Record the edition and any future-effective provision separately from requirements already in force. The public rules checked on 6 September 2026 include dated provisions, so the publication date of an article cannot replace the applicable rule date. Visa’s public rules
Validate the prior transactions
For each candidate prior transaction, retain its payment reference, processing date, status and documented link to the relevant payment method. An account-level order history is not enough if it does not establish the required payment relationship.
Check whether the transaction is genuinely qualifying rather than a validation charge, an unpaid attempt or a record whose dispute status is unknown. Ask the processor which source establishes that status and which date fields its eligibility calculation uses.
Do not choose transactions solely because they share favorable identifiers. Apply the history requirements first, then evaluate the matching data. Keep rejected candidates and their reasons in an internal worksheet so the team can explain why only certain records were used.
Where the provider’s documented window differs in expression from the network rule, ask how its system applies the rule for the case. Do not silently substitute one reference date for another or generalize a processor’s simplified eligibility flag.
Check matching elements precisely
The documented Stripe implementation requires a supported combination across the disputed transaction and both prior transactions, including an IP or device element. It does not treat device ID and device fingerprint as two independent qualifying elements. Confirm the exact current combination with the provider. Stripe’s matching-element requirements
Use original recorded values and documented field meanings. A normalized account label, a city estimate or a manually inferred device match may not satisfy the required element. If an identifier was transformed, preserve the source and ask the provider whether that representation is accepted.
Missing data is a real eligibility issue. Do not create a device identifier retrospectively from a browser description or treat a later address update as the historical transaction address. The evidence must reflect what the relevant records establish.
A hypothetical eligibility screen
A hypothetical merchant has a Visa fraud dispute and three previous orders from the same account. One previous order used a different payment method. Another falls outside the provider-confirmed qualifying period. The remaining order matches the required identifiers but provides only one qualifying prior transaction.
The merchant should not label the case CE 3.0 eligible because there are three repeat purchases. The qualifying set is insufficient under the provider’s requirements. The team can still assess other permitted evidence routes, but it must not describe generic account history as a completed CE 3.0 submission.
Use this worksheet:
| Gate | Evidence needed | Result to record |
|---|---|---|
| Network and condition | Processor reason record | Verified or unresolved |
| Provider support | Account-specific route | Supported or unavailable |
| Prior payment relationship | Processor linkage | Qualifying or rejected |
| History period and status | Required dates and status records | Meets rule or fails |
| Matching elements | Accepted original fields | Complete or missing |
| Submission treatment | Provider confirmation | CE route or ordinary evidence |
Each failed gate should identify the reason and the next legitimate action. A failed eligibility check is not a reason to manufacture missing history.
Confirm the final submission treatment
Before relying on CE 3.0, ask the provider to confirm that the supplied data is complete and will be submitted through the intended route. A dashboard flag may indicate potential eligibility while required fields remain missing.
Retain the qualification worksheet, source references and provider confirmation. Keep the ordinary factual response accurate and relevant to the current fraud allegation. Do not claim that qualifying evidence proves product delivery or defeats unrelated consumer complaints.
CE 3.0 preparation is successful when the merchant can show the eligible condition, qualifying history, accepted matching data and supported processor treatment. If one of those elements is absent, describe the case accordingly and use only the response options the provider confirms. Eligibility should be established from the records and current rules, not from the persuasive title placed on the packet.
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
- Visa Invalid Data Disputes: Which Clearing Fields Must Your Processor Verify?
- Shopify POS Chargebacks: When EMV Counterfeit Liability Shift Applies