EDITORIAL RESEARCH / ECOM RATINGS
A reason-code-first guide to preserving payment, entitlement, access and support records before a digital chargeback arrives.
Independent documentation analysis · Sources checked October 28, 2026 · Practical guide
A digital product can be delivered seconds after payment and still generate a chargeback weeks later. The disputed transaction may concern a download, a paid template, a software license, a hosted course, or access to a subscription service. Unlike a shipped parcel, these purchases leave no carrier tracking number. That does not mean sellers have no evidence. It means the evidence must come from the checkout, entitlement, access and support systems that already operate the business.
The critical distinction: an order receipt proves that a payment was attempted or completed; it does not by itself prove that the customer received, accessed or used a digital product. For a defensible response, preserve records from the entire purchase-to-use journey, and match them to the reason code shown in Stripe.
Start with the actual dispute reason, not a generic rebuttal
Stripe disputes are not all evaluated against the same question. A cardholder may say the product never arrived, the transaction was unauthorized, a purchased file was defective, a subscription was canceled, or a credit was not processed. Sending the same screenshot collection for every case is less useful than building a concise answer to the allegation. A download timestamp is powerful context for a product-not-received complaint but is not a complete response to a claim that the delivered file differed from what was advertised.
The first task is to record the Stripe payment identifier, order identifier, dispute reason, amount, currency, cardholder statement and response deadline. Work backwards from that reason. If the claim is nonreceipt, show exactly how access was provisioned and whether it was exercised. If the claim is fraud, distinguish authentication and customer history from mere fulfillment. If the complaint is about quality, preserve what the sales page promised and what the buyer actually received. If cancellation is disputed, the visible cancellation policy and account events matter.
Stripe offers example evidence packets for different dispute categories, including digital product nonreceipt. The documentation emphasizes relevant confirmation, technical activity and customer communications rather than sheer document volume. A short, dated, internally consistent packet can be more useful to a reviewer than dozens of unrelated screenshots. Even strong evidence does not guarantee a win; the card issuer and network rules control the decision.
Build an evidence chain before a dispute exists
Think of the evidence as five linked events: the checkout displayed the offer; payment completed; the store granted entitlement; delivery or access became available; the customer received or used that access. For each event, store a timestamp in UTC, the internal customer or order key, the affected item and a source-system reference. This creates an audit trail even if several vendors handle the transaction.
For a file store, the chain might be: product version 4 appeared at checkout; Stripe recorded a successful payment; the order system generated an entitlement; the email provider accepted a receipt or access message; the download service recorded a successful authorized request. For a course, it might be enrollment, login, lesson access and completion events. For software, a generated license, activation record and later use can help explain what occurred.
The chain is only credible when events are tied together. A generic server log showing somebody downloaded guide.pdf proves little. A log containing a stable entitlement ID, download-token hash, order ID, time and response status can connect access to a specific transaction without exposing unnecessary personal information. Avoid collecting sensitive data merely because it might someday be useful; decide what is necessary, document retention, restrict access and disclose data handling appropriately.
What the payment and checkout record should contain
Keep the precise product name and variant, unit price, total charged, currency, tax treatment where applicable, checkout date and time, purchaser email as entered, and the Stripe payment or charge identifier. Archive a version of the offer and checkout terms that were presented at purchase time. This is especially important if the sales page changes frequently: the present-day page cannot always establish what a buyer saw six months earlier.
Retain payment status transitions, an invoice or receipt reference, refunds, authentication results available from the payment provider, and any separate customer-initiated changes. When a cardholder reports an unrecognized payment, those records let a merchant describe the checkout rather than inventing a narrative. The appearance of a valid billing email or a successful payment is not definitive proof that the authorized cardholder made the purchase, so do not overstate what a single field proves.
Record policy acceptance cautiously. A timestamp and version identifier for an explicitly disclosed refund or subscription policy can support the account of what happened. An unlabeled checkbox or a hyperlink buried elsewhere is weaker evidence. For recurring services, preserve the renewal notice, cancellation path, billing interval and whether a cancellation event actually occurred before the charged period. Store the text of the relevant policy version, not only the URL to a policy that may later change.
Digital delivery evidence: granted, notified, opened and downloaded
Four states should not be mixed together. Granted means the order system created an entitlement or made a product available. Notified means an email or account alert was sent. Opened means the account or delivery page was viewed. Downloaded means a file-transfer or access event occurred. The fact that an email service accepted a message does not prove it reached the inbox; an open-tracking pixel may not accurately prove the recipient read the email. Likewise, issuing a temporary link does not prove the recipient used it.
Stripe’s dispute API includes an access_activity_log field for server or activity logs demonstrating that a customer accessed or downloaded the digital product. Its documentation calls for relevant IP addresses, timestamps and detailed recorded activity. Useful entries may also include the account ID, product ID, event type, HTTP result and limited device or session context. When sharing such evidence, redact secrets and unrelated customer information. Never include raw session tokens, passwords or complete card details in the dispute packet.
Where files are generated or stored by an external provider, preserve that provider’s delivery confirmation and map it to your order number. If the provider cannot export historical logs, that limitation should be documented during integration, not discovered after the response deadline. Consider retaining an immutable export of key access events for an appropriate period under your privacy and retention obligations.
Evidence for hosted courses and SaaS services
Access to a service is not always evidenced by one download. For hosted courses, capture enrollment and account-provisioning time, accepted invitations, authenticated logins, lesson or module visits, and completion records where genuinely collected. A purchase-to-login interval may be more meaningful than a generic screenshot of the course dashboard. For a software subscription, activated seats, successful authentication, API calls or completed jobs can show that the service was available and used.
Be disciplined about claims. A login event demonstrates successful authentication, not necessarily satisfaction with the content. A service-usage record may contradict a nonreceipt claim but does not automatically defeat an assertion that the functionality was materially defective. Conversely, a failed login after purchase may strengthen the customer’s complaint and should prompt a real support investigation before responding to the bank.
When a purchaser uses a different email for checkout and the product account, store the confirmed link between the two identities. Do not assume they are connected merely because the names look similar. For enterprise access, maintain the purchase account, team seat assignment and recipient email as separate fields. The person paying and the person using the tool may legitimately differ.
An evidence matrix for four common dispute situations
A useful response packet changes according to the allegation:
| Dispute situation | Best starting records | What still needs explanation |
|---|---|---|
| Digital item not received | Payment record, entitlement creation, notification attempts, successful access or download log | Whether the buyer had a working route to the item and when it was used |
| Unauthorized transaction | Payment authentication results, prior account history, purchase IP and device context when lawfully collected | Why the activity is attributable to the customer; authorization must not be assumed |
| Product not as described | Offer and specification version, delivered asset or version, support ticket and remediation | Whether the product met the actual sales representation |
| Canceled or refund not received | Visible terms, cancellation timestamps, refund ID and processor outcome | Whether the disputed payment or credit fell within the policy and timeline |
The matrix is an editorial tool, not a promise that any evidence type automatically wins. Stripe’s examples illustrate successful and unsuccessful packets because relevance, quality, timelines and network reason codes all matter. Sellers should follow the fields and prompts presented for the specific dispute, which may vary by card network and jurisdiction.
A worked example: a disputed $79 digital course
Assume a fictional creator sold a $79 video course at 14:02 UTC on 3 April. The payment succeeded, the learning system granted access at 14:03, an enrollment email was accepted by the email provider at 14:04, and the student authenticated at 14:17. At 14:21 the student played the first lesson. Three weeks later the cardholder disputes the purchase as “product not received.”
A focused packet would identify the payment and order, attach the product description displayed at checkout, show enrollment under the verified buyer account, list the relevant account and lesson access events with UTC times, and summarize any support exchange. It would not say “the buyer completed the course” if only one lesson play was recorded. It would not present the email provider’s accepted status as proof of inbox delivery. It would avoid claiming that a screenshot of a lesson can establish account ownership.
Now change only the dispute reason to “product not as described.” The same access events become background rather than the centerpiece. The seller now needs the actual course outline, advertised access conditions, delivered lessons, any corrections or refunds offered, and communication showing how the complaint was handled. This is why capturing the entire customer journey produces better evidence than retaining only downloads.
What Stripe’s API fields reveal about recordkeeping
Stripe’s API offers fields for purchase IP, customer email, product description, service dates, customer communication, refund and cancellation policy disclosures, and access logs. The existence of a field is a clue about useful recordkeeping, not a command to collect every possible identifier for every buyer. Digital sellers should retain data that supports a legitimate business purpose, use appropriate notices and security controls, and prefer minimal factual records over broad surveillance.
The access_activity_log field is especially relevant to digital goods because it gives sellers a place to describe verified digital access without forcing the story into physical-shipping fields. The API references a 20,000-character maximum for that field in the documented version. That makes summarization important: include the meaningful timestamps and events, not a raw dump of millions of requests. Some evidence fields take uploaded files rather than plain text; create a stable PDF or export with readable labels and source references.
For merchants integrating through the API, do not submit a dispute automatically when the first evidence field is populated. Stripe lets evidence be staged and then submitted; check the live API version and settings before building automation. The submission should be reviewed for consistency and privacy before it leaves the business. A single factual contradiction can undermine an otherwise strong packet.
Preserve customer communication without manufacturing consent
Every ticket, chat or email connected to a disputed order should be preserved with time, sender, subject or case number and the relevant messages. This includes delivery questions, password-reset requests, requests for alternate formats, complaints and refunds. Messages in which a customer acknowledges receiving the product can be highly relevant, but only if they are genuine and not extracted in a misleading way from a larger conversation.
Avoid writing a rebuttal that says “customer confirmed satisfaction” because someone clicked a thumbs-up in an unrelated onboarding survey. Use exact factual descriptions: “support sent a new access link at 10:15 UTC” or “the customer replied that the file opened successfully.” If records contradict your position, investigate them rather than deleting them or retroactively adjusting timestamps.
Screenshots should display context, dates and stable identifiers. If a chat export contains other customers’ messages or unnecessary sensitive information, redact the unrelated material while preserving authenticity. Keep the unedited original internally under appropriate access controls. The purpose is a reliable business record, not a persuasive collage made at the last minute.
What to do when the download link expired
Digital products often use expiring links, and expiration by itself is not evidence that delivery failed. Ask which exact link was sent, when it became available, what the expiry condition was, whether the customer attempted to open it, and whether an account-based alternative existed. If the buyer never used the link, the delivery record and email history may still support what was offered, but they should not be described as proof of successful download.
When support reissues a link, preserve the new token reference and send time. If the new link fails because of a platform defect, document the incident and corrective action. Issuing a refund or resolving the customer’s access problem may be more commercially sensible than contesting an obviously valid complaint. A dispute response should not become an incentive to ignore a broken fulfillment flow.
For recurring products or updated files, store the version identifier. A buyer who purchased version 2 should not be answered with a screenshot of version 4 and a claim that it proves what was originally delivered. Version-aware entitlement and content archives help the seller respond to disputes and improve customer support simultaneously.
Design a 90-day operational audit, not just a dispute folder
Next, examine the retention schedule. A blanket “keep everything forever” approach is neither efficient nor privacy-conscious. Instead, choose a documented retention period informed by card-network dispute windows, accounting duties and applicable law; consider how to preserve an active dispute hold without indefinitely retaining all raw logs. Restrict access, log exports, and define how customers can exercise data rights while mandatory records remain protected.
Finally, run a mock case. Choose one test purchase, pretend a nonreceipt dispute arrives, and see whether the team can make a clear packet in minutes. If payment and access records do not join correctly, fix the integration. If the same event has three time zones, normalize it. If policy snapshots are missing, add versioned archives. These operational improvements are often more valuable than any single future chargeback win.
A final response checklist for digital sellers
Before submitting, check that the response answers the actual dispute reason; payment and order identifiers match; product descriptions and policies are from the relevant purchase date; access events have interpretable timestamps; customer communication is complete and accurately summarized; unrelated secrets are removed; and any refund record is linked to the original transaction. The packet should have one short factual narrative, a chronological timeline, and a small set of readable supporting files.
Confirm the deadline shown in Stripe. Card-network rules and response windows can vary, so do not assume that a period mentioned in an old tutorial applies to a live case. Also confirm how much material the specific evidence form accepts. A well-supported case submitted too late or with missing mandatory fields is still at risk of losing.
The final point is balance. If the buyer never received an accessible product, a chargeback defense cannot repair that experience. Good dispute operations begin with delivery quality, transparent terms, responsive support and a willingness to resolve real errors. Evidence is there to document what actually happened, not to replace fair customer service.
Bottom line
Digital sellers do not need a delivery truck to demonstrate a completed transaction. They need a verifiable connection between payment, the promised item, the granted entitlement, the notification route, and actual customer activity. Stripe provides evidence fields and example packets that make those connections useful in a dispute. By building the records into ordinary checkout and fulfillment processes, sellers can respond with specific facts rather than improvised screenshots and vague assurances.
The most practical starting point is a single order timeline with timestamps, stable IDs, exact policy versions and relevant access logs. Use it for support first and disputes second. It is the difference between saying a file “must have been delivered” and being able to show what your systems recorded.
For a separate analysis of payment processing and dispute fees, read Stripe Fees Explained and the Ecom Ratings Stripe review.
Primary sources and verification
- Stripe: Dispute sample evidence packets
- Stripe: Update a dispute API, including access_activity_log
- Stripe: Disputes overview and evidence guidance
Editorial method: The $79 course is a fictional worked example. Recommendations about event design and retention are editorial operational guidance, not mandatory Stripe configurations or a guarantee of issuer decisions. Review date: October 28, 2026.