Chargeback evidence checklist for fraud and other claims

For a fraud chargeback, first verify whether the case says the cardholder did not authorize or participate in the transaction. Then build a short chain from checkout verification to account continuity and fulfillment or use. Do not treat a long packet, a fraud-tool score, or ordinary repeat-order history as proof by itself.

Fraud chargeback evidence: start here

Read the case label before choosing a template. Shopify distinguishes a fraudulent claim, in which the cardholder says they did not authorize the transaction, from an unrecognizedclaim, in which the customer does not recognize the merchant name or location on the statement. Your processor might group or name these differently, so the individual case view still controls.

Worked fraud-packet example

Suppose a digital-subscription case is coded as card-not-present fraud. The team has a 3D Secure result, the purchase IP, a verified account login from the same device after the charge, dated service-usage logs, and a support message about the subscription. The cover statement can link those events chronologically. The support message belongs in the context section; it should not be described as identity verification.

Classify the case before collecting documents

Create a one-page case record before asking other teams for evidence. The processor or platform view for the individual dispute controls; a label used in your internal fraud system is not a substitute for the network reason shown in the case.

• Case identity: processor case ID, order ID, transaction date, disputed amount, and currency.
• Claim: displayed dispute category or reason code and the issuer's explanation, when one is available.
• Deadline: portal due date, time zone, internal review buffer, evidence owner, and final submitter.
• Transaction type: physical goods, digital goods, service, subscription, or a mixed order.
• Decision: accept the claim or challenge it. Do not manufacture a packet when the customer's claim is valid.

Shopify says issuer claims are not available for every dispute, because availability depends on the issuer and network. If no detailed claim is present, document that limitation and work from the displayed reason and the fields requested by your processor.

Map the reason to the record groups that answer it

There is no universal document bundle for successful representment. Stripe, Shopify, and Adyen all organize defense guidance around the displayed reason or claim, while Adyen's live dispute API can mark document groups as required, one-of-several, optional, or an allowed alternative. Use this map to route the request internally, then replace it with the exact fields and requirement levels shown for the case.

These are intake record groups, not card-network requirements. Visa and Mastercard publish condition-specific rights and documentation rules, and a processor can translate them into different merchant-facing fields. The reason code, region, payment method, transaction type, and live case instructions control.

Use a required-record coverage gate

Before writing the rebuttal, copy every required field or required document group from the live case into a packet manifest. Give each one a status of provided or missing. Keep optional material outside the denominator, and mark a field not applicable only when the case instructions allow that treatment.

Worked packet-gate example

A case shows five required groups. The team has satisfied four, but the delivery file omits the full destination address. Required-record coverage is 4 ÷ 5 = 80%, so the packet is not reviewer-ready. An optional customer message does not change the denominator and cannot substitute for the missing delivery field. The owner must obtain a compliant record or escalate the gap before the internal cutoff.

Adyen's requirement levels make this distinction explicit in its API, but the same control works in a manual portal: capture what the case requires, assign an owner, link the supplied file, and stop the submission when a required group remains missing.

Use a four-stage evidence workflow

Worked deadline example

Suppose the processor portal shows a deadline of Friday, August 14, 2026. The operations lead requires two business days for review. The internal evidence-owner cutoff is Wednesday, August 12. The owner gathers records and resolves gaps before that cutoff; the reviewer uses the remaining window to check the narrative, attachments, and portal fields.

This example is an operating convention, not a network deadline. Use the date and time shown for the actual case, allow for local holidays and time zones, and submit earlier when your platform stops edits after submission.

Match records to the dispute reason

The goal is not to prove that the business is generally trustworthy. It is to answer this issuer claim about this transaction. Shopify's current guidance likewise separates evidence by dispute type, and Visa lists different allowable evidence for different dispute conditions.

Fraudulent or unrecognized transaction: packet recap

• AVS and CVV results, plus any 3D Secure authentication record
• Purchase IP, device data, and account login or usage history
• Delivery or service-use evidence tied to the customer or address
• Eligible prior undisputed transaction history that meets the processor and network criteria for the case

