Stripe Can Now Appeal a Lost Dispute Through the API. Its Own Help Center Still Says You Can't.

Until September 30, 2026, a lost dispute on Stripe was the end of the conversation. You could respond once, with evidence, inside a 7-to-21-day window, and whatever the card issuer decided after that was final — no second round, no escalation, nothing left to do but eat the chargeback and move on. Stripe's own help center still says exactly that. Its changelog, as of the same date, says something different: there's now an API for appealing a dispute you've already lost.

That gap between a 44.6% win rate on contested disputes and a 10.7% net recovery rate overall is mostly explained by disputes merchants never fight in the first place, not by appeals — appeals barely exist yet for anyone. But it's the right context for why Stripe building a formal appeal path matters: losing a dispute has always been common, and until now, losing it was permanent no matter how strong your evidence was on the first try.

What actually shipped on September 30

The change is narrow and API-only — there's no new dashboard button to click yet. Stripe added an appeal object nested inside evidence on the Dispute resource, plus two new values for the dispute status field: appeal_needs_response and appeal_under_review. The mechanics follow the same shape as ordinary evidence submission, just one stage later in the dispute's life:

• reason_for_filing — a text field making the case for why the original decision should be reversed
• supporting_files — up to five file IDs, uploaded with the dispute_evidence purpose, the same pipeline you'd already use for a normal dispute response
• submit — a boolean on the update call. Leave it out or set it true and the appeal submits immediately; set it false to stage the reason and files first and submit later in a separate call

Submit it, and the dispute's status flips to appeal_under_review, at which point the appeal evidence locks — you don't get to keep editing your case while a network reviews it, any more than you could with a first-round response. Stripe's guidance is to watch the charge.dispute.updated event to catch the status change and whatever evidence deadline comes with it, rather than polling the API for it.

Why the help center and the changelog disagree

This isn't a documentation bug. It's a feature landing in preview before every surface that describes it has been updated. Stripe's lost-dispute FAQ is specific on this point: "the issuer's decision is final and cannot be appealed or challenged," and separately, that some card networks run an arbitration phase where a loss can be appealed for a substantial network fee, which Stripe says it "does not currently support." The changelog entry four months later is support for exactly that. Both pages are accurate for the moment they were written — the FAQ just hasn't caught up to an API shipped under the 2026-09-30.preview version yet, and preview means exactly what it says: expect it to move before it's generally available, and don't build a customer-facing promise on top of it today.

The eligibility gate is the detail easiest to miss on a skim of the changelog. You can't appeal on demand just because you disagree with a loss — Stripe's own note on the feature says to "use this feature only for eligible disputes with a status of appeal_needs_response," and that status is assigned to a dispute, not requested by you. It's the same pattern as two mechanisms Stripe already runs for narrower cases: Visa Compelling Evidence 3.0, which only kicks in for fraud disputes coded 10.4 and tells you via enhanced_eligibility_types when a specific dispute qualifies, and Mastercard compliance evidence, gated the same way. The new appeal field generalizes that pattern — a second look, but only when Stripe or the network has already decided your case is a candidate for one — rather than opening arbitration to every merchant who loses and wants another shot.

That last row is a genuinely new stage in the dispute lifecycle, not a reshuffling of an existing one. Before September 30, a dispute's status chart had three real endpoints: won, lost, or an inquiry that closed without becoming a formal dispute at all. Now there's a fourth path for a defined subset of losses, with its own status values and its own evidence hash that's walled off from the one you already used.

Where an appeal actually earns its cost

Dispute win rates vary enormously by category, and that spread is exactly why a general appeal mechanism matters more for some businesses than others. Industry data from Chargebacks911 and chargeback.io puts contested win rates like this:

A merchant losing fraud-coded disputes nearly five times as often as they win them is also the merchant with the most to gain from any new escalation path, assuming the network fee behind it is smaller than the disputed amount. For a $40 monthly SaaS seat, that math almost never works — the fee alone can exceed the charge. For a $4,000 annual enterprise contract disputed as fraud or "subscription canceled" — which is its own dispute reason code in Stripe's API, distinct from product-not-received or general — appealing a loss stops being a rounding error and starts being a real recovery decision. That's the practical filter: build the webhook plumbing for everyone, but reserve the actual appeal effort for disputes where the disputed amount clears whatever the network's arbitration fee turns out to be once Stripe publishes it.

What this changes for a SaaS billing team, and what it doesn't

It doesn't touch the first-round evidence problem at all. Our breakdown of Stripe's million-dispute evidence study is still the right place to start — a refund record and usage logs still move win rates more than anything an appeal can recover later, and the appeal path only exists downstream of a loss you could often have prevented with a better first response. It also doesn't change the underlying reason codes driving most SaaS disputes in the first place, which our chargebacks and failed payments guide and statement descriptor piece both cover — a subscriber who doesn't recognize a charge or forgot they were still paying for something is going to generate the same dispute whether or not an appeal exists on the back end.

What it does change is the cost calculus on a specific slice of losses: high-value, fraud-coded, or otherwise strong-on-the-merits disputes that lost anyway, where you now have a defined (if gated) path to contest the outcome instead of a hard stop. Three things worth doing before this leaves preview:

1. Wire charge.dispute.updated now. Appeal eligibility is a status change, not a dashboard alert you'll stumble on — if you're not watching for appeal_needs_response, you'll find out a dispute qualified after its evidence deadline passed.
2. Set a dollar threshold before you need one. Decide now, not mid-dispute, what disputed amount justifies pursuing an appeal against an unpublished network fee. A rule applied consistently beats a judgment call made under a deadline.
3. Keep your refund and usage-log pipeline separate from appeal evidence. The appeal hash is a different object from the standard evidence hash, locked independently once submitted — don't assume data that won you points on the first pass carries over automatically.

None of this moves the number that actually determines how many disputes you see in the first place, which is how clean your cancellation and refund experience is upstream of a bank call. A subscriber who finds your cancel button, or gets a fast refund directly from you, never generates the dispute an appeal would later be needed to fight. That's the same ground we've covered under involuntary churn generally — the cheapest dispute to win is the one that never gets filed. If disputes are already showing up as a meaningful slice of your reported churn, run the numbers through our churn calculator before you staff up an appeals process for a stage of the dispute lifecycle that, for most SaaS pricing, still won't clear the network's own fee to use it.

Frequently asked questions

Stop losing subscribers today

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