Stripe Dispute Evidence

Evidence is a set of named fields, not a folder of files

The evidence object carries a little over two dozen documented fields, and they split cleanly in a way that is useful to know before you start gathering anything.

Nine of them take a file upload: receipt, customer_communication, customer_signature, service_documentation, shipping_documentation, cancellation_policy, refund_policy, duplicate_charge_documentation and uncategorized_file. Everything else is a string, and several of the strings are what actually decide cases: shipping_tracking_number, shipping_carrier, shipping_date, service_date, access_activity_log, customer_purchase_ip, billing_address, product_description, cancellation_rebuttal, refund_refusal_explanation, duplicate_charge_explanation and uncategorized_text.

Stripe’s own description of shipping_tracking_number is the clearest argument for why the field name matters. When Stripe compiles your evidence into a single document, tracking numbers filed under that field are expanded to include detailed delivery information from the carrier. The identical tracking number pasted into uncategorized_text stays a string that a reviewer has to look up somewhere else, which they will not do. Filing evidence in the right field is the difference between a number and a delivery record.

That pattern repeats across the object. Fields exist so the network can read them, and the generic ones exist for everything that does not fit. Reaching for uncategorized_text first is the most common way to weaken an otherwise good response.

Which fields apply is a two-axis lookup

Stripe does not publish one evidence checklist. It publishes recommendations per dispute category, then splits each category again by product type, because the same claim needs different proof depending on what was sold.

The categories come from the dispute reason, which is the cardholder’s claim rather than your assessment: credit not processed, duplicate, fraudulent, general, product not received, product unacceptable, subscription canceled, unrecognized and noncompliant. The product types are physical products, digital products or services, and offline services. Stripe explains the split directly: physical goods call for evidence that the customer possesses the item, digital goods have no trackable shipping data so the focus moves to usage, login or download, and offline services are bought in advance, which is where a cancellation policy becomes material.

Take one claim through all three. For product not received on a physical product, Stripe recommends shipping_documentation, shipping_address, shipping_date, shipping_carrier and shipping_tracking_number, plus customer_signature where somebody signed at pickup or delivery. For the identical claim on a digital product, none of those exist, and the recommended set becomes access_activity_log with IP addresses and timestamps, alongside customer_purchase_ip, customer_name and customer_email_address. For an offline service it changes again, to service_date and service_documentation such as a signed contract or work order.

A subscription canceled claim ignores all of that and asks for three fields most merchants have never filled in: cancellation_policy as it was shown to the customer, cancellation_policy_disclosure explaining how and when they were shown it, and cancellation_rebuttal justifying why the subscription was not canceled, or why this particular payment is still valid even if it was.

This is why a standard evidence bundle underperforms. The documents are usually fine. They arrive in the wrong fields for the claim being made.

One submission, and the limits that decide what fits in it

Stripe states the constraint that shapes everything else in one line: you have only one opportunity to submit your response. Stripe forwards the response and all supporting files to the issuing bank immediately, and you cannot edit the response or submit additional files afterwards.

The mechanical limits follow from that. You can submit only one file per evidence type, so several documents of the same type have to be combined into a single multi-page file before you upload. Total evidence file size is capped at a combined 4.5 MB. For Mastercard, evidence is also capped at a combined 19 pages.

Stripe is equally specific about what reviewers will not look at. Banks evaluating a dispute do not review external content, which rules out audio and video files, requests to call or email for more information, and links to click through to, including tracking links and file downloads. Anything in that list is space you spent and nobody read.

Countering also has a price. A dispute countered fee applies on top of the dispute received fee. Stripe returns the countered fee if you win, and states that unless your contract says otherwise it never returns the received fee. The countered fee does not apply to businesses in Mexico and Japan. Once you have submitted, the bank’s review can take up to three months.

What Stripe fills in for you, and what you should not touch

Part of the evidence object is populated before you ever open the form. Stripe states that when your integration supports it, it automatically captures the data for the background sections and pre-populates both the API evidence attributes and the Dashboard form fields, covering shipping details, refund policy details, customer details and product details.

Two programs go further than that. For a fraudulent dispute that is Visa Compelling Evidence 3.0 eligible, Stripe provides most of the required evidence from your transaction history and badges the required fields in the response form. Stripe’s instruction there is worth following exactly: if a field is pre-populated, do not edit it, because editing it can affect eligibility. If it is empty, add what it asks for, such as the product description. Where the liability shift rule may apply, Stripe populates 3D Secure information including the Electronic Commerce Indicator automatically.

The general lesson sits underneath all of it. The fields Stripe can pre-populate are the ones your integration already collected at payment time, which means evidence quality is mostly decided months before any dispute arrives. Collecting a shipping address, a purchase IP and a product description at checkout is cheap. Reconstructing them inside a response window measured in days is not.