Stripe's Smart Disputes Auto-Fights Your Chargebacks by Default. Since October 28, You Can Finally Prove Whether It Did.

Turn on Smart Disputes and the pitch is simple: Stripe watches for chargebacks, builds the evidence packet from data it already has, and files it before your deadline so a dispute never slips through unanswered. Most teams enable it once and stop thinking about disputes entirely. That's the problem. Until October 28, 2026, there was no clean way to confirm, after the fact, whether Smart Disputes had actually filed anything — or whether a dispute you assumed was covered had simply expired with nothing submitted at all.

What actually shipped on October 28

Two changes landed in the same release, and together they close a real gap rather than adding a new feature. The first adds a submission_method property inside evidence_details on every Dispute object. It's read-only, it's always present, and it reports exactly one of three values: manual, smart_disputes, or not_submitted. It also shows up on every charge.dispute.created, charge.dispute.updated, and charge.dispute.closed event, so a webhook consumer can now tell, without opening the Dashboard, exactly how each dispute's evidence got to the issuer — if it got there at all.

The second is a validation rule. If you update a dispute with intended_submission_method set to smart_disputes and submit set to true, Stripe now checks whether Smart Disputes is actually available for that specific dispute before accepting the request. If it isn't, you get an HTTP 400 with the code smart_disputes_not_available — immediately, not after the response window has quietly closed. Before this shipped, that same scenario had no equivalent signal in the API; you found out a dispute hadn't been handled the way you expected only by noticing it in the Dashboard, usually after it was too late to do anything about it.

The value that should change how you read your dispute data

Of the three submission_method values, two are unremarkable. manual means someone on your team filed a response. smart_disputes means Stripe's automated system handled it — the outcome the feature is designed to produce. not_submitted is the one worth building an alert around, because it means a chargeback ran its full clock with nothing filed on your behalf: no manual response, and no Smart Disputes packet either, usually because the dispute wasn't eligible and nobody caught that in time to respond manually.

Eligibility for Smart Disputes isn't an account-level switch you flip once. Stripe determines it per dispute, weighing the dispute's reason code, the payment method involved, and — critically — how much relevant evidence it can actually assemble and how costly doing so would be relative to the disputed amount. A business that ships physical goods hands Stripe a tracking number and a delivery signature almost by default. A SaaS subscription hands it a login timestamp and not much else, unless you've specifically wired up usage-log collection. That asymmetry means recurring-billing disputes are structurally more likely to land on thin evidence than a retailer's package-delivery dispute, which is exactly the category where not_submitted becomes the realistic outcome instead of a theoretical one.

Why "we turned it on" was never the same as "we're covered"

Stripe's own Smart Disputes documentation has always been honest that the feature only acts on eligible disputes — the Dashboard flags ineligible ones separately, and an API field called recommended_evidence lists exactly what data would move a given dispute into eligibility. What changed on October 28 isn't eligibility itself; it's that you can now ask the API directly, at the moment you're updating a dispute, whether a specific one qualifies — and get a clean error back instead of a request that appears to succeed while quietly doing nothing. That matters more than it sounds, because a dispute that silently goes unanswered looks identical, from the outside, to one Smart Disputes successfully handled — right up until the charge.dispute.closed event comes back marked lost for a reason nobody investigated.

For a subscription business, this compounds with a detail our chargebacks and disputes guide covers from a different angle: recurring billing disputes skew heavily toward reason codes like unrecognized charges and "forgot to cancel," categories where the strongest evidence is renewal history and usage logs, not delivery proof. If your evidence pipeline for those signals is thin, you're not just losing more disputes outright — you're more likely to be the account where Smart Disputes quietly can't help at all, and not_submitted was previously invisible until you went looking for it.

Visa's VAMP program doesn't care why a dispute went unanswered — it counts every chargeback against your ratio regardless of outcome, and it excludes refunds but not losses you never contested. A handful of not_submitted disputes a month is a rounding error for most SaaS businesses. The same handful, repeated every month because nobody noticed a reason code consistently failing Smart Disputes eligibility, is how an account drifts from comfortably under 1.5% toward a ratio that triggers monitoring — not because disputes went up, but because the response rate quietly went to zero on one category of them.

What to actually build now

The fix isn't complicated, but it does require touching code most teams wrote once and never revisited after enabling Smart Disputes:

1. Watch submission_method on charge.dispute.closed, not just the outcome. A dispute that closes lost with submission_method: not_submitted is a different failure than one that closes lost after Stripe genuinely tried. Route the first kind to a human; the second is just a dispute you lost on the merits.
2. Set intended_submission_method deliberately instead of leaving it implicit. If you explicitly mark a dispute for Smart Disputes and handle the smart_disputes_not_available error path, you find out it's ineligible with days left on the clock — not after the deadline, when a Dashboard glance would've been the only way to catch it.
3. Feed the evidence Smart Disputes is actually asking for. The recommended_evidence field on a Dispute lists, per dispute, exactly which data points would move it into eligibility. For most SaaS disputes that's usage logs and renewal history tied to the billing customer ID — the same infrastructure our breakdown of Stripe's million-dispute evidence study found moves win rates the most for digital products, independent of Smart Disputes entirely.

None of this replaces the groundwork Stripe already expects you to have in place. Our piece on Stripe's dispute appeal API covers what happens after a loss you can still contest; this is the layer underneath that, making sure you know which losses actually went through a defense at all before you decide whether an appeal is worth pursuing. A dispute marked not_submitted because it was never eligible for Smart Disputes and nobody filed manually isn't a candidate for appeal — it's a process gap, and the appeal path won't fix a case that was never actually argued.

The deeper fix is the one that was true before this release and still is: a subscriber who can find your cancel button, or gets a fast refund directly from you, never generates the chargeback this whole mechanism exists to answer. Smart Disputes is a backstop for the disputes that still land despite that, and now it's a backstop you can actually audit instead of trusting blind. If disputes are showing up as a meaningful slice of what you're reporting as involuntary churn, run the numbers through our churn calculator before you assume an automated safety net is catching everything it's supposed to — the only way to know for sure is to check submission_method, which is the whole reason this field exists now.

Frequently asked questions

Stop losing subscribers today

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