ChargebackDesk · Checklists
The minimum-evidence checklists
For every Stripe dispute category we work to a minimum set of evidence — our acceptance standard: the least we need in hand before a response has a fair chance of holding up. These are the exact lists the free checker runs and every packet is checked against before a person signs it off. Below the minimum, we refuse the case and charge nothing.
Encoded from ChargebackDesk's Concierge Packet Templates (v1), which derive from Stripe's public dispute documentation; they are not yet validated against Stripe's per-dispute Dashboard guidance. Every item has a stable link (for example /checklists#me-f1) so you can cite it. Guidance, not a guarantee of any dispute outcome. Last updated 2026-10-14.
Fraudulent — "I didn't authorize this"
Stripe reason fraudulent · the guide · run this checklist on your dispute
| Code | Minimum item | Where to find it | Why missing it loses cases |
|---|---|---|---|
| ME-F1 | Post-purchase access event Do your records show at least one post-purchase access event — a login, license activation, lesson view, API call, or download — timestamped at or after the purchase? | Look in your LMS progress export, SaaS activity/audit log, license activation log, or download log. | This is the most important item for digital goods in this category. Without post-purchase use there is nothing tying the buyer to the product — the #1 refusal reason in this category. |
| ME-F2 | Purchase IP + access-log IP Is the purchase IP address present in your Stripe charge record, AND is at least one IP address present in your access logs? | An exact match is not required. IPs corroborate account activity only — they are never proof of who a person is. | With no IPs on either side there is no activity corroboration at all. Combined with a missing access log, the case cannot be built. |
| ME-F3 | Name and email from the charge Do you have the customer's name and email from the charge record? | Both appear on the charge in your Stripe dashboard. | The packet has to identify whose charge this is from the record itself — not from memory or a CRM note. |
| ME-F4 | Delivery proof tied to the buyer Can you prove delivery: a delivery/welcome email log, a license issuance record, or an account-creation timestamp on or after the purchase? | A mail-provider delivered/opened record is stronger than "we sent it." | If delivery can't be proven, the usage story has no foundation — issuers won't get past it. |
Subscription canceled — "I canceled and was charged anyway"
Stripe reason subscription_canceled · the guide · run this checklist on your dispute
| Code | Minimum item | Where to find it | Why missing it loses cases |
|---|---|---|---|
| ME-S1 | Cancellation policy as shown at signup Can you produce your cancellation policy exactly as it was shown to the customer at signup? | An archived page, a dated terms version, or a Wayback capture. A screenshot of today's edited page does not count on its own. | Issuers judge this category on the policy the customer actually saw. Without the signup-era version there is no case — the most common refusal here. |
| ME-S2 | One specific rebuttal, from records Can you support one specific rebuttal from records: (a) no cancellation request exists for the period, with the systems you searched named; (b) the request came after the billing date; or (c) the request was honored under the policy? | "The customer never canceled" without a stated search basis is not a rebuttal. | You need one of the three specific stories, with dates and ticket IDs. A general denial loses to a specific customer claim. |
| ME-S3 | How the buyer saw the policy Can you show how and when the buyer saw the cancellation policy at signup? | Signup checkbox, terms link placement, reminder emails — from your actual signup flow, not an assumption. | A policy the customer never had a fair chance to see carries little weight with issuers. |
Product not received — "I paid and got nothing"
Stripe reason product_not_received · the guide · run this checklist on your dispute
| Code | Minimum item | Where to find it | Why missing it loses cases |
|---|---|---|---|
| ME-P1 | Timestamped fulfillment record Does a timestamped fulfillment record exist: a delivery email with a mail-provider delivery/open log, OR an account/license created at or after purchase? | Check SendGrid/Postmark/Mailgun or your platform's delivery log — recipient, time, and delivered/opened status. | If no delivery record exists, the product may genuinely not have been delivered. The honest move then is not a packet: accept the dispute in Stripe (the customer already has the money back) and deliver the product. If it's still an inquiry, deliver or issue a full refund instead. |
| ME-P2 | Access after delivery, or delivered/opened proof Is there at least one of these: a post-delivery access event (login, download, activation), OR mail-provider confirmation of delivery (delivered/opened — not merely sent)? | Access after delivery is the strongest proof of receipt for a digital product. | Without either leg, the claim "they received it" is unsupported assertion. |
| ME-P3 | Delivery to the buyer on the charge Was delivery sent to the same email/account as the buyer on the charge? | Compare the delivery record's recipient with the charge's customer email. | Delivery to a different address than the charge email — without a buyer request for that address on file — usually ends the case. |
Product unacceptable — "not as described / defective"
Stripe reason product_unacceptable · the guide · run this checklist on your dispute
| Code | Minimum item | Where to find it | Why missing it loses cases |
|---|---|---|---|
| ME-U1 | Product description as purchased Is the product description as it appeared when the customer bought it available? | Archived sales/checkout copy or versioned docs from the purchase period — not today's edited page. | The as-purchased description is the comparison baseline for this entire category. Without it, there is nothing to compare the complaint against. |
| ME-U2 | Complaint answered, continued use, or documented refusal Do you have at least one of: (a) the complaint was investigated and answered in your support records; (b) the buyer kept using the product meaningfully after complaining; or (c) a refund was refused under a documented, pre-disclosed policy? | A resolved support ticket with the buyer's acknowledgment is the strongest single artifact in this category. | Without one of these, the complaint stands unanswered and uncontradicted — the hardest position in the category. |
| ME-U3 N/A allowed | Refund refusal fully documented If a refund was refused: do you have the refund policy as-shown, the disclosure record, AND a specific written refusal explanation citing the clause and the facts? | Answer N/A if no refund was requested or refused in this case. | "Per our policy" alone loses. A refusal needs the policy as the customer saw it, proof they saw it, and a specific explanation. |
Unrecognized — "I don't know what this charge is"
Stripe reason unrecognized · the guide · run this checklist on your dispute
| Code | Minimum item | Where to find it | Why missing it loses cases |
|---|---|---|---|
| ME-N1 | Product in plain, recognizable words Can you describe the product in plain words the cardholder would recognize? | "Online course: Python for Accountants — 40 video lessons" works. Internal SKUs and jargon don't. | This category is won by recognition, not argument. If the buyer can't recognize the product from the description, nothing else in the packet matters. |
| ME-N2 | The exact statement descriptor Do you know — and can you document — the exact statement descriptor the cardholder saw on their statement? | Found on the charge record / Stripe Settings → Public details. Exactly as issued. | The descriptor is the core question in this category. If you can't say what the cardholder saw, the case is unanswerable. |
| ME-N3 | An identity tie to the charge Is there at least one identity tie: the buyer's name, the buyer's email, or usage under the buyer's account? | Any one of the three is enough to anchor the recognition story. | With no tie between the charge and a person or account, there is nothing to remind the cardholder with. |
| ME-N4 | Documentation matches your entity Does your receipt/descriptor documentation match the merchant entity you actually sell under? | Watch for white-label or platform descriptors that belong to a different entity. | Documentation for the wrong entity can't be submitted — and a generic processor descriptor (e.g. just the processor's name) is a fix-your-descriptor problem, not a packet. |
Credit not processed — "the refund never arrived"
Stripe reason credit_not_processed · the guide · run this checklist on your dispute
| Code | Minimum item | Where to find it | Why missing it loses cases |
|---|---|---|---|
| ME-C1 | Which story is true, from records Have you determined, from records, which story is true: (A) the refund WAS processed, or (B) no refund was owed and the request was properly denied? | There are exactly two winnable stories in this category. Story A first: where the charge was fully refunded through Stripe before the dispute, Stripe's Smart Disputes can build the refund defense with no Smart Dispute fee, where Stripe offers it — check the dispute in your Dashboard before paying anyone for a packet. If neither story is clearly true, don't file a packet: accept the dispute in Stripe (the customer already has the money back). If it's still an inquiry, a full refund resolves it with no Stripe dispute fee; accepting an inquiry doesn't. | Hedging both stories at once destroys credibility. And if a promised refund was never sent, the cardholder is right — accept the dispute in Stripe; it has already returned the money, so don't refund it again. |
| ME-C2 N/A allowed | Story A: the refund record Story A — if the refund WAS processed: do you have the refund record: refund ID, amount matching the disputed amount (or documented proration math), and a timestamp before the dispute? | Answer N/A if no refund was issued (that's Story B). | The refund record is nearly the whole case in Story A. An amount or date that doesn't reconcile reads as an admission. |
| ME-C3 N/A allowed | Story B: policy, disclosure, written denial Story B — if no refund was owed: do you have the refund policy as shown at purchase, the disclosure record, AND the written denial referencing the policy? | Answer N/A if a refund was issued (that's Story A). | Story B stands on all three documents together. Missing the as-shown policy or the written denial ends it. |
| ME-C4 | The complete refund-request thread Do you have the complete refund-request communication thread — or a documented absence, naming the systems searched and the date range? | Complete means the whole thread, including anything unfavorable. | An unexplained gap where the refund conversation should be invites the issuer to believe the customer's version. |
General — bank-side / bucket reasons
Stripe reason general · the guide · run this checklist on your dispute
| Code | Minimum item | Where to find it | Why missing it loses cases |
|---|---|---|---|
| ME-G1 | Mapped to one substantive story Can this dispute be mapped to one substantive story? (debit_not_authorized runs the Fraudulent checklist in full; customer_initiated maps to the closest real category by what the dispute is actually about.) | If the exact reason is bank_cannot_process, check_returned, incorrect_account_details, or insufficient_funds, evidence cannot fix it — see the note above; those are refused by default. | A generic packet for a generic reason is unlikely to change the bank's decision, and responding still costs you Stripe's own fee. Without an identifiable story there is nothing to build. |
| ME-G2 | The mapped category's minimums, all met Are ALL of the mapped category's minimum-evidence items in place? (Run that category in this checker to verify.) | The mapped category's checklist applies in full — minimums and refusal triggers are inherited, not relaxed. | Partial evidence under the mapped category scores the same as it would in that category: below minimum. |
Duplicate charges (Stripe reason duplicate, Visa 12.6.1) have their own template, ME-D1 to ME-D3, described on the Visa 12.6.1 page; the checker does not yet run it as a category.