The Complete Guide to Chargeback Defense for Stripe Sellers

A chargeback starts when a cardholder asks their bank to reverse a charge instead of asking you for a refund. From that moment, the money leaves your Stripe balance, a dispute fee is usually assessed, a clock starts on your response, and the case will be decided by a bank analyst who has never heard of your business. Most sellers meet this process for the first time under pressure, with a due date a few days out and no clear idea what the submit evidence button actually expects from them. This guide exists to fix that. It walks through the whole lifecycle of a dispute, from the reason code the issuer assigns to the final decision, and explains what you can control at each step and what you cannot.

We are the small team behind DisputeLoom, a tool that packages Stripe dispute evidence, and we wrote this page because the questions we hear from sellers are remarkably consistent. Which disputes are worth fighting? What do banks actually read? Why did a packet with twenty attachments lose while a two-page response won? How do you keep a dispute rate low enough that your processor stops sending warning emails? The answers below are drawn from published card network rules, Stripe's own dispute documentation, and years of watching real cases play out. Where the honest answer is that it depends, we say so and explain what it depends on. Each section links to a deeper article, so treat this page as the map and those articles as the terrain.

How a Chargeback Moves Through the System

A chargeback is a rule-governed process rather than a customer complaint. The cardholder contacts the issuing bank, the issuer classifies the complaint under a reason code defined by the card network, and the network's rules then dictate who owes what, how long each party has to act, and what evidence counts. The funds are pulled from your Stripe balance provisionally, which is why a dispute shows up as a negative balance adjustment before anyone has looked at the merits. Stripe sits on the acquiring side of this chain: it receives the dispute from the network, passes it to you, and forwards whatever you submit back up the chain to the issuer. Understanding that Stripe is a conduit rather than the decision maker changes how you write your response, because the audience is a bank employee, not a Stripe employee.

The response step is formally called representment, and it is your only guaranteed opportunity to be heard. You either accept the dispute, which closes the case with the funds gone, or you submit evidence before the deadline shown in your dashboard. The issuer reviews your submission against the reason code and either reverses the chargeback, returning the funds to you, or upholds it. On some networks, an issuer that disagrees with a reversal can escalate to pre-arbitration and then arbitration, where the network itself rules and charges a fee that can exceed the value of a small transaction. In practice, for typical ecommerce and SaaS ticket sizes, the representment decision is the end of the road, so the packet you send at that stage carries all of the weight.

Two adjacent events are not chargebacks but matter just as much. An inquiry, sometimes called a retrieval request, is a bank asking for transaction details before deciding whether to file a dispute; a thorough and prompt reply can stop the chargeback from ever being created. An early fraud warning is a signal from the network that a cardholder has reported a transaction as fraudulent, and refunding that charge promptly often prevents the dispute from following. Both show up in Stripe alongside disputes, and sellers who treat them as low-priority notifications tend to convert avoidable situations into lost cases. The article on why most chargebacks are lost goes deeper into the structural reasons merchants struggle at each of these stages, and the reason code guide explains the classification that drives everything downstream.

Reason Codes Decide What Evidence Matters

Every dispute carries a reason code, and that code is the single most important piece of information in the case. It tells you what the cardholder claimed and, by extension, what the issuer's analyst is required to look for in your response. Visa groups its codes into four families: fraud, authorization, processing errors, and consumer disputes. Mastercard, American Express, and Discover use different numbering but cover the same ground. A code like Visa 10.4 (card-not-present fraud) means the cardholder says they never made the purchase, while 13.1 (merchandise or services not received) means they admit the purchase but say nothing arrived. Those two claims demand entirely different proof, and a packet written for the wrong one will lose no matter how thorough it is.

Stripe translates network codes into plain-language categories such as fraudulent, product not received, product unacceptable, subscription canceled, duplicate, credit not processed, and unrecognized. That mapping is useful for triage but hides nuance. A fraudulent label on a Visa transaction may be eligible for compelling evidence rules that let you show a history of prior undisputed purchases from the same customer with matching data points such as IP address, device, account login, or shipping address. The same label on a different network may follow different rules. Before writing a word of your response, look at the underlying network code in the dispute details, then decide what the analyst needs to see to overturn that specific claim rather than a general impression of your legitimacy.

Reason codes also tell you when not to fight. A processing-error code for a genuine duplicate charge, or a credit-not-processed code where you promised a refund and never issued it, is a case you should accept quickly and fix operationally. Fighting those wastes your time, irritates the issuer, and in some cases exposes you to a second dispute on the same order. The most effective sellers keep a short internal playbook: for each code they see regularly, a one-line statement of what the bank wants, the exhibits that satisfy it, and a rule for when to concede. Our guide to reason codes provides that mapping in detail, and the friendly fraud article covers the consumer-dispute codes that are most often misused by cardholders who simply did not recognize a charge.

