Digital Goods Evidence
A course or download isn't a dispute reason. Looking for the actual claim?
Start with what the customer claims, then use the evidence template below.
- Digital goods need their own delivery records. Access logs and usage data help you answer the actual dispute claim
- Collect access logs, IPs, device fingerprints and usage records at transaction time. Not after the dispute lands
- For Visa 10.4, ask your processor whether your history meets CE 3.0 requirements. Earlier purchases of the same product alone don't qualify.
- Session logs and support records can show delivery and use. They don't guarantee the outcome
Physical goods merchants can show tracking for a "not received" dispute. Digital merchants need access, download or usage records instead. Match that evidence to the customer's actual claim.
The reason: no delivery proof, no signature, no package photo. Just bits on a wire.
But you can win digital disputes if you collect the right data and present it correctly. This page shows you how.
Why Digital Goods Are Different
The Evidence Gap
| Physical Goods | Digital Goods |
|---|---|
| Tracking number | No tracking |
| Carrier confirmation | No carrier |
| Delivery photo | No photo |
| Signature | No signature |
| Weight/dimensions | No physical attributes |
What You Have Instead
Digital goods evidence relies on:
- Access logs - Proof of login and usage
- Download records - Proof of delivery to their device
- IP correlation - Links purchase and access locations; doesn't identify the cardholder by itself
- Device matching - Same device for purchase and access
- Account activity - Ongoing usage proves receipt
The hard part is presenting it in a form issuers understand.
Evidence That Wins Digital Disputes
Tier 1: Strongest Evidence
These have the highest impact on dispute outcomes.
| Evidence | Why It Works | How to Collect |
|---|---|---|
| Post-purchase login from same IP | Links the purchase to later account access; doesn't identify the cardholder alone | Log IP + timestamp at every login |
| Device fingerprint match | Same device for purchase and usage | Implement fingerprinting SDK |
| In-product activity after purchase | Shows account usage; check who had access | Log all feature usage with timestamps |
| Customer acknowledgment | They admitted receiving/using | Support tickets, emails, chat logs |
| Account activity summary | Pattern of ongoing access | Generate usage reports |
Tier 2: Strong Evidence
These support your case but rarely win alone.
| Evidence | Why It Helps | Limitation |
|---|---|---|
| Download/activation timestamp | Proves delivery | Doesn't prove who downloaded |
| Email delivery confirmation | Shows notification sent | Doesn't prove it was read |
| Account creation pre-dispute | Shows established relationship | Doesn't prove this transaction |
| AVS/CVV match | Authorization passed | Cardholder could still dispute |
| 3DS authentication | Cardholder verified | May shift liability, varies by issuer |
Tier 3: Weak Evidence
Don't rely on these alone.
| Evidence | Why It's Weak |
|---|---|
| Terms of service screenshot | Proves nothing about this transaction |
| Refund policy | Proves you have a policy, not that it applies |
| "Digital goods are non-refundable" | Doesn't override dispute rights |
| Email confirmation sent | Doesn't prove delivery or receipt |
| Generic security description | "We use SSL" means nothing to issuers |
Plenty of SMBs have no device fingerprinting and no detailed access logs. On low-ticket items that's fine. Be honest about where you sit.
- No access logs, no device data, under $50: compare the available evidence with the cost of a response. If a chargeback is already open, accept it through the case rather than sending a separate refund.
- Basic access logs, no device fingerprinting: you can fight.
- Full logging (IP, device fingerprint, usage timestamps, downloads): fight with confidence. That's strong evidence.
The cheapest win is better evidence from tomorrow. Not fighting today's disputes with nothing.
Evidence Collection by Product Type
SaaS / Subscription Software
What to capture at purchase:
- IP address + geolocation
- Device fingerprint
- Account ID
- Subscription terms acknowledged (with timestamp)
What to capture ongoing:
- Login timestamps and IPs
- Features accessed
- Data created (documents, records, settings)
- API calls made
- Session duration
Evidence package for disputes:
1. Account overview
- Created: [date]
- Email: [email]
- Subscription: [plan name]
- Status: Active / Cancelled on [date]
2. Purchase transaction
- Date: [date/time]
- Amount: $X
- IP: [IP address] (Location: [city, country])
- Device: [fingerprint hash]
3. Post-purchase activity (last 30 days before dispute)
| Date | Action | IP Address |
|------------|-------------------------|---------------|
| [date] | Login | [same IP] |
| [date] | Created document | [same IP] |
| [date] | Invited team member | [same IP] |
| [date] | Changed settings | [same IP] |
4. Customer communication
[Any support tickets, emails acknowledging service]
Digital Downloads (Software, Games, Music)
What to capture at purchase:
- IP address
- Device fingerprint
- Download link generated
What to capture at download:
- Download initiation timestamp
- Download completion (if trackable)
- IP address at download
- Device/browser at download
What to capture at activation:
- License key activation timestamp
- Hardware ID (for device-locked licenses)
- Activation IP
Evidence package for disputes:
1. Purchase record
- Date: [date/time]
- Product: [name]
- IP: [IP address]
- Device fingerprint: [hash]
2. Download record
- Link generated: [timestamp]
- First download: [timestamp]
- Download IP: [IP address]
- Downloads completed: [count]
3. Activation record (if applicable)
- License key: [last 4 chars]
- Activated: [timestamp]
- Hardware ID: [hash]
- Activation IP: [IP address]
4. IP correlation
Purchase IP [X.X.X.X] matches download IP [X.X.X.X]
Streaming / Video / Courses
What to capture at purchase:
- Standard (IP, device, account)
What to capture ongoing:
- Content accessed (video IDs, lesson names)
- Watch time / completion percentage
- Progress saved
- Notes or bookmarks created
Evidence package for disputes:
1. Account and purchase details
[Standard info]
2. Content access log
| Date | Content Accessed | Duration | Completion |
|------------|-------------------------|-----------|------------|
| [date] | Module 1: Introduction | 45 min | 100% |
| [date] | Module 2: Basics | 62 min | 100% |
| [date] | Module 3: Advanced | 28 min | 45% |
3. Total engagement
- Videos watched: 12 of 20
- Total watch time: 8.5 hours
- Last access: [date] (after dispute filed)
In-App Purchases / Gaming
What to capture:
- Account ID and age
- Purchase IP and device
- Virtual goods delivered
- Goods consumed/used
- Gameplay time
Evidence package:
1. Account overview
- Account created: [date]
- Account level/rank: [X]
- Total playtime: [hours]
2. This purchase
- Date: [date/time]
- Item: [name]
- IP: [IP address]
- Device: [fingerprint]
3. Item delivery and usage
- Item credited: [timestamp]
- Item used/consumed: [timestamp]
- Gameplay after purchase: [hours]
4. Account activity (post-purchase)
[Login timestamps, achievements, multiplayer sessions]
Visa Compelling Evidence 3.0 for Digital
For the full CE 3.0 requirements and eligibility, see Compelling Evidence: Visa CE 3.0. This section covers the digital side: how to capture matching data.
CE 3.0 works for digital goods, but you need to capture the right data.
CE 3.0 Matching Elements
Match at least two elements across the disputed purchase and two qualifying prior transactions. One match must be IP or device. Device ID and fingerprint count as one element.
| Element | Digital Implementation |
|---|---|
| Device ID/fingerprint | Use fingerprinting SDK (DeviceAtlas, Iovation, etc.) |
| IP address | Log at transaction time |
| Shipping address | Full delivery address, if available. Don't substitute a billing address |
| User account | Account ID / email |
Prior Transaction Requirements
Prior transactions: two earlier purchases on the same card, each more than 120 and no more than 365 days before the dispute, with no fraud report from the issuer. Full checklist.
Digital CE 3.0 Example
Disputed Transaction (Dec 15, 2024):
- Amount: $99
- Device ID: abc123
- IP: 203.0.113.42
- Account: user@email.com
Prior Transaction #1 (Aug 10, 2024):
- Amount: $49
- Device ID: abc123 ← MATCH
- IP: 203.0.113.42 ← MATCH
- Account: user@email.com ← MATCH
- No dispute
Prior Transaction #2 (May 22, 2024):
- Amount: $29
- Device ID: abc123 ← MATCH
- IP: 198.51.100.23 (different)
- Account: user@email.com ← MATCH
- No dispute
This is a matching sketch, not a qualifying submission.
Device IDs here are placeholders. Ask your processor to check the real device format, dispute dates and supported route.
The Usage-After-Dispute Strategy
The strongest evidence for digital goods is usage after the customer filed the dispute.
Why This Works
If the customer claims they never received the product, but you can show they:
- Logged in after the dispute date
- Accessed features after disputing
- Created content after disputing
- Made API calls after disputing
Then they clearly received and used what they claim they didn't get.
How to Present It
Timeline:
Dec 1: Purchase made ($99)
Dec 15: Dispute filed - "Never received"
Dec 16: Customer logged in (IP: X.X.X.X) ← AFTER DISPUTE
Dec 17: Customer accessed Dashboard ← AFTER DISPUTE
Dec 18: Customer exported report ← AFTER DISPUTE
Dec 20: Dispute response due
The customer claims they never received access to [Product].
However, our logs show they logged in and actively used the
product on Dec 16, 17, and 18 - AFTER filing the dispute.
This demonstrates the customer received and continues to use
the service they claim was never delivered.
Logging Requirements
To use this strategy, you need:
- Login timestamps with IP
- Feature access logs with timestamps
- Session data (what they did, when)
- Correlation to the specific account
"Can we generate a usage report for any account showing: all logins with IP, features accessed with timestamps, and any content created? We need this for chargeback responses."
Evidence Assembly Checklist
Before you submit, check you've got:
Required (Don't Submit Without)
- Transaction timestamp and amount
- Customer email and account ID
- IP address at purchase
- At least one proof of access/usage after purchase
Strongly Recommended
- Device fingerprint match (purchase to usage)
- Multiple usage events with timestamps
- IP correlation (purchase IP = usage IP)
- Usage after dispute date (if available)
Supporting (Include If Available)
- Prior successful transactions on same account
- Customer support tickets (especially positive ones)
- Email confirmations with delivery timestamps
- AVS/CVV match confirmation
- 3DS authentication confirmation
Format Checklist
- Single PDF document
- Summary on first page
- Strongest evidence highlighted
- Timestamps clearly visible
- Under 10 pages if possible
- Professional, not emotional
Common Mistakes
Mistake 1: "Digital = No Delivery Proof Needed"
Wrong thinking: "It's digital, so there's no delivery to prove."
Reality: you prove delivery a different way. Access logs, downloads and activations are your delivery proof.
Mistake 2: Relying on Confirmation Emails
Wrong thinking: "We sent a confirmation email, so they received it."
Reality: Email confirmation proves you sent an email. It doesn't prove:
- They opened it
- They clicked the link
- They accessed the product
- They are the cardholder
Mistake 3: Generic Responses
Wrong thinking: "Our standard response covers everything."
Reality: "We delivered the digital product as described" doesn't show this customer's delivery or use. Add the relevant access records.
Mistake 4: Not Collecting Data
Wrong thinking: "We'll figure out evidence when we get a chargeback."
Reality: you can't go back and capture login IPs, device fingerprints or usage patterns. Collect at transaction time and access time. Not at dispute time.
Mistake 5: Fighting Unwinnable Disputes
Wrong thinking: "We'll fight every chargeback on principle."
Reality: no usage logs, no login records, no device match? Check what other evidence answers the dispute reason. Compare the amount at stake with the work and cost of a response.
Test to Run
Digital evidence audit (7 days):
Day 1-2: Inventory
- List all data points you currently capture at purchase
- List all data points you capture at login/usage
- Identify gaps
Day 3-4: Implement
- Add missing logging (minimum: IP at purchase, IP at login, usage events)
- Verify device fingerprinting is active
- Test evidence retrieval for a sample account
Day 5-7: Template
- Create evidence package template by product type
- Build query to pull usage report for any account
- Train support team on evidence assembly
Success criteria: you can assemble the records needed for your common dispute reasons before the notice deadline, with time to check them. Log missing records and preparation time so you can improve the next case.
Scale Callout
| Volume | Focus |
|---|---|
| Under $100k/mo | Implement basic logging (IP, login, usage). Manual evidence assembly. |
| $100k-$500k/mo | Device fingerprinting. Automated usage report generation. CE 3.0 data capture. |
| Over $500k/mo | Full fraud stack with fingerprinting. Auto-generated evidence packages. API integration with processor for CE 3.0 submission. |
Where This Breaks
-
Account sharing. The cardholder shared their login? That person's usage doesn't prove the cardholder used anything. You may still lose.
-
Stolen credentials. A fraudster opened the account with stolen card data. Every usage log is the fraudster's, not the cardholder's. True fraud, true loss.
-
Immediate disputes. Dispute filed minutes after purchase? You have no usage logs. Some fraud rings do it on purpose.
-
No logging infrastructure. No IPs, no fingerprints, no usage data means no evidence. Build the logging before you need it.
Analyst Layer: Metrics to Track
| Metric | What It Tells You | Target |
|---|---|---|
| Win rate (digital goods) | Overall effectiveness | Track your own results |
| Win rate by product type | Where to focus | Varies |
| Evidence completeness rate | Data capture health | Track missing records by dispute reason; compare before and after logging changes |
| Time to evidence package | Response efficiency | Set a preparation budget that leaves time for review before the notice deadline |
| CE 3.0 qualification rate | Prior transaction matching | Track it, and why cases fail |
| Usage-after-dispute rate | Post-dispute access | Higher = better |
Track Digital Disputes by Product
| Product Type | Evidence to Check |
|---|---|
| SaaS subscriptions | Login timestamps, features accessed and data created |
| Digital downloads | Download records and activation timestamps |
| Streaming/courses | Content accessed, watch time and progress |
| In-app purchases | Virtual goods delivered and used, plus account activity |
Track your own win rate by reason code rather than relying on a general figure.
Check your evidence collection for gaps.
Next Steps
Not collecting usage data?
- Implement IP logging at purchase and login → Minimum viable evidence
- Check that your processor can use the device data for the full CE 3.0 requirements
- Log feature usage with timestamps → Proof of access
Getting chargebacks you should win?
- Audit your evidence package → What's missing?
- Build product-specific templates → Standardize evidence
- Check for usage-after-dispute → Your strongest argument
High volume digital business?
- Automate evidence assembly → One click to generate package
- Confirm the CE 3.0 submission route and required records with your processor
- Build chargeback prevention → Alerts and 3DS
See Also
- Winning Evidence - General evidence strategy
- Compelling Evidence 3.0 - CE 3.0 details
- Representment - Fighting chargebacks
- Friendly Fraud - Customer abuse patterns
- Device Fingerprinting - Implementation
- Subscriptions & Recurring - Subscription disputes
- 3D Secure - Liability shift for digital
- Chargeback Alerts - Prevention tools
- Chargeback Metrics - Win rate tracking
- Refund Strategy - When not to fight