# Prepare chargeback evidence files that a reviewer can actually read [By Evidenz](https://evidenz.dev/) 5 min read An evidence attachment should explain one relevant part of the case without requiring a live dashboard or external link. Keep a readable export, identify the source and payment, check the provider’s current file and page limits, and inspect the exact version submitted. A dispute evidence file should let someone outside your company understand a relevant record without logging into your systems. An attachment full of clipped screenshots, unexplained event codes, or links to private dashboards does not become useful simply because the upload succeeds. Prepare the file for the reviewer’s task: understanding the specific claim and the records that address it. ## Choose the records before choosing the format Write down the disputed payment, the claim, and the question each attachment should answer. For a cancellation claim, that might be the request date, the effective date, and the renewal. For a service-access claim, it may be the entitlement and relevant delivery or access events. Keep the narrative separate from the source material. A short explanation can identify what a record shows and its limitations. It should not replace missing records with confident language. If your billing export does not contain the historical plan terms, adding a paragraph about today’s terms does not fill that gap. The [chargeback-evidence guide](https://evidenz.dev/articles/chargeback-evidence) covers selection in more detail. This page concerns the next step: turning selected records into an accurate, readable submission. ## Check the limits for this submission route [Stripe currently accepts PDF, JPEG, and PNG dispute attachments and sets a 4.5 MB combined file limit. Its guide also lists a 19-page Mastercard limit alongside a general combined-page limit below 50.](https://docs.stripe.com/disputes/best-practices) Do not treat the broader limit as permission to exceed a tighter network constraint. Check the current case form and documentation before exporting; these are Stripe instructions, not universal limits for every processor. For an API workflow, [Stripe distinguishes text evidence fields from fields that take an uploaded file ID](https://docs.stripe.com/disputes/api). Keep track of which file belongs to which field. A successful generic file upload does not establish that the file was attached to the dispute or that the response was submitted. The destination changes the file requirements. [Adyen's Customer Area guidance lists PDF, JPG, and TIFF and rejects material containing sensitive data such as full card numbers or passport copies.](https://docs.adyen.com/risk-management/manage-disputes) Those are Adyen instructions, not another name for Stripe's limits. Verify the actual submission route before exporting, and inspect the redacted artifact rather than only the source document. ## Build a compact packet with useful labels Start each attachment with a descriptive title and enough context to identify the payment, account, and period. Use stable identifiers consistently. An internal username on one page and an unexplained billing ID on another make the reviewer do the linking work. Number the pages and identify sections in ordinary language: invoice, cancellation request, support response, and relevant activity. If several messages are needed, show their dates and sequence. Remove repeated quoted email chains while preserving the context that changes their meaning. For logs, explain the event vocabulary. “Workspace export completed” tells a reader more than an undocumented code. Include the event time and timezone, relevant account link, and source. Distinguish customer actions from background jobs and support-agent activity. A table of raw events without those distinctions can imply activity that did not occur. ## Keep the contents inspectable Open the export at a normal reading size. Can you read the relevant amount, date, sender, and sentence without enlarging individual image fragments? Does the text remain understandable if color is unavailable? Is any annotation covering the original value? Use a restrained layout with sufficient contrast. Avoid shrinking a wide dashboard into a narrow page. Crop irrelevant interface controls, but preserve the labels and context needed to interpret the record. If a screenshot needs several paragraphs of explanation, a carefully labeled export may be clearer. Include the relevant content in the attachment rather than relying on an external link. A source link can help your internal audit trail, but it should not be the only place the decisive fact exists. Retain the original record internally so the exported excerpt can be checked. ## Redact without changing the story Remove unrelated personal data, secrets, access tokens, and other customers’ information. Make redactions permanent in the exported file rather than drawing removable shapes over text. Reopen the result and check what remains searchable or selectable. Preserve material that weakens the merchant’s position. A support reply acknowledging a billing error should not disappear because the attachment contains only the customer’s earlier agreement. Redaction protects irrelevant information; it should not manufacture a more favorable chronology. ## Review the final artifact, then confirm submission **Illustrative example.** A six-page support export contains the same quoted conversation three times. Removing repeated quoted text makes the sequence easier to follow; removing the customer’s cancellation request would change its meaning. The reviewer should be able to follow the original request, the reply, and the subsequent charge in order. Have a second person check that each attachment belongs to the correct payment and answers the recorded reason. Confirm size, page count, legibility, and the absence of unrelated records. Keep the exact final files and submission confirmation with the case. Work back from the [response deadline](https://evidenz.dev/articles/dispute-response-deadlines) so this check happens before the last available upload attempt. ## Give each attachment a reason to be there Evidenz's intended contribution to B2C and B2B SaaS reviews starts with the investigation behind the packet: connecting payment, account, support, and product history so a reviewer can explain why a record belongs to this case. For a personal subscription, the attachment needs a clear account-to-payment link. For a company workspace, it may also need to explain which members and service period the activity covers. A readable attachment should preserve those distinctions. Evaluate the underlying history before selecting excerpts, then check the final files against the provider's requirements. Source context, appropriate redaction, and submission confirmation still need their own review. ## Sources and scope Sources checked October 2026 Published by Evidenz. Examples are illustrative, not customer results. Check current requirements and the actual case against the linked sources. - [Stripe: Dispute evidence best practices](https://docs.stripe.com/disputes/best-practices) - [Stripe: Use the API to respond to disputes](https://docs.stripe.com/disputes/api) - [Adyen: Manage disputes](https://docs.adyen.com/risk-management/manage-disputes) Customer context is our starting point. Evidenz is being built for B2B and B2C SaaS: a shared customer history across subscription billing, accounts, support, and digital product activity. Join the waitlist for early-access news. [Join the waitlist](https://evidenz.dev/#hero) ## Keep reading [5 min read ### Chargeback evidence for subscription businesses](https://evidenz.dev/articles/chargeback-evidence)[6 min read ### How to respond to a chargeback, with a SaaS rebuttal letter example](https://evidenz.dev/articles/respond-to-chargebacks)[5 min read ### Chargeback response deadlines: work from the live case, not a day count](https://evidenz.dev/articles/dispute-response-deadlines) Canonical page: https://evidenz.dev/articles/preparing-dispute-evidence-files