Three similar-sounding outcomes on card payments—who triggers them, when they happen in the payment timeline, and what they mean for your product and metrics. This cheat sheet helps you reduce disputes and choose the right “undo” path for each scenario.
The quick take
Freshness note: accurate as of 26 Sep 2025.
Refund — You (the merchant) send the money back after capture/settlement. Fast to execute, keeps fees lower, and avoids a dispute on your ratio.
Reversal — You void a still-pending authorization before capture/clearing, so funds are simply released. Think “undo the hold.”
Chargeback — The cardholder’s bank pulls funds back after the transaction posts, usually following a complaint. Costly, slow, and it hits your dispute metrics.
How card payments flow (and where each “undo” fits)
Auth → (optional) Multiple Captures → Clearing → Settlement → Funding.
Reversal (void): Between Auth and Clearing. If you haven’t captured yet (or can still void), cancel the auth. The hold falls off the card on the issuer’s timeframe (commonly 1–7 business days, varies by bank and geography).
Refund: After Capture/Settlement. You create a credit (full/partial). Your acquirer submits it, the network delivers it, and the issuer posts it to the card.
Chargeback: After Settlement. The issuer initiates the dispute with a reason code (e.g., fraud, goods not received, not as described). You can fight it via representment with evidence.
Tip: If you can solve a customer issue with a refund quickly, do that. It’s cheaper than a chargeback and keeps ratios healthy.
Who starts it—and who pays
Reversal — Initiated by merchant/acquirer; minimal fees; fastest customer experience because no posted debit to “undo.”
Refund — Initiated by merchant; you eat the interchange/processing already paid; still cheaper than a dispute.
Chargeback — Initiated by issuer/cardholder; you pay dispute fees, ops time, potential penalties, and you risk program thresholds if ratios rise.
Reason codes, pre-dispute tools, and representment (lightweight)
Reason codes categorize why the issuer pulled funds (fraud, processing error, canceled recurring, etc.).
Pre-dispute resolution (e.g., network programs like Order Insight/VMPI) lets issuers ping you for immediate details or a proactive refund to stop a chargeback before it starts.
Representment: If you have strong evidence (delivery proof, refund logs, usage/IP/device data, terms acceptance, 3-D Secure, photos), you can contest and try to win the funds back.
Reality check: Winning the dispute doesn’t always mean winning the relationship. Use representment for clear, documentable cases; issue refunds when the evidence is weak.
Metrics to track (and how product can move them)
- Dispute/chargeback rate (count or basis points). Keep within program thresholds.
- Win rate (representment success). Track by reason code and processor/network.
- Refund rate (and time-to-refund). Faster refunds → fewer disputes.
- Pre-dispute deflection (where available). Measure how many cases you prevent.
- Cycle time: Days from dispute to resolution; drives support cost and CSAT.
- False declines vs. chargebacks: Tighten risk too much and you lose conversion; too loose and disputes rise—find the balance.
Product checklist: prevent disputes before they start
- Crystal-clear checkout: Legal name + doing-business-as, phone, and recognizable descriptor on statements.
- Receipts & notifications: Immediate email/SMS with order details, realistic ETAs, and simple “need help?” paths.
- Shipping and proof: Track-and-trace links, delivery confirmation, signature for high-risk SKUs, photo-on-delivery where possible.
- Content & visuals: Accurate photos, variations, and policies (returns, cancellations) in plain language.
- Refund UX: Self-serve portal, partial refunds, automated status updates (“refund initiated,” “posted by your bank in X days”).
- 3-D Secure & risk tuning: Use step-up only when needed; whitelist loyal customers; log device/IP; align rules by product and ticket size.
- Subscriptions: Clear billing cadence, pre-renewal reminders, easy cancel, and clean retry logic.
- Customer support SLA: Fast first response (<24h) beats a chargeback filed out of frustration.
- Evidence kit: Store order notes, chat logs, delivery proofs, device fingerprints, and terms acceptance—ready for one-click export.
Edge cases you’ll see in the wild
- Partial capture/partial refund: If you ship in parts, refund only the undelivered portion, and communicate dates clearly.
- Authorization “fall-off”: If you reversed (voided) correctly, the pending hold disappears on the issuer’s schedule—set expectations in your UI/email.
- Card-on-file retries: Respect network rules on retries and notifications to avoid “processing error” disputes.
- Friendly fraud vs. true fraud: Track separately; invest in post-purchase comms to reduce friendly fraud.
- Digital goods & services: Time-stamped access logs, IP/device, and in-app telemetry are your best evidence.
Quick decision guide (use with your ops team)
- Not shipped yet / service not delivered? → Reversal (if still pending) or Refund.
- Shipped and customer unhappy but cooperative? → Refund (partial/full).
- Customer claims fraud and evidence is strong on your side? → Consider Representment.
- Customer unresponsive and evidence weak? → Refund to avoid ratio damage.
By the numbers (what “good” looks like—varies by vertical)
- Chargeback rate: Keep well below network thresholds; set internal alerts ~50–70% of the way to limits.
- Win rate: Aim for >50% on clear non-fraud disputes where evidence is strong.
- Refund SLA: Initiate within 24–48 hours; tell customers posting can take 1–7 business days depending on the issuer.
- Pre-dispute deflection: Target continuous improvement via better descriptors, instant order details, and proactive CS.
Glossary (plain English)
Authorization (auth): The bank approves a hold for the amount.
Capture: You finalize the charge.
Clearing/Settlement: The charge posts and money moves through networks.
Reversal/Void: Cancel an uncaptured auth; the hold is released.
Refund: Send money back after posting.
Chargeback: Issuer forcibly takes funds back after posting.
Facts are based on company statements, processor/network product briefings, and industry reporting.