Stripe Disputes, Chargebacks & Fraud: Fight Them and Prevent Them with Radar (2026)

What actually happens when a customer disputes a charge?

A dispute (the card networks call it a chargeback) starts when a cardholder asks their bank to reverse a charge. Stripe immediately pulls the disputed amount plus a dispute fee (~$15 as of 2026; confirm current) from your balance. You get a card-network window — usually ~7–21 days — to submit evidence; the issuer then decides in roughly 60–75 days whether you win or lose.

That’s the whole shape of it. Now here’s the sequence I’ve watched play out dozens of times with real money moving.

A dispute doesn’t start with you. It starts with the cardholder calling their bank and saying some version of “I didn’t make this,” “I never got it,” or “I was charged twice.” The issuer opens the dispute, and the first you hear about it is when money leaves your Stripe balance.

The cardholder files the dispute with their issuer — fraud, product not received, duplicate, subscription canceled, whatever the reason code says. Stripe then immediately withdraws the disputed amount plus a dispute fee from your balance. As of 2026 that fee is roughly $15 and it’s non-refundable — though note Stripe does not charge this dispute fee in Mexico (confirm current; this kind of thing changes). The money is gone the moment the dispute lands, before anyone has looked at your side.

You react to the charge.dispute.created webhook and get a card-network window to respond — usually around 7 to 21 days depending on the network and reason code. You submit evidence. Then the issuer evaluates it, which typically takes 60 to 75 days, and decides: you win or you lose.

If you win, the disputed funds come back to your balance. The original dispute fee generally does not come back. And under Stripe’s newer fee structure, a “dispute countered” fee can apply on top when you choose to fight (confirm current). So even a clean win is rarely entirely free.

The full mechanics are in Stripe’s how disputes work docs, and they’re worth reading once end to end so you internalize the timeline.

The brutal economics: why a dispute costs you even when you win

Let me be honest about the money, because the marketing version of this never is.

When a dispute hits, you don’t just risk the charge. You lose the goods or service you already delivered, and the funds are held throughout the 60-to-75-day evaluation. That’s a real cash-flow hit on money that was already yours. For a small SaaS or marketplace, having revenue frozen for two and a half months hurts more than the line item suggests.

Then there’s the fee. The roughly $15 dispute fee stays gone even when you win — it’s non-refundable. Here’s the nuance most people miss: if you contest, a separate ~$15 dispute-countered fee applies — but Stripe refunds that countered fee when you win the counter; only the original ~$15 dispute fee is permanently non-refundable. So a lost contested dispute can cost you ~$30 total in fees, while a won one leaves you down ~$15 (confirm current).

Do the math on a $20 charge: you “win,” you get your $20 back, you’re still down the original ~$15 fee plus the time you spent assembling evidence. You won and you barely netted positive — and if you’d lost the contest, the fees alone would have exceeded the charge. That asymmetry is the whole triage decision.

It gets worse at scale. High dispute ratios push you toward the Visa and Mastercard monitoring programs, which carry their own fines and put your account standing at risk. That’s an existential problem, not a line-item one — losing your ability to process cards is far more expensive than any single chargeback.

My opinion, formed by actually running this: below a certain ticket size, fighting costs more in fees and time than the charge is worth. Triage which disputes you contest. And recognize that all of this math is exactly why prevention beats fighting — which is where the rest of this post lives.

How do I respond to a dispute with evidence (and actually win)?

When you do decide to fight, treat charge.dispute.created as the source of truth. Not an email, not a dashboard glance — the webhook event. (If you’re fuzzy on why events beat polling for this kind of thing, I wrote up webhooks vs polling vs the API.) Wire that event to a handler that opens an internal task and pulls the full order context so a human or your automation can act fast.

// POST /webhooks/stripe — verified Stripe webhook endpoint
import Stripe from "stripe";
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

export async function handleStripeEvent(event) {
  if (event.type === "charge.dispute.created") {
    const dispute = event.data.object;
    console.log("Dispute opened", dispute.id, dispute.reason, dispute.amount);

    // Pull order context and queue evidence assembly
    const charge = await stripe.charges.retrieve(dispute.charge);
    await openDisputeTask({
      disputeId: dispute.id,
      reason: dispute.reason,                  // match evidence to this reason code
      dueBy: dispute.evidence_details.due_by,  // also: has_evidence, past_due
      customerEmail: charge.billing_details?.email,
    });
  }
}

Then submit organized evidence. The reason code tells you what the issuer wants to see, so match the evidence to it: receipt, customer communication, delivery or usage logs, the IP address, AVS and CVC results, and the refund policy the customer agreed to at checkout. Stripe’s data is consistent — better-organized, well-matched evidence wins more often. Vague evidence loses.

You submit through the Dashboard or via the API with stripe.disputes.update, attaching an evidence object (customer_email_address, receipt, shipping_documentation, uncategorized_text, and so on), then submit before the deadline.

One thing Stripe added that’s genuinely useful: Smart Disputes, part of Radar’s dispute management. Its AI can auto-assemble and submit evidence for you, which both reduces dispute rates and helps keep you out of network monitoring programs. I still want a human eyeing the high-value ones, but for the long tail of small disputes, letting it run is a sane default.

Whatever you do, respond well before the deadline. When the window closes, you forfeit by default — no evidence, automatic loss.

Stripe Radar: blocking fraud before it becomes a chargeback

The cheapest dispute is the one that never happens. That’s Radar’s job.

Stripe Radar is ML fraud detection trained across Stripe’s entire network — every transaction it’s ever seen informs the score on yours. It’s included at a baseline, and it scores each payment and can block or flag risky ones before they ever settle. You get a meaningful layer of protection for free just by being on Stripe.

