ChargebackDesk · Guides · Fraudulent

Responding to a Stripe "fraudulent" dispute

The cardholder told their bank they did not authorize this charge (Visa 10.4, and 10.1–10.3 where relevant; Mastercard 4837, and the other codes Stripe lists under Fraudulent: 4849, 4870, 4871 and 6341; Amex F29). For a digital product, your rebuttal is not a tracking number — it's the record of the buyer receiving and using what they paid for.

The story you have to tell

The legitimate cardholder — or someone using their credentials on their account — bought the product and used it. That story lives or dies on usage evidence. An issuer reading your response wants to see, in order: the account was created for the buyer, the product was delivered to them, and they actually used it after paying.

Deadline rules

• The deadline that matters is the evidence due-by date on the dispute itself in Stripe (evidence_details.due_by). Not a network average, not a guess — if you don't respond by it, you automatically lose the dispute.
• Evidence is effectively a single shot — plan to submit a complete packet, because you generally cannot amend after submitting.
• Work backwards: aim to submit at least 72 hours early so a missing file doesn't become a missed deadline.
• Amex and Discover may start with an inquiry (warning_needs_response) before a formal dispute. Answer inquiries too — an unanswered Discover inquiry can escalate into a dispute you can no longer challenge.

What evidence wins

1. Access / activity log. Logins, lesson completions, license activations, API calls, downloads — with timestamps. Post-purchase use by the account that bought is the rebuttal. Excerpt it properly: first event, most recent event, and the highest-activity session (roughly 3–40 events), with totals stated.
2. Delivery proof tied to the buyer. Account creation record, license key issuance, or a welcome-email delivery log showing the product reached the email on the charge.
3. Customer communication. Post-purchase emails or tickets from the buyer asking product questions ("where is module 6?"). A buyer using support is a buyer who purchased. Include the complete thread.
4. Receipt + product description. What was sold, when, for how much, and how it was delivered.
5. Purchase-session corroboration. The purchase IP from the charge record and IPs in the access log may corroborate account activity. Never present an IP as proof of who a person is — VPNs exist, and issuers know it.

The minimum checklist

Below any of these, we refuse the case rather than file it — and you should think hard before filing yourself:

• ME-F1 — at least one post-purchase access event with a timestamp at or after purchase.
• ME-F2 — purchase IP present in the export AND at least one access-log IP present (exact match not required).
• ME-F3 — customer name and email from the charge record.
• ME-F4 — delivery provable: delivery email log, license record, or account-creation timestamp on/after purchase.

Flags you fulfilled anyway. If your own systems flagged this payment as a stolen card, raised a fraud warning, or Radar flagged it, and the order was fulfilled anyway, we decline the case. A failed AVS or CVC check that the card issuer authorized anyway is different: it's not an automatic decline, and a specialist reviews it — Stripe lists "issuer authorized despite a failed CVC check" among the evidence for this category, and includes the AVS/CVC results in the response regardless.

Common mistakes that lose winnable cases

• Submitting a "signature." A checkout checkbox is not a signature. Presenting it as one misrepresents the record and poisons the honest evidence around it.
• Leading with AVS/CVC results. Authorization metadata says a card was valid, not that the cardholder used your product. Usage is the rebuttal.
• Speculating about the cardholder. "This customer is running a scam" is not a fact in your records. State what was purchased, delivered, and used — nothing about motives.
• Cherry-picking the support thread. Complete threads only. An omitted unfavorable message, if it surfaces, reads as fabrication.
• Having no logs at all. If your platform doesn't retain access logs, this category is usually unwinnable — and the real fix is retention, starting today, for the next dispute.

Other dispute categories

• Subscription canceled
• Product not received
• Product unacceptable
• Unrecognized
• Credit not processed
• General
• All reason codes — Visa, Mastercard, Amex, Discover