Stripe Just Started Enforcing a Dispute Evidence Page Limit. On Three Networks, There Isn't One to Enforce.

For as long as Stripe's Disputes API has existed, you could attach whatever evidence you wanted to a dispute response. Long text explanations, a dozen file uploads, a full PDF export of a support thread — Stripe took it, submitted it to the card network, and let the network's own reviewer deal with whatever showed up. Whether that evidence was even readable, formatting-wise, was your problem and the network's problem. It was never the API's problem. As of the 2026-09-30.endive and matching .preview releases, it is: Stripe now estimates the compiled page count of your evidence before it ever leaves the update call, and if it's over the network's limit, you get a 400 back instead of a submission.

What Stripe's changelog actually says

The entry is short and specific: "Stripe now validates the estimated compiled page count of evidence submitted when you update a Dispute. If the estimated page count of your text fields and file uploads exceeds the network page limit, the API returns a 400 error with the code dispute_evidence_page_limit_exceeded." The important clause is the one easy to skim past — this validation applies whether or not you set submit to true. That's deliberate. It means you can call Dispute#update with your evidence hash and submit: false purely to find out if you're over the limit, with nothing finalized and nothing locked, before you commit to a response you only get one shot at inside a 7-to-21-day window.

Stripe classifies this as a breaking change, and it is one in the narrowest possible sense: a request that used to return 200 now returns 400 for the exact same payload, if that payload happens to be long. Nothing about the evidence fields themselves changed — reason_for_filing-style text fields and file uploads still work the same way. What changed is that Stripe now runs an estimate against them before accepting the update at all, instead of passing everything through and letting the network's own reviewer silently truncate, reject, or dock you for a representment that doesn't meet its formatting rules.

The limit was never Stripe's. It was always the network's.

This is the detail that makes the change worth more than a changelog footnote: Stripe isn't inventing a page cap. It's finally checking one that card networks have published for years and that most merchants never saw enforced at the API layer. Checkout.com's dispute evidence documentation lays out exactly how uneven those limits are from network to network:

Only two networks in that table have a documented page count at all. Mastercard's 19-page cap predates this API change by years and already carries a real financial penalty for going over it — Checkout.com states the overage fee as 1 EUR per page past the limit, separate from Mastercard's right to reject the representment outright. Amex's limit is looser at 20 pages but tighter on file count, capping you at five files total regardless of how short each one is. Visa, JCB, and Diners/Discover don't publish a page cap at all — their constraint is pure file size, measured in megabytes, not pages. Stripe's changelog entry says the check compares your evidence against "the network page limit," singular, without spelling out what happens on a network that hasn't published one. The practical read: a Visa dispute with a dense but well-compressed evidence packet is far less likely to trip this error than the identical packet attached to a Mastercard dispute.

The spread matters because a single evidence pipeline that generates one PDF per dispute, regardless of which card issued the charge, is now a pipeline that behaves differently depending on which network the subscriber's card runs on. A packet that clears Visa's 10 MB ceiling without issue can still blow past Mastercard's 19-page cap if it's dense with screenshots rather than large files — page count and file size aren't the same constraint, and a packet can fail one without being anywhere near the other.

What actually fills 19 pages in a SaaS dispute response

Few teams building an evidence packet by hand sit down and plan to hit a page limit. It happens by accretion. A support ticket thread exported as-is runs long before anyone trims it. A usage-log pull meant to prove "the customer logged in three days before the disputed charge" turns into a full session-by-session CSV dump because that's what the query returns by default. A signed order form or terms-of-service acknowledgment gets attached as a 40-page master agreement instead of the one page the customer actually signed. None of this is wrong evidence — our breakdown of Stripe's million-dispute evidence study found refund proof and usage logs are exactly the right things to include. It's wrong packaging. The study measured what evidence types move win rates; it didn't measure what happens when the right evidence is buried in forty pages a Mastercard reviewer caps at nineteen before they've reached your strongest point.

Checkout.com's own guidance on this is blunt: attach the relevant excerpt, not the whole document. A single highlighted clause from a terms-of-service page proves the same thing as the full document and costs a fraction of the page budget. The same logic applies to session logs — a summarized table of login timestamps proves recent usage as well as a raw export, at a tenth of the length. If your evidence-generation code wasn't written with a page ceiling in mind, it's worth assuming it currently isn't.

What to change in your dispute pipeline before this bites

• Stage before you submit. Call the update with submit: false first, specifically to let Stripe's new validation run. If it returns dispute_evidence_page_limit_exceeded, you've found the problem before your one evidence window started counting down instead of after.
• Cap generated evidence at Mastercard's number, not Visa's. If one template produces evidence regardless of network, build it to the tightest constraint across the networks you actually see disputes on — which for most portfolios means designing around 19 pages, not around whichever network happens to have no stated limit.
• Summarize usage logs instead of exporting them raw. A table of login dates and feature access beats a full session export on page count and, per Stripe's own evidence study, isn't even the stronger version of that evidence type — a full refund record still outranks it by a wide margin.
• Update your error handling for the new code. dispute_evidence_page_limit_exceeded needs the same kind of explicit handling you'd already give card_declined on a payment — a silent retry with the same oversized payload will fail the same way twice.

This lands in the same category as the other breaking change we've covered from this release, Stripe's new dispute appeal API: a genuinely useful mechanism shipping quietly inside a version bump, easy to miss until an integration that worked unmodified for years starts throwing a 400 it's never seen before. Neither change affects why disputes land on a SaaS business in the first place — that's still the reason-code mess our chargebacks and failed payments guide covers, and the statement-descriptor confusion we've written about separately. What this one changes is whether the strongest evidence you have actually reaches a reviewer intact, or gets rejected by Stripe's own API before a human on the other end ever sees it.

A dispute that gets lost because the evidence was too long to submit is functionally identical, on your churn report, to one lost on the merits — the subscriber is still gone and the revenue still didn't come back. If disputes are already a meaningful slice of what shows up as churn once you add involuntary and voluntary losses together, our churn calculator is a quick way to see how much of that total is coming from chargebacks versus people who simply couldn't find a way to cancel. And for the subscribers who were never going to fight a charge and just wanted out, a cancellation flow like CancelFlow is still the cheaper save — it catches the cancellation before it turns into a dispute you'd otherwise need nineteen clean pages to win.

Frequently asked questions

Stop losing subscribers today

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