Building an Evidence Packet That Gets Read

The person deciding your dispute is a bank employee working through a queue. They are not going to read twenty attachments, open an archive file, or reconstruct your argument from raw logs. Your packet has one job: make the case for reversal obvious within the first page. That means a short summary at the top that states the reason code, what the cardholder claimed, and the two or three facts that disprove it, followed by exhibits in the order the summary references them. Stripe compiles the fields and files you submit into a single document for the issuer, so the structure you choose is the structure the analyst sees. Sellers who lead with a cancellation policy screenshot instead of the delivery confirmation on a not-received dispute are making the analyst work, and analysts under time pressure tend to rule against work.

The right exhibits depend on the reason code and on what you sell. For physical goods facing a not-received claim, the core is carrier tracking with delivery confirmation to the address the customer provided, ideally one that matched an address verification check at checkout, plus signature confirmation for higher-value orders. For digital products and SaaS, it is access and usage logs tied to the customer's account, the IP address and device used at signup compared with those used at purchase, and the timestamped acceptance of your terms. For services, it is the scheduling record, the communication history, and any deliverables. For fraud claims, it is whatever links the buyer to the cardholder: matching billing details, a card verification match, prior undisputed orders, and, where available, authentication data from a 3-D Secure challenge.

Two habits separate packets that win from packets that lose. The first is relevance: include only what addresses the claim, and label each exhibit so its purpose is clear without explanation. Extra material does not add credibility; it dilutes the signal and pushes the decisive page deeper into the document. The second is tone. A response that argues with the cardholder, speculates about their motives, or complains about the process reads as emotional rather than factual, and analysts discount it accordingly. State facts, cite exhibits, and stop. The evidence packet article walks through a page-by-page template you can copy, and the piece on what banks look for explains the reviewer's checklist from the other side of the desk, including the details that quietly disqualify otherwise solid submissions.

Deadlines, Triage, and a Repeatable Workflow

The most common way to lose a winnable dispute is to miss the deadline. Stripe shows a due date on every dispute, and that date is the one that matters; the network's own window is longer, but Stripe needs time to forward your response, so the dashboard deadline already accounts for that. In practice, sellers often have somewhere between one and three weeks depending on the network, and the clock starts when the dispute is created, not when you first notice it. A dispute that lands on a Friday afternoon during a product launch is exactly as urgent as one that arrives on a quiet Tuesday. Building a process that notices disputes within a day and assigns an owner immediately is worth more than any improvement to the packet itself, because a perfect packet submitted late is simply a loss.

Triage comes next. Not every dispute deserves the same investment, and a good workflow decides within minutes which of three paths a case takes. Concede: the cardholder is right, the amount is small, or the reason code is one you cannot realistically overturn. Fight with a template: the case matches a pattern you have already documented, and the exhibits can be pulled from your order system with little custom work. Fight with care: the amount is significant, the facts are unusual, or the customer relationship is worth preserving, and someone should spend real time on the narrative. Writing those rules down, including the dollar thresholds and the reason codes that fall into each path, means the decision is made once rather than agonized over every single time a notification arrives.

A repeatable workflow has a small number of moving parts: a notification that reaches a person, a checklist per reason code, a library of standard exhibits such as your refund policy page and terms acceptance flow, a place to assemble and review the packet before submission, and a record of what was sent and what happened. Whether that lives in a shared folder, a spreadsheet, or a purpose-built tool matters less than whether it is actually followed under pressure. The deadlines article covers the specific timing rules by network and how to handle a case when the window is nearly gone, and the win-rate tracking article explains how to turn the record of past cases into better triage decisions over time.

Friendly Fraud, True Fraud, and Merchant Error

Disputes fall into three broad buckets, and treating them the same is a mistake. True fraud means a stolen card or compromised account was used, the cardholder genuinely did not authorize the purchase, and you shipped goods or granted access to a criminal. Merchant error means you made a mistake: a duplicate charge, an item that never shipped, a subscription that kept billing after cancellation, a refund promised but not processed. Friendly fraud, which the networks increasingly call first-party misuse, means a legitimate cardholder disputed a legitimate charge. Sometimes that is deliberate, an attempt to get something for free. More often it is confusion: an unrecognized billing descriptor, a family member's purchase, a forgotten trial that converted, or a customer who found disputing easier than emailing you.

Each bucket has a different best response. True fraud is usually not worth fighting unless you have strong authentication data or a compelling evidence history, because the cardholder really did not make the purchase and network rules favor them; the productive response is to tighten prevention. Merchant error should be conceded fast and fixed at the root. Friendly fraud is where evidence packets earn their keep, because the facts are on your side: the customer did receive the product, did agree to the terms, did use the service. The challenge is proving it in a form the issuer accepts, which means tying the purchase to the cardholder through data you collected at checkout and showing that the product or service was delivered as described and on time.