Radar for Fraud Teams is the paid upgrade. It adds custom rules, allow and block lists, and manual review queues at an additional per-transaction fee (see Radar pricing; confirm current). If you’re a Connect marketplace, there’s also Radar for Platforms.

The rules I actually run:

• Block or send a 3DS challenge on high-risk scores
• Flag payments where AVS or CVC don’t match
• Rate-limit by IP and email to kill card-testing bursts
• Allow-list known-good customers so I don’t punish my best buyers with friction

One opinionated warning: tune your rules against your real false-positive cost, not just your fraud cost. Over-blocking quietly kills good revenue, and that loss is invisible in a way a chargeback never is. A blocked legitimate customer doesn’t email you — they just leave. Watch your decline rates as carefully as your dispute rate.

3D Secure and SCA: the liability shift that ends fraud disputes

If you take one thing from this post, take this: 3D Secure is the single biggest lever you have.

Authenticating a payment with 3D Secure shifts fraud liability to the card issuer. If a 3DS-authenticated payment is later disputed as fraudulent, you are typically not liable — the issuer eats it. If 3DS isn’t used, fails, or isn’t available, you stay liable. That’s the whole game for fraud disputes. Stripe can even auto-attach the 3DS authentication data as evidence on liability-shifted disputes, so the win is largely automatic.

Here’s the part people leave on the table: SCA already requires 3DS for many EU payments. If you’re authenticating EU transactions out of compliance obligation but not using 3DS anywhere else, you’re skipping free liability protection on the rest of your traffic.

You request it on the PaymentIntent:

const paymentIntent = await stripe.paymentIntents.create({
  amount: 4999,
  currency: "usd",
  payment_method_options: {
    card: { request_three_d_secure: "any" }, // force 3DS authentication
  },
});

But don’t force it on every transaction. 3DS adds a step, and friction costs conversion. The best play is to trigger 3DS selectively on Radar-flagged risky payments via a Radar rule — clean traffic sails through, suspicious traffic gets challenged and liability-shifted.

And know the limit: the liability shift covers fraud disputes only. It does nothing for “product not received” or “not as described.” Those still come down to receipts, clear delivery records, and good communication. 3DS ends one whole category of disputes; it doesn’t end all of them.

The prevention stack I’d actually run

Here’s the order of operations I’d implement, top to bottom. Each layer catches what the last one missed.

1. Radar rules first. Block the obvious fraud, flag the gray zone for review, and allow-list your known-good customers so you don’t add friction where it’s not needed.
2. 3DS on risky payments. Route Radar-flagged transactions through 3D Secure to shift fraud liability to the issuer. Selective, not blanket.
3. A clear billing descriptor. A huge share of “I don’t recognize this charge” disputes come from a cryptic statement line. Set a descriptor your customer will actually recognize — your brand name, not a holding-company acronym.
4. Good receipts and communication. Timely receipts, a visible refund policy, and easy support so an unhappy customer asks you for a refund instead of calling their bank. A refund costs you the sale; a dispute costs you the sale plus the fee plus your account standing.
5. A fast evidence pipeline. For the disputes that slip through anyway: charge.dispute.created → auto-assemble (Smart Disputes or your own assembler) → submit before the deadline.

The throughline: keep your dispute ratio under the Visa and Mastercard monitoring thresholds. Prevention doesn’t just save individual charges — it protects your account standing, which is the thing you actually can’t afford to lose. This sits right next to dunning as a revenue-leak you should plug; if you haven’t, I covered the other leak in recovering failed payments with Stripe dunning.

FAQ: Stripe disputes, chargebacks and fraud

Do I get the dispute fee back if I win? The original ~$15 fee is non-refundable even on a win. If you also incur a dispute-countered fee for contesting, Stripe refunds that countered fee when you win the counter (confirm current). The original fee is also not charged in Mexico.

How long do I have to respond to a Stripe dispute? Usually around 7 to 21 days, set by the card network and reason code. The issuer then decides in roughly 60 to 75 days.

Does 3D Secure stop all chargebacks? No. It shifts liability on fraud disputes only — not “product not received” or “not as described.” Those still need receipts and delivery evidence.

Is Stripe Radar free? Baseline Radar is included. Radar for Fraud Teams adds custom rules, lists, and review queues at an additional per-transaction fee — see Radar pricing for current numbers.

What’s the difference between a dispute and a chargeback? A chargeback is the card-network mechanism. In Stripe you handle it as a dispute on the charge — same event, Stripe’s terminology.

Should I fight every dispute? No. Below a small ticket size, the fees and time usually exceed the charge — and a lost contest can cost you ~$30 in fees. Triage which ones are worth contesting.

The honest takeaway

Fighting disputes is damage control. You’ll lose the original fee even when you win, you’ll wait two months for your own money, and you’ll burn hours assembling evidence. It’s necessary sometimes, but it’s never where the wins are.

The real wins are all upstream: Radar rules to block fraud, 3DS to shift fraud liability to the issuer, a clear billing descriptor so customers recognize their charge, and good receipts so they ask you for a refund instead of their bank for a chargeback. Set this up once and watch your dispute ratio — and your stress — drop. This is the system I run with real money moving through it, and it’s a layer above the basics in how to integrate Stripe into your SaaS. If you’re running a marketplace, the same prevention logic layers onto Stripe Connect for marketplaces.

If you want this wired into your Stripe stack correctly — Radar rules tuned to your real false-positive cost, selective 3DS, and an evidence pipeline that actually submits on time — that’s exactly the kind of thing I build.