Compelling Evidence: What Visa Actually Accepts
Compelling evidence is a defined list, not anything persuasive you hold. Here is what qualifies per condition, and the formats that get files rejected.
By Jeffrey Anderson
- Compelling evidence is a closed list in section 11.5.1 of the Visa rules, organised by dispute condition. Documentation outside that list does not qualify however persuasive it looks.
- Where you hold an AVS match of Y or M for the delivery address, the rules say a signature is not required as evidence of delivery. Merchants lose cases assuming otherwise.
- For digital goods you need a description, the download date, and two or more identifiers such as IP address, device ID, a verified customer profile, or an undisputed transaction from the same device and credential.
- Compelling Evidence 3.0 needs two previous undisputed transactions processed more than 120 calendar days before the dispute was submitted and no more than 365 days before its processing date.
- Only the device fingerprint may be hashed. Login ID, full delivery address, device ID and IP address must all be supplied in clear text, which is a systems design decision rather than a dispute-time one.
- Device ID and device fingerprint count as similar elements and may not both be submitted. Sending both wastes a slot you needed for a different data point.
- From 24 October 2026 the two previous transactions may come from one or more merchants rather than only your own, but an acquirer may only submit data it accepted and processed itself.
Compelling evidence isn't whatever you can dig up. It's a defined list in the Visa rules, organised by dispute condition, and anything outside that list isn't compelling evidence no matter how convincing it looks to you.
Table 11-6 in the Visa Core Rules and Visa Product and Service Rules (18 April 2026) sets out what qualifies. Table 11-31 adds a separate, much more prescriptive route for card-absent fraud. Both are worth knowing line by line, because the most common reason a good case fails is that the file didn't match the format the rules require.
We've covered how representment works and the fact that compelling evidence doesn't oblige anyone to rule your way. This is the other half: what specifically counts.
What Qualifies, By Dispute Condition
Section 11.5.1 lists allowable compelling evidence against three fraud conditions: 10.1 (EMV liability shift counterfeit fraud), 10.3 (other fraud, card-present) and 10.4 (other fraud, card-absent). Most of the list attaches to 10.4, which is where card-not-present merchants live.
| # | What counts |
|---|---|
| 1 | Photographic or email evidence linking the recipient to the cardholder, or showing the cardholder possesses or is using the merchandise |
| 2 | For goods collected in person: cardholder signature on the pick-up form, a copy of the identification presented, or details of it |
| 3 | For delivered goods: evidence of delivery to the same address for which you received an AVS match of Y or M |
| 4 | For digital goods sold online: a description, the download date, and two or more identifying data points |
| 5 | For delivery to a business address: evidence of delivery plus evidence the cardholder worked there at the time |
| 6 | For a mail or phone order: a signed order form |
| 7 | For passenger transport: evidence services were provided, plus a ticket, boarding pass scan, frequent flyer detail or related purchase |
| 8 | For a travel and entertainment transaction: evidence services were provided, plus loyalty detail or an undisputed related transaction |
Item 3 deserves a second look. If you have an AVS match of Y or M and you delivered to that address, the rules say a signature is not required as evidence of delivery. Merchants routinely lose cases because they assumed they needed a signature they never collected.
The Digital Goods Rule
Item 4 is the one that matters for software, subscriptions and anything downloadable, and it's specific.
You supply a description of the merchandise or services, the date it was downloaded, and two or more of the following: the IP address, the device ID, the purchaser's name and email address linked to a customer profile you hold, evidence the profile was accessed and verified before the transaction date, evidence your site or app was accessed by the cardholder on or after the transaction date, or evidence the same device and payment credential were used in an undisputed transaction.
Two or more. Not one strong item. If you sell digital goods, that list is effectively a specification for what your logging has to capture, and the time to build it is before a dispute, not during one.
Compelling Evidence 3.0 For Card-Absent Fraud
There's a second, separate route for condition 10.4 in Table 11-31, usually called Compelling Evidence 3.0. It's built on transaction history rather than delivery proof.
The idea is that if the same payment credential was used in two previous transactions the issuer never reported as fraud, the cardholder has a relationship with you that undercuts a claim of pure fraud.
The conditions are exact:
- Those previous transactions must have been processed more than 120 calendar days before the dispute was submitted
- And not more than 365 calendar days before the dispute's processing date
- You supply a detailed description of the merchandise or services for the disputed transaction and both previous ones
- You certify the date the merchandise or services were provided
- The device ID or fingerprint, or the IP address, must match, plus at least one more matching element
One footnote is worth knowing if you run payouts: the 120 day requirement doesn't apply where the other undisputed transactions were original credit transactions.
The Formatting Rules That Get Files Rejected
This is where good cases die, and it's all in the footnotes.
| Element | Requirement |
|---|---|
| Customer account or login ID | Clear text, not hashed, and a value the cardholder recognises |
| Full delivery address | Street, city, state or province, postal code and country. Clear text, not hashed |
| Device ID | A verifiable device identifier such as an IMEI, at least 15 characters, clear text, not hashed |
| Device fingerprint | Derived from at least two software or hardware properties, at least 20 characters, may be hashed |
| IP address | The cardholder's public IP, clear text, not hashed, valid IPv4 or IPv6 |
Note which single item may be hashed. The device fingerprint, and nothing else. If your systems store login IDs or addresses hashed for privacy reasons, you cannot use them here, and that's a design decision to make deliberately rather than discover mid-dispute.
Never Send Both Device ID And Fingerprint
Small rule, easy to trip.
The rules state that device ID and device fingerprint are considered similar data elements, that an acquirer is not permitted to supply both in support of a submission, and that another data element must be selected instead.
So sending both doesn't strengthen your file. It costs you a slot you needed for a genuinely different element. Pick one, then add the login ID, the delivery address or the IP.
What Changes On 24 October 2026
The 3.0 route is being rewritten, and the shift is significant.
Through 23 October 2026, the two previous undisputed transactions are your own. From 24 October 2026, the rule reads that the same card or related payment credential was used at one or more merchants in two previous transactions, which broadens the history you can draw on beyond your own customer relationship.
There's a limit attached. A new footnote says an acquirer must only submit transaction data accepted and processed by that acquirer. So it widens from your transactions to your acquirer's portfolio, not to the whole network.
If you're close to a threshold on your dispute ratio, that change is worth a conversation with your acquirer before it lands, because how much it helps you depends entirely on how much of your customers' activity sits inside their book.
Frequently Asked Questions
Is compelling evidence just any documentation I have?
No. It's a defined list in section 11.5.1 of the Visa rules, organised by dispute condition. Documentation outside that list isn't compelling evidence regardless of how persuasive it seems.
Do I need a signature to prove delivery?
Not where you have an AVS match of Y or M for the delivery address. The rules say explicitly that a signature is not required as evidence of delivery in that case.
What counts for digital goods?
A description of what was sold, the download date, and two or more identifiers: IP address, device ID, the purchaser's name and email linked to a profile you hold, evidence the profile was verified before the transaction, evidence of access on or after the transaction date, or an undisputed transaction from the same device and credential.
How old do the previous transactions need to be for Compelling Evidence 3.0?
More than 120 calendar days before the dispute was submitted, and not more than 365 calendar days before the dispute's processing date.
Can I hash the data for privacy?
Only the device fingerprint. Login ID, delivery address, device ID and IP address must all be supplied in clear text.
Can I send both a device ID and a device fingerprint?
No. The rules treat them as similar data elements and prohibit supplying both. Choose one and use a different element for the second data point.
Want your dispute file checked against what the rules actually accept before you send it? Apply free or talk to a specialist, and see how we handle chargeback defense.
Jeffrey Anderson, Merchant Placement Specialist
Merchant placement specialist at Gray Merchants. Jeffrey works directly with acquiring-bank underwriting teams across the firm’s 70+ banking relationships to place high-risk and hard-to-place businesses, structure multi-MID accounts, and keep flagged merchants processing. His writing draws on the placement files he works every week: what underwriters ask for, why accounts get declined, and what keeps an approved account open.