Because friendly fraud is so often rooted in confusion, the cheapest defense is to make the charge recognizable and the refund path easy. A clear statement descriptor with your brand name and a support phone number or URL, a confirmation email that arrives immediately, a renewal reminder before a subscription bills, and a refund policy generous enough to be used instead of the bank all cut first-party disputes at the source. When a dispute still arrives, the packet should quietly make the point that the customer had every opportunity to resolve this directly. Our friendly fraud article covers detection patterns and response strategies, and the article on why most chargebacks are lost explains how misclassifying these three buckets leads sellers to fight the wrong cases and concede the right ones.

Preventing Disputes Before They Are Filed

Every dispute you avoid is worth more than a dispute you win. A won case still cost you the response time, and whether the dispute fee comes back on a win depends on your processor's current policy; a case that never existed cost nothing and did not touch your dispute ratio. Prevention starts at checkout with clear product descriptions, visible shipping timelines, an upfront refund and cancellation policy, and explicit consent for recurring billing captured with a timestamp. It continues with transactional email that confirms the order, explains what the charge will look like on a statement, and gives a direct way to reach support. Sellers are often surprised how many disputes trace back to a customer who simply could not figure out who charged them.

Fraud screening is the second layer. Stripe's built-in risk tooling scores each payment, and adding your own rules for high-risk patterns such as mismatched billing and shipping countries, multiple cards from one device, or unusually large first orders will block a share of true fraud before it becomes a dispute. Address verification and card verification code checks should be enabled and their results stored, because they are both a filter today and evidence tomorrow. For higher-risk orders, requesting 3-D Secure authentication shifts liability for fraud-coded disputes to the issuer on most networks, although it does nothing for non-fraud claims and adds checkout friction, so apply it selectively to risky orders rather than to every customer.

The third layer is responsiveness. A customer who emails about a problem and hears nothing for three days will call their bank. Fast, generous resolution of complaints, including proactive refunds when a shipment is clearly delayed or a service failed, is the highest-return dispute prevention available to a small team. Watch inquiries and early fraud warnings in Stripe as leading indicators, and refund those charges when the facts support it, since refunding before a dispute is created keeps it off your ratio while refunding after does not. The prevention article details each of these layers with implementation notes, and the processor account article explains why your dispute ratio, not your win rate, is the number Stripe watches most closely.

Protecting Your Processor Account and Measuring What Matters

Winning individual disputes is tactical; keeping your processing relationship healthy is strategic. Card networks run monitoring programs that flag merchants whose dispute or fraud counts exceed defined thresholds relative to transaction volume. The exact formulas and percentages are revised periodically, and thresholds have historically sat around one percent of transactions, with fees, remediation plans, and eventually termination for merchants who stay above them. Stripe, as the acquiring party, bears the network penalties and passes the risk back to sellers through rolling reserves, payout delays, tighter review, or account closure. Critically, a dispute counts against your ratio when it is filed, regardless of whether you later win it, so the ratio can only be improved through prevention.

This is why a seller with a strong win rate can still be in trouble, and why refund-first policies that look expensive on a per-order basis are often the cheaper choice overall. When Stripe reaches out about elevated disputes, respond with a concrete remediation plan: what you changed at checkout, in fraud rules, in customer service, and in fulfillment, with the dates those changes shipped. Being terminated by a processor for excessive disputes can lead to placement on industry watch lists that make it hard to open an account elsewhere, so the stakes are higher than the immediate lost revenue. Treat processor communications about disputes as the most important emails your business receives, and answer them the same day.

Measurement closes the loop. At minimum, track dispute count and ratio by month, disputes by reason code and by product, response rate, win rate by reason code, net dollars recovered, and the time from dispute creation to submission. Those numbers answer the questions that matter: which products or flows generate disputes, which case types are worth fighting, and whether a change you made actually moved the ratio. A win rate that varies sharply by reason code is normal and useful; it tells you where to invest in evidence and where to concede. The win-rate tracking article suggests a simple reporting structure, and the processor account article covers reserves, monitoring programs, and how to have the conversation with Stripe when your numbers drift.

More guides on this topic

Further reading from the DisputeLoom blog, each answering one specific question in depth.

Chargeback defense is not a single skill but a set of connected habits: knowing the process, reading the reason code before responding, writing a packet the analyst can decide in one pass, meeting every deadline, sorting disputes into the right bucket, preventing the avoidable ones, and watching the ratio that your processor cares about. None of it requires a large team. It requires a written playbook, a place to keep the standard exhibits, and the discipline to follow the same steps when a dispute lands at the worst possible time. If you take one thing from this guide, make it this: the dispute you prevent is worth more than the one you win, and the one you win is decided on the first page of the packet. Start with the articles linked above, build the playbook for the two or three reason codes you see most often, and expand from there as your volume and your data grow.