A chargeback evidence checklist should change when the dispute reason changes. The universal portion is small: identify the transaction, show what the customer agreed to, and preserve the processor deadline. Everything else should be selected because it proves or disproves the issuer’s specific claim. For a condition 13.3 or similar not-as-described allegation, see the not-as-described chargeback guide for the transaction comparison and return history. For a Visa 13.6 refund or void dispute, use the credit-not-processed chargeback checklist. Visa condition 10.4 has an additional prior-purchase route; use this Visa CE 3.0 evidence checklist only when the network reason code qualifies.
Universal case cover sheet
Put these facts at the top: - merchant/order number; - processor dispute ID; - transaction date and amount; - customer name or account; - network reason code and issuer claim as shown in the processor portal; - response deadline; - refund status; - one-sentence position: accept or contest and why.
Then list only the exhibits you will submit. This cover sheet is internal as well as useful for drafting: it prevents a team member from mixing two disputes for the same customer.
Fraud / card-not-present packet
Potentially relevant: - order details and checkout timestamp; - AVS/CVC or 3-D Secure result exposed by the processor; - billing and shipping details; - IP/device/session evidence; - account history; - prior undisputed orders using matching identifiers; - customer communications; - delivery or usage proof.
Do not claim that an IP address conclusively identifies the cardholder. The useful question is whether multiple independent facts connect the transaction to an established customer relationship or authorized use.
The right records depend on what the cardholder disputed; this is an organizing aid, not a universal checklist.
Product not received packet
For physical goods: - carrier and tracking number; - delivery date/time; - address used at checkout; - signature or delivery photo when available; - shipment confirmation sent to customer; - carrier investigation or customer conversation.
For digital goods: - account identifier; - access/login event; - download/stream/use timestamps; - IP/device where relevant; - entitlement activation; - customer support interactions.
For a service claim, include the booked appointment or scope, attendance/completion record, work log, and any customer acknowledgment. Shopify likewise distinguishes physical tracking, digital access logs, and service-completion records.
Worked example: a $420 service visit
Assume a fictional repair visit has a $60 diagnostic charge, $240 in labor, and a $120 replacement part: $60 + $240 + $120 = $420. The cardholder disputes the $420 as a service not provided. The merchant’s narrow evidence set could include the appointment confirmation, an itemized work order showing the same $420 components, the technician’s dated completion record, and a customer message acknowledging that the repair was finished. Each item answers a different question: what was agreed, what was charged, what work occurred, and what the customer later said. A generic policy page or unrelated account history adds little if it does not address this claim.
This is an illustrative record-matching example, not a result prediction. The total confirms that the sample invoice adds correctly; it does not establish that a real case meets a network rule or that the issuer will rule for the merchant. Follow the processor’s live form, accepted evidence types, deadline, and exact dispute reason.
| Physical goods | Digital goods | |
|---|---|---|
| Core record | Carrier/destination/delivery | Account/entitlement/access |
| Customer link | Checkout address | Account ID and timestamp |
| Weak substitute | Bare delivered scan | Receipt without access evidence |
Not as described / defective packet
Include the exact product page or proposal version the customer saw, order/SKU, specifications, photos, return policy, complaint, troubleshooting/replacement offer, and return tracking if any.
A generic current product page is weaker if the description changed after purchase. Preserve versioned sales material when possible.
If the product was defective and you refused a valid remedy, the evidence may support accepting the dispute rather than fighting it.
Select the folder that answers the notice; not every case calls for every document.
Incorrect amount / general packet
Compare the itemized order total with the amount authorized and settled. Show the price displayed at checkout, taxes, shipping, conversion or other fees, and the processor transaction record that explains the final charge. If the claim is about a temporary authorization, show its status and whether it cleared; do not call it a duplicate solely because a pending hold and a settled charge appeared together.
Canceled recurring packet
Use signup and renewal facts: - subscription start; - accepted recurring terms; - billing frequency; - cancellation policy; - cancellation request timestamp; - effective cancellation timestamp; - disputed renewal timestamp; - pre-renewal notice where applicable; - post-renewal usage.
The timeline is the argument. If cancellation was valid before the charge under your terms, contesting is usually weak.
Duplicate / paid by other means packet
Put the two alleged transactions side by side: - processor transaction ID; - order number; - amount; - timestamp; - items/service period; - settlement status.
If both settled for the same order, refund or accept as appropriate. If they are two separate purchases, make the differences impossible to miss.
Credit-not-processed packet
Show return/cancellation date, refund policy, refund authorization, processor refund ID, refund date/amount, and customer notification.
If the credit was issued before the dispute, provide evidence of the actual credit transaction. A screenshot that says “refund queued” is weaker than a processor record showing it settled.
| Dispute type | Core evidence to lead with | Caution from the guide |
|---|---|---|
| Fraud or card-not-present | Order details and checkout timestamp, AVS/CVC or 3-D Secure results the processor shows, billing and shipping details, account history, prior undisputed orders with matching identifiers | An IP address does not conclusively identify the cardholder; connect the transaction through several independent facts |
| Product not received | Carrier and tracking number, delivery date and time, address used at checkout, signature or photo; for digital goods, login and download or use timestamps; for services, the scope and completion record | Match the proof to physical goods, digital goods, or services |
| Not as described or defective | The exact product page or proposal version the customer saw, SKU, specifications, photos, return policy, complaint, and any replacement offer | A page that changed after purchase is weaker, so preserve versioned sales material |
| Incorrect amount | The itemized total compared with the amount authorized and settled, plus taxes, shipping, fees, and the processor record | Do not call a pending hold and a settled charge a duplicate |
| Canceled recurring | Subscription start, accepted terms, billing frequency, cancellation request and effective timestamps, renewal timestamp, pre-renewal notice, post-renewal usage | If the cancellation was valid before the charge, contesting is usually weak |
| Duplicate or paid by other means | The two transactions side by side with IDs, order numbers, amounts, timestamps, and settlement status | If both settled for the same order, refund or accept as appropriate |
| Credit not processed | Return or cancellation date, refund policy, refund authorization, processor refund ID, date and amount, customer notice | A "refund queued" screenshot is weaker than a processor record showing it settled |
Evidence formatting QA
Before submission: - every screenshot shows context; - dates/time zones are understandable; - the narrative points to exhibit numbers; - no contradictory refund or cancellation record is omitted; - the filed reason code and claim text match the cover sheet.
Save exactly what was submitted. Also capture the processor portal’s evidence category and submission deadline before drafting. Reason labels vary across networks and processors. If an internal label differs from the issuer’s claim or portal reason, use the portal’s wording and check the network-specific evidence instructions.
A merchant reviews the dispute reason, organizes relevant records, follows processor instructions, and saves a copy.
Build the packet in the order a reviewer can verify it
A practical evidence packet usually begins with the transaction: order identifier, amount, date, payment method reference, customer identity information, and the dispute reason. Next comes proof tailored to that reason. Delivery disputes need delivery proof; cancellation disputes need cancellation terms and usage after the alleged cancellation; duplicate disputes need two distinct orders or proof one of the apparent duplicates was voided.
Add the customer-facing terms that were actually accepted. Screenshots should show where the term appeared during checkout, not only a policy page that a customer might never have seen. When the processor accepts text explanations, point to each exhibit rather than restating the entire story.
Build a short index that names each exhibit and the fact it proves. Remove internal notes and unrelated history; retain one complete internal copy of the final upload and the submission time. Check the processor’s current file-size, page, and type limits before exporting.
Check legibility before upload
Export evidence at readable resolution and verify dates, amounts, names, and tracking numbers are visible after the processor compresses the file. Do not rely on color alone to identify exhibits. A one-page index naming each exhibit can help when the portal permits it, but the decisive evidence should still be understandable on its own.
Exclude sensitive data that proves nothing
Do not upload full card numbers, unrelated identity documents, or private account history merely to make the packet look substantial. Use the minimum information needed to connect the customer, transaction, and disputed event under the processor's rules.