Keep the two claims distinct even when the available records overlap. For an unrecognized claim, add the billing descriptor and merchant name shown at checkout or on receipts when the portal accepts them. For a fraud claim, lead with the authorization and participation evidence summarized above.

Product not received

• Order confirmation and the shipping address supplied at checkout
• Carrier, tracking number, ship date, and delivery status
• Full delivery address and signature or delivery photo when available
• Delivery notifications and relevant customer communications

For digital goods, replace carrier evidence with access logs, download or license delivery, IP or device data, and timestamps. For services, use booking, check-in, work-completion, or customer-acknowledgment records. A physical-shipment template does not fit every product.

Product unacceptable or not as described

• Product listing or specification as it appeared at purchase
• Order, fulfillment, serial-number, and quality-control records
• Support history and the customer's description of the problem
• Return or resolution offered, with the applicable accepted terms

Subscription canceled

• Terms accepted at signup, including billing cycle and renewal
• How and when cancellation terms were presented and accepted
• Renewal notice, payment receipt, and cancellation-system records
• Service usage after the disputed charge, when relevant

A policy screenshot is useful only when it shows the terms that applied to that purchase and how the customer accepted them. A current policy page or a link to a website can fail to show what the customer saw at checkout.

Credit not processed or duplicate charge

• Refund or reversal record with amount, date, and processor reference
• Return tracking and relevant refund communications
• Transaction logs, order IDs, timestamps, receipts, and item details that distinguish separate purchases
• A clear explanation when one entry was a temporary authorization rather than a second settled charge

Build a reviewer-friendly packet

Put a short cover statement first: identify the order, state the claim, state the response, and point to the records that support it. Then place those records in event order. Label each exhibit with what it proves; remove duplicate email chains and unrelated policy pages.

Run the final quality gate

Reconcile the packet against its manifest before the named reviewer approves submission. A complete packet can still be unpersuasive, so every check below must pass in addition to 100% required-record coverage.

• Claim match: every attachment answers the displayed reason or issuer claim.
• Chronology: dates, amounts, order IDs, names, and events agree across the cover statement and exhibits.
• Legibility: screenshots are cropped, high contrast, and readable without relying on color alone.
• Policy proof: the packet shows the relevant terms at purchase and how the customer accepted them.
• Portal limits: file type, page count, size, and one-file-per-field rules are checked against the current platform.
• Submission control: a named reviewer approves the packet, a named submitter sends it, and the confirmation is retained.

Platform limits are not universal. As of this review, Stripe and Shopify publish different combined-file limits, and Shopify also publishes per-file constraints. Follow the current rules shown by the processor handling the case rather than copying a number from this or any other general checklist.

If the claim is renewed, build a delta rebuttal

This checklist owns the first evidence packet. If the issuer or provider reopens the case after reviewing it, do not resend that packet unchanged. Open the original submission beside the new issuer explanation, record what changed, and verify whether any omitted record can still be considered in the live workflow. Then use the chargeback pre-arbitration process and decision guide to build a delta rebuttal only when the case exposes a merchant action. Mastercard's current merchant guide shows why this distinction matters: in multiple flows, documentation required earlier might not be considered when it is first added at pre-arbitration.

What this checklist cannot decide

Relevant evidence does not guarantee recovery. Shopify says strong evidence can still lose, and Visa states that compelling evidence does not require Visa or an issuer to conclude that the cardholder participated or benefited. Network, region, reason code, transaction type, and processor workflow can change both the response rights and acceptable evidence.

This guide starts after the decision to use representment. If the team has a formal case but has not decided whether the response is worth building, use the fight-or-accept chargeback decision formula. If the team is still deciding between early-resolution alerts and a formal dispute response, use the alerts versus representment guide. If the question is whether software or managed services can pay for themselves, use the automation break-even model. To improve the records available before the next case exists, use the chargeback prevention checklist.