Stripe Studied 1 Million Disputes: The Evidence That Actually Wins a "Product Not Received" Case

Every guide to winning a Stripe dispute says roughly the same thing: submit strong evidence, do it fast, prove the customer got what they paid for. None of them say which evidence actually moves the needle, because until recently nobody had run the numbers. In July 2026, Stripe did — pulling evidence packets from a million disputes over a 16-week window and isolating which specific pieces of evidence correlated with a win. The results are specific enough to change what you build, not just what you write in a dispute response.

What the study actually measured

"Product not received" is Stripe's most common nonfraud dispute category, spanning everything from a package that genuinely got lost to a subscriber who forgot they signed up and told their bank they never got what they paid for. Stripe's research team took a million of these disputes, looked at what evidence merchants had actually attached to each response, and isolated which individual pieces of evidence — controlling for everything else — moved the win rate up or down. That's a meaningfully different exercise than the usual "here's what a strong dispute response looks like" advice piece. It's measured, not prescribed.

We've covered the broader mechanics of chargebacks and disputes before — response windows, network thresholds, why subscription billing gets hit harder than one-off purchases. This is narrower and more useful: given that a dispute has landed, what specifically should be in the response, and does it differ for a SaaS product versus a company shipping boxes.

The physical-goods hierarchy (and why it doesn't transfer)

For businesses that ship something, Stripe's data shows a clean, stackable hierarchy of evidence value:

Delivery confirmation alone is worth 27 points. Layering a GPS delivery map on top adds another 15. A recipient signature on top of both adds a final 2 — a real but much smaller marginal gain, because by that point the case is already strong. None of this has an equivalent for a SaaS product. There's no truck, no GPS pin, no doorstep. If your product is software, the physical-goods playbook — the one most generic "how to win a Stripe dispute" article defaults to — simply doesn't apply to you, and building a case around it wastes the response window on the wrong evidence.

What actually matters for a digital or subscription product

Stripe's data isolates two evidence types specifically for digital goods, and they look nothing like the shipping-and-signature stack above:

The refund figure is worth sitting with, because it's counterintuitive at first. If you've already refunded a customer, why would a dispute even matter? Because the dispute and the refund aren't always the same event to the bank. A customer can request a refund from you, get it, and still separately dispute the original charge through their bank — sometimes because they forgot they got the refund, sometimes because the dispute was already in motion before the refund cleared. When that happens, proof of the refund is close to a decisive piece of evidence: it directly answers the question the arbitrator is actually asking, which is "did this business make it right," not "did the customer technically get what the reason code says they didn't."

The practical implication is that your refund records need to be attachable as evidence, not just a line in your accounting system. If a support agent processes a refund manually outside Stripe, or through a different tool than the one that generates your dispute evidence, that refund won't show up automatically when a dispute response gets compiled — and you lose the strongest evidence type in the entire dataset by default, not by choice.

Why "product not received" applies to software at all

It's a fair question why a reason code built around missing packages is the one most SaaS disputes fall under. The answer is that issuing banks work from a fixed, network-defined list of reason codes, and most of them predate subscription software as a purchase category. A cardholder calls their bank, says "I'm being charged for something I don't use," and the bank's support rep maps that complaint onto the closest available code — usually product-not-received or a general "services not as described" variant, rather than anything SaaS-specific. That's also why our chargebacks guide spends time on "friendly fraud": a subscriber disputing a renewal they genuinely forgot about gets coded the same way as someone who never got a package, and the reason code alone won't tell you which one you're dealing with.

What this means practically: don't read a "product not received" dispute on a subscription and assume the customer is lying about non-use. Often they're not — they stopped logging in months ago and the charge really did land on an account nobody was using. Usage logs cut both ways here. Recent, active usage right up to the disputed charge is strong evidence for you. A usage trail that goes cold weeks before the charge is a signal the case is weaker than it looks, and worth weighing against the $15 dispute fee (plus another $15 if you contest and lose) before you spend engineering time pulling logs for a case unlikely to turn.

Building the evidence pipeline before the dispute happens

The 7–21 day response window is the same regardless of what evidence you need, and it's not enough time to build data infrastructure from scratch. The teams who consistently win these disputes aren't assembling evidence reactively — they've wired the two things Stripe's data says matter most into something queryable the moment a charge.dispute.created webhook fires:

• A refund system that writes to one place. Whether a refund happens through your Stripe dashboard, an API call from your support tool, or a manual override, it needs to land in a system your dispute-response process actually checks. A refund your evidence packet can't find is a refund that doesn't count.
• Session or access logs tied to the billing customer ID, not just the app's internal user ID. If pulling "did this customer log in after this charge" requires a cross-reference between your auth system and your billing system that nobody's built, you'll be doing it manually inside a 7-day window instead of querying it in minutes.
• A dispute-response template scoped to reason code, not one generic template. A product-not-received dispute on a digital product should default to pulling refund status and access logs first. Don't reach for delivery-confirmation logic that was written for a different kind of business.

This is the same logic behind wiring up involuntary churn recovery before a payment ever fails, rather than scrambling after the fact — the infrastructure has to exist before the event, because the event itself doesn't leave you time to build it.

Where not to spend the effort

Stripe's data is also useful for what it doesn't reward. A recipient signature adds 2 points on top of a GPS map that's already added 15 on top of delivery confirmation's 27 — real, but a rounding error next to the 63-point lift a refund record gets a digital-goods dispute. If your team is choosing between building a more granular access-log pipeline and chasing marginal evidence types with a small measured effect, the data says build the pipeline. The same applies to over-customizing dispute-response copy: a well-organized packet with the right two or three pieces of evidence outperforms a longer, more polished one built around the wrong evidence.

None of this replaces preventing the dispute in the first place. A subscriber who can find your cancel button doesn't need to call their bank, and a customer who gets a fast, easy refund from you directly never generates a dispute to begin with — which is a large part of what a well-built cancellation flow is actually protecting you from. If you're trying to separate how much of your reported churn is coming through disputes versus your own cancel flow, run both numbers through our churn calculator before you invest in evidence infrastructure — sometimes the cheaper fix is making the exit easier to find, not making the dispute easier to win.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.