Stripe representment templates for digital goods disputes
Copy-paste representment templates for Stripe chargebacks on digital products: the response structure, the evidence packet order, and the wording that addresses each dispute reason.
A representment is a structured argument, not a complaint. The template’s job is to put the right fact in front of the analyst in the order the card network evaluates it.
Definition. Representment is the merchant’s formal response to a chargeback — the packet of narrative and evidence Stripe submits to the card network on your behalf. For digital goods the packet must overcome the default assumption that “nothing physical shipped” means “nothing was delivered.” Stripe’s responding to disputes documentation describes the submission mechanics; this guide gives you the wording.
The response skeleton (all dispute reasons)
Use this structure regardless of the dispute reason. Replace [BRACKETS].
RE: Dispute [DISPUTE ID] — Transaction [CHARGE ID], [DATE], [AMOUNT]
Transaction summary. On [DATE], [CUSTOMER NAME] ([CUSTOMER EMAIL]) purchased [PRODUCT NAME], a digital [download / license / subscription], for [AMOUNT] via our website [URL]. The product was delivered electronically to the same email address [N minutes] after payment.
Delivery evidence. Exhibit A shows [the download completed from IP [IP] on [DATE+TIME] / license key [KEY] activated on [DATE] / the customer logged in [N] times between purchase and dispute].
Consent evidence. Exhibit B shows the checkout page as the customer saw it, with [price, product description, refund policy link] displayed, and our records of the customer accepting the Terms of Service ([TIMESTAMP], IP [IP]).
[Reason-specific paragraph — see below.]
Refund policy. Our refund policy (Exhibit D, published at [URL] and linked at checkout) states [ONE-SENTENCE SUMMARY]. The customer [did not contact support / contacted support on [DATE], and we responded on [DATE] — thread attached as Exhibit E].
We ask that this dispute be resolved in the merchant’s favor based on the delivery and consent evidence above.
The reason-specific paragraph
The middle paragraph changes by dispute reason. These are the three that dominate digital goods.
”Product not received”
Argument: electronic delivery is logged.
The product is delivered electronically and instantly; no physical shipment exists or was promised. Our delivery logs (Exhibit A) show the file was downloaded / the account was accessed from IP [IP] on [DATE], [N minutes] after purchase. This IP matches the IP used at checkout (Exhibit B).
”Fraudulent / unauthorized”
Argument: the cardholder’s identity is linked to usage.
The purchase used [3-D Secure authentication / a card with CVC and postal-code match — Exhibit C shows the Radar evaluation]. Post-purchase, the account associated with [CUSTOMER EMAIL] logged in [N] times over [PERIOD] and [used the product / renewed a session] — sustained usage inconsistent with a stolen card. [If 3DS authenticated: liability for this transaction shifted to the issuer at authentication.]
”Product unacceptable / not as described”
Argument: what was promised is what was delivered.
Exhibit B shows the product page at the time of purchase, including [feature list / file format / compatibility notes]. Exhibit A confirms the customer received exactly that product. The customer [never contacted support about the alleged defect / contacted support on [DATE]; we offered [FIX/REFUND] on [DATE] — Exhibit E]. Dissatisfaction without a support attempt does not meet the card network’s standard for this reason code.
Exhibit order for digital goods
Label exhibits in the order the analyst needs them, not the order you found them:
| Exhibit | Content | Source |
|---|---|---|
| A | Delivery proof: download log, license activation, or login history | Your app / delivery system |
| B | Checkout page + terms acceptance record (timestamp, IP) | Your checkout flow |
| C | Payment authentication: Radar risk score, CVC/AVS/3DS result | Stripe dashboard |
| D | Refund policy as published at purchase date | Your website |
| E | Support correspondence, if any | Helpdesk |
What belongs in each category — and the gaps that lose winnable cases — is covered in the dispute evidence guide.
Three wording rules
- Facts before feelings. Delete every “clearly,” “obviously,” and “this customer is abusing the system.” Analysts discount editorializing and it costs you the only page they read.
- One claim, one exhibit. Every factual sentence should name the exhibit that proves it. Unattributed claims are skipped.
- Match the reason code. Evidence that ignores the stated reason (“here’s our delivery log” on a not as described dispute) reads as a form letter and loses.
Before the next dispute
The strongest packets are assembled from records that existed before the dispute — consent snapshots, download logs, support threads. Run the free scan to check the policy pages this template cites, and see the dispute process guide for the timeline you are working against.
Frequently asked
- Does Stripe read my representment text?
- Stripe formats and forwards your submission to the card network; the issuing bank's analyst reads it. Write for a reviewer who has 2–3 minutes per case and has never seen your product.
- How long should a representment response be?
- One page of narrative plus labeled exhibits. Analysts skim — front-load the transaction facts and the single strongest piece of evidence in the first paragraph.
- Can I win 'product not received' disputes for a download?
- Yes — download logs, license activations, and post-purchase logins are accepted as digital delivery proof. That evidence category exists in Stripe's dispute form for exactly this case.
- Should I refund instead of fighting?
- For amounts under your evidence-assembly cost, often yes. But respond to the dispute even if you refund, otherwise it closes against you on procedural grounds.