# Visa Compelling Evidence 3.0 for SaaS: check the actual match

[By Evidenz](https://evidenz.dev/)  4 min read

Visa Compelling Evidence 3.0 is a specific route for qualifying card-absent fraud disputes, not a general name for strong chargeback evidence. A SaaS team needs the provider-confirmed transaction history, required matching data, and the rules applicable to the dispute processing date. Two earlier invoices or repeated logins do not establish eligibility by themselves.

## When is CE3.0 the relevant evidence route?

Start with the network reason code and the provider's eligibility result. Visa CE3.0 concerns qualifying 10.4 card-absent fraud disputes. A cancellation, service-quality, or missing-refund complaint needs an investigation that answers that allegation, even if the customer has a long payment history.

[Stripe documents automatic eligibility evaluation and required-field indicators for its CE3.0 response flow.](https://docs.stripe.com/disputes/best-practices) Use the actual case result and requested fields. Do not infer eligibility from a customer email match, successful payment, or generic “fraudulent” label.

For B2C SaaS, the account might belong to one subscriber. For B2B SaaS, the payer, company workspace, administrator, and member using the service may differ. A useful internal account relationship is not automatically the same thing as a network-accepted match.

## Which date and historical transactions matter?

[Visa's April 2026 rules set date-dependent requirements for the historical-payment route under condition 10.4.](https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf) The ordinary purchase-history route uses two prior non-fraud transactions, more than 120 and no more than 365 days before dispute processing, with qualifying matching data. Exceptions and the provider's supported route must be checked on the case.

The clock is not simply “the previous four monthly renewals.” Preserve the dispute processing date, transaction dates, payment-credential relationship, and provider's selected qualifying records. An invoice without a completed qualifying payment does not replace a historical transaction.

## What changes on October 24, 2026?

Visa's published rules expand the route for disputes processed on or after October 24, 2026 to qualifying history at one or more merchants, limited to transactions processed by the submitting acquirer. They also clarify that device ID and device fingerprint count as similar elements, so both cannot fill two separate matching slots.

That does not establish access to other merchants' records in your account or in Evidenz. Ask your provider how the effective-date change is supported for the actual dispute. Keep the rule version and provider result with the review.

## Keep the comparison tied to original records

Build an internal comparison before writing an argument. Each value needs a source, relevant timestamp, transaction association, and meaning. Do not alter a value to make it resemble the other transactions.

Internal CE3.0 preparation worksheet; the provider determines qualification

| Review item | What the reviewer needs | A SaaS mistake to catch |
| --- | --- | --- |
| Case and rule version | Network code, dispute processing date, provider eligibility, and applicable instructions. | Applying a future rule to an older case or treating an unsupported flow as available. |
| Three transaction records | The disputed payment and the two provider-verified historical payments. | Using invoices, failed renewals, or two captures of the same event as interchangeable history. |
| Payment relationship | The provider-verified card or related credential association for the route. | Matching only the last four digits or customer email. |
| Required matching elements | The qualifying device or IP element and an additional accepted match, with original sources. | Counting device ID and fingerprint as independent matches or substituting an unrelated workspace ID. |
| Service description | What the disputed payment and earlier payments purchased. | Using today’s plan description for a different historical product. |
| Provider submission | Required form fields, pre-populated values, review approval, and final confirmation. | Assuming an internal worksheet has been filed with the issuer. |

A match needs interpretation. A public IP can be shared. A device identifier can change. An internal organization key might identify the billed company without identifying the person who authenticated. Record these distinctions instead of writing “same customer” over several different relationships.

The [identity-resolution guide](https://evidenz.dev/articles/customer-identity-resolution) explains the underlying account-to-payment work. Keep only the records needed for the investigation and use the provider's requested format rather than a homemade substitute.

## A recurring-payment example

**Fictional preparation example.** A subscription team sees a fraud dispute for an October payment. Its system also contains completed April and May payments, a consistent account login identifier, and a device record. The team can prepare a comparison, but those observations do not constitute a CE3.0 eligibility result.

The reviewer still needs the provider to verify the relevant credential, historical transaction status, date window, and accepted matching elements. A failed May collection or a device associated with another workspace changes the worksheet. Preserve the gap rather than filling it with a plausible-looking value.

If the complaint is instead that support promised to cancel the October renewal, review that promise. The [sample evidence packet](https://evidenz.dev/articles/sample-chargeback-evidence-packet) shows why account activity can coexist with a valid cancellation complaint. CE3.0 preparation should not obscure the question the case actually asks.

## What does Stripe handle, and what should the team review?

[Stripe describes identifying qualifying history and pre-populating CE3.0 evidence fields.](https://docs.stripe.com/disputes/best-practices) The team's useful work is to check the service description, source relationships, requested missing information, and factual completeness of the case explanation.

[Stripe's response guide says not to edit pre-populated required CE3.0 values because doing so can affect eligibility.](https://docs.stripe.com/disputes/responding) Investigate an apparent error through the provider's supported process. Keep the reviewed submission and confirmation separately from an internal draft.

## Evidenz's role in this investigation

Evidenz is being developed to connect payments, account activity, and support conversations for B2B and B2C SaaS teams. Its intended workflow helps explain which activity belongs to which payment and gives a reviewer source context for a draft.

That direction is not a certification of Visa eligibility, access to cross-merchant history, or a promise that a dispute will be overturned. Use the provider's case instructions for qualification and submission, and the customer history to make the account of events accurate.

## Sources and scope

Sources checked October 2026

Published by Evidenz. Examples are illustrative, not customer results. Check current requirements and the actual case against the linked sources.

- [Visa: Core Rules and Product and Service Rules, 18 April 2026](https://usa.visa.com/content/dam/VCOM/download/about-visa/visa-rules-public.pdf)
- [Stripe: Compelling evidence for Visa disputes](https://docs.stripe.com/disputes/best-practices)
- [Stripe: Respond to disputes](https://docs.stripe.com/disputes/responding)

Customer context is our starting point.

Evidenz is being built for B2B and B2C SaaS: a shared customer history across subscription billing, accounts, support, and digital product activity. Join the waitlist for early-access news.

[Join the waitlist](https://evidenz.dev/#hero)

## Keep reading

[4 min read

### Chargeback reason codes: match the claim to SaaS evidence](https://evidenz.dev/articles/chargeback-reason-codes)[5 min read

### Chargeback evidence for subscription businesses](https://evidenz.dev/articles/chargeback-evidence)[5 min read

### Customer identity resolution for subscription investigations](https://evidenz.dev/articles/customer-identity-resolution)[4 min read

### 3D Secure and chargebacks: what authentication does and does not prove](https://evidenz.dev/articles/three-d-secure-and-disputes)

Canonical page: https://evidenz.dev/articles/visa-compelling-evidence-3