Refunds and Chargebacks: Handle Them Without Losing Money or Goodwill

⬅️ Growth Overview

Refund and Chargeback Strategy for Your New SaaS

Goal: Build a refund and chargeback workflow that's customer-friendly, financially sustainable, and operationally simple. Avoid the failure modes where founders treat every refund as adversarial (poisoning customer goodwill) or where chargebacks accumulate quietly until your payment processor flags the account.

Process: Follow this chat pattern with your AI coding tool such as Claude or v0.app. Pay attention to the notes in [brackets] and replace the bracketed text with your own content.

Timeframe: Refund policy + workflow shipped in 1 week. Chargeback dispute process + monitoring in week 2. Quarterly review baked into the calendar from launch onward.

Why Refund Handling Is Underweighted by Founders

Three failure modes hit founders the same way:

• The "no refunds" policy is hostile and costs more than it saves. Founder thinks "no refunds" protects revenue. In practice, customers who would have refunded calmly instead initiate chargebacks (more expensive, damages your processor reputation), leave bad reviews, and warn their networks. The "no refund" stance saves $50 per customer in immediate revenue and costs $500-$5,000 in long-term reputation, dispute fees, and lost word-of-mouth.
• No process means refunds get personal. Each refund request requires founder judgment, founder emotional labor, and founder time. The customer who's unhappy gets the founder's worst self because the founder is exhausted from handling the previous refund manually. A simple policy + a workflow turns refunds into a small, predictable cost; no policy turns them into recurring crises.
• Chargebacks are silent killers. Customers initiate chargebacks via their bank instead of contacting you. You see the deduction days or weeks later. Each chargeback = lost revenue + a $15-$25 fee from the processor. After 1% chargeback rate, processors flag your account; at 2-3%, they suspend it. By the time the founder notices, damage is done.

The version that works is structured: a clear, generous refund policy; a simple workflow that doesn't require founder intervention for routine cases; chargeback monitoring with an automated dispute response; and quarterly review of the data to spot upstream issues (bad onboarding, misleading marketing, broken billing).

This guide assumes you have already chosen a Payment Provider (Stripe, Polar, Paddle, etc.), have shipped Customer Support (the channel where most refund requests land), and have implemented Reduce Churn (refund requests are downstream of dissatisfaction).

1. Design a Generous, Simple Refund Policy

The single most consequential decision. Most founders make it too restrictive.

You're helping me design the refund policy for [your product] at [your-domain.com]. The product is [B2B SaaS / B2C SaaS / consumer / prosumer], with pricing of [$X/month or $Y/year].

The decision tree:

**Default: 30-day money-back guarantee for first-time purchases**
- New customers can request a full refund within 30 days
- Process: simple email or in-app form; refunded within 5 business days
- Benefit: removes purchase friction; signal of confidence in product
- Downside: small revenue loss; almost always net-positive vs the alternative

**Pro-rated refund for annual plans**
- Customer cancels mid-year: refund unused portion (months remaining × monthly rate)
- Some founders don't pro-rate; this is hostile and produces chargebacks
- Pro-rate by default; protect against gaming with a per-customer-per-year limit if needed

**No refund after 30 days for monthly plans**
- Customer paid for the month already; service was delivered
- Can cancel future renewal anytime
- This is industry standard

**Service-failure refund (unconditional)**
- If the product was meaningfully broken (extended downtime, bug they hit, missing feature they were promised)
- Refund regardless of timing
- Founder's discretion; usually small amount

**Full refund on tier downgrade within first 30 days**
- Customer accidentally upgraded to higher tier; usage doesn't justify
- Refund the difference, no questions asked

**For B2B / annual contracts**:
- Refund policy explicit in the contract
- Pro-rated default; anti-gaming clauses if necessary

**For lifetime deals**:
- Per [AppSumo & Lifetime Deals](https://www.launchweek.ai/launch/appsumo-lifetime-deals): typically 60-day refund window per AppSumo standard
- Consistent with platform if you sell through one

**For pre-launch / founding-customer programs**:
- Per [Pre-Launch Revenue](https://www.launchweek.ai/launch/pre-launch-revenue): full refund anytime before ship + 30 days after
- Generous because trust is the contract

Output:
1. The full refund policy in plain language
2. The legal review checkpoint (have a lawyer review before publishing)
3. The customer-facing page (linked from pricing, footer, support docs)
4. The internal escalation rules: when does a refund need founder approval vs. auto-approved

Three principles I've watched founders re-learn:

• Generous beats restrictive. A 30-day refund on a $100 product = $3 average per refund (assuming 3% refund rate). Restrictive policies cost more in chargebacks + bad reviews + reputation than they save.
• Pro-rate annuals. "No refund on annual plans" generates chargebacks; pro-rating doesn't.
• Make refund easier than chargeback. If your refund process is harder than calling the bank, customers chargeback instead. Friction asymmetry matters.

2. Build a Simple, Self-Serve Refund Workflow

Manual refunds are a sign of bad process. Automate the routine cases.

Help me design the refund workflow for [your stack — Stripe / Polar / Paddle / your provider].

The workflow:

**Self-serve refund request** (in-product form):
- Customer goes to Settings → Billing → Refund Request
- Form fields:
  - Reason (dropdown: Doesn't fit my needs / Found alternative / Service issue / Accidental purchase / Other)
  - Optional comment box
- Submit triggers:
  - Email confirmation to customer
  - Internal notification to support / founder
  - If within auto-approve criteria: refund issued immediately via Stripe / Polar / your provider
  - If outside auto-approve criteria: support reviews within 24h

**Auto-approve criteria** (refund without human review):
- Within 30-day money-back window
- Single-month subscription or annual within first 30 days
- Customer has < 3 prior refunds (anti-fraud limit)
- Refund amount under $500 (configurable based on your pricing)

**Human-review criteria**:
- Annual plan past 30 days (pro-rate review)
- Multiple prior refunds from same customer
- Refund > $500
- Service-failure claim
- Anything outside the policy

**Implementation in Stripe** (most common):
```ts
async function processRefund(chargeId, reason, amount?) {
  const refund = await stripe.refunds.create({
    charge: chargeId,
    amount: amount || undefined, // undefined = full refund
    reason: 'requested_by_customer',
    metadata: { internal_reason: reason }
  })

  // Trigger:
  // - Customer email confirmation
  // - Audit log entry per [Audit Logs](audit-logs-chat.md)
  // - Subscription cancellation if applicable
  // - PostHog event for analytics

  return refund
}

Communication:

• Confirmation email to customer within 5 minutes of refund issued
• Includes: amount, expected timing (5-10 business days for the refund to appear on their card), how to cancel future renewals if applicable
• Tone: friendly, no friction, "sorry it didn't work out"

The "winback" moment:

• After refund processed, send a 1-line email: "If you ever want to try again or if there's anything we should improve, just reply to this email. No follow-up otherwise."
• Some refunders return; many give useful feedback
• Tone: low-pressure, genuine

Output:

1. The self-serve form UI
2. The auto-approve / human-review logic
3. The Stripe / Polar / your provider integration code
4. The customer-communication templates
5. The audit-log integration per Audit Logs
6. The PostHog event payload (refund_requested, refund_approved, refund_processed)

The single most undervalued tactic: **the post-refund "tell us anything" email.** Most refunders are silent; the ones who reply give you the most actionable feedback in your funnel.

---

## 3. Track Refund Reasons; Use Them to Improve

Every refund is data. Most founders ignore it.

Build the refund-reason tracking system.

The reasons (consolidate to 5-7 buckets — too many produces noise):

1. Doesn't fit my needs — wrong product for them; user-acquisition mismatch
2. Found alternative — competitive loss; investigate which competitor
3. Service issue / bug — product failure; fix the bug
4. Accidental purchase / billing error — UX issue or fraud signal
5. Pricing / can't afford — pricing-page issue or wrong-tier signal
6. Wasn't using it — activation failure
7. Other — open text; review monthly

Capture in PostHog (or your analytics): refund_reason as a property on the refund_processed event.

Monthly review:

• Top reason: addressed? Did the underlying issue change?
• Trend over time: are refunds growing (bad signal) or shrinking (good)?
• Per-cohort: do certain acquisition channels produce more refunds?
• Per-tier: is one pricing tier disproportionately refunded? (Sign of pricing or feature mismatch)

Action triggers:

• "Doesn't fit my needs" >20% of refunds → marketing/positioning misaligned with actual product
• "Found alternative" trending up + same competitor named → competitive threat to investigate
• "Service issue / bug" rising → product quality issue; investigate
• "Accidental purchase" rising → onboarding/checkout UX issue
• "Pricing" rising → tier structure may be wrong

Quarterly action:

• Identify the top 1-2 actionable refund reasons
• Ship a fix in the next quarter
• Measure refund-reason distribution change over the next 90 days

Output:

1. The refund-reason taxonomy
2. The PostHog event tracking
3. The monthly review template
4. The quarterly action-priority framework
5. The dashboard: refund rate by month, by reason, by tier, by acquisition channel

The single most useful insight: **refund reasons change over time.** A spike in "found alternative" means a competitor just launched something. A spike in "doesn't fit my needs" means your marketing is reaching the wrong audience. Treat reason data as early-warning.

---

## 4. Monitor Chargebacks Aggressively

Chargebacks are the silent killer. Detect them before your processor does.

Set up chargeback monitoring.

The risk:

• 1 chargeback = lost revenue + $15-$25 fee from processor
• Chargeback rate above 1% = processor warning
• Chargeback rate above 2-3% = processor account suspension
• Account suspension = loss of payment processing entirely (catastrophic)

Detection:

• Stripe / Polar / your provider sends a webhook on chargeback initiated
• Per Public API: webhook receiver fires when this event arrives
• Internal alert: Slack notification to founder + support immediately

Stripe webhook event: charge.dispute.created

• Customer initiated dispute via their bank
• Stripe automatically debits your account for the chargeback amount + fee
• You have 7-14 days to respond (varies by network)

Immediate response actions:

1. Read the dispute reason (Stripe categorizes: fraudulent, product not received, product unacceptable, duplicate, subscription canceled, etc.)
2. Check the customer's history — were they a real customer? Did they use the product?
3. Decide: dispute or accept
   • Dispute (fight the chargeback): if you have evidence the charge was legitimate
   • Accept: if it's clearly fraud or the customer's case is strong

Dispute response (when you fight it):

• Stripe Dashboard / API for evidence submission
• Required evidence varies by reason but typically:
  • Proof of service delivery (login records, usage logs, etc.)
  • Customer agreement (signed terms / accepted ToS)
  • Communication history (support emails)
  • Refund policy
• Submit BEFORE the deadline (Stripe shows you the deadline)

Win rates (Stripe published data):

• Overall: ~15-20% of disputes won
• Higher with strong evidence; lower with weak
• Specific reasons (fraudulent disputes) almost never won; product-not-received frequently won

Prevention is cheaper than disputing:

• Easy refund process → fewer chargebacks
• Clear product expectations → fewer "unacceptable" disputes
• Subscription-end communication → fewer "canceled but charged" disputes

Output:

1. The chargeback webhook handler code
2. The internal-alert Slack integration
3. The dispute-response template + evidence checklist per dispute reason
4. The 7-day SLA for responding to disputes
5. The monthly chargeback-rate dashboard with trend
6. The threshold alerts (>0.5% / >1% / >2% chargeback rate)

The single most consequential rule: **respond to every dispute within 48 hours.** Even disputes you'll lose: respond. Stripe's algorithms reward responsiveness; ignored disputes hurt your account standing more than lost disputes.

---

## 5. Prevent Chargebacks at the Root

Most chargebacks come from preventable failures. Investigate.

Design the chargeback prevention strategy.

Common chargeback causes (in roughly priority order):

1. "I didn't recognize the charge" (~40% of B2C chargebacks)

• Customer forgot they signed up; recurring charge surprises them
• Prevention: clearer billing descriptor (Stripe: customize the descriptor); reminder emails before renewal; visible subscription in settings

2. "I tried to cancel and was charged anyway" (~25%)

• Customer tried to cancel; UX failed; they were charged
• Prevention: easy cancel UX (per Reduce Churn); clear confirmation email; no friction in cancellation
• Per Pre-Launch Revenue: same principle — easy refund > resented chargeback

3. "Product wasn't as described / didn't work" (~15%)

• Marketing oversold; product underdelivered
• Prevention: realistic marketing copy; clear expectations; refund offer when product doesn't meet expectations

4. "Fraudulent — wasn't me" (~10%)

• Stolen credit card / family-member used
• Prevention: 3D Secure for higher-risk transactions; address-verification (AVS); fraud-detection (Stripe Radar)

5. "Service issue / outage" (~5%)

• Product broken when customer needed it
• Prevention: stable product; status page; proactive comms during outages

6. "Subscription canceled but charged" (~5%)

• Cancellation didn't process; recurring charge fired
• Prevention: webhook reliability; testing of cancellation flow; refund proactively if charge fires after cancellation request

Per-cause prevention tactics:

Quarterly chargeback review:

• What caused each chargeback this quarter?
• Which causes are preventable upstream?
• What product / process changes would eliminate the top cause?

Output:

1. The chargeback-cause taxonomy
2. The prevention tactic per cause
3. The quarterly review template
4. The "billing descriptor" optimization (Stripe-specific)
5. The renewal-reminder email template (sent 7 days before annual renewal)

The single most undervalued prevention: **clear renewal-reminder emails.** A customer who knows their renewal is coming next week doesn't dispute it; a customer surprised by the charge does. The 7-days-before email costs nothing and prevents 30% of chargebacks.

---

## 6. Handle Special Cases: Fraud, Abuse, Repeat Refunders

Edge cases need policy in advance.

Document the policies for special-case handling.

Repeat refunders:

• Customer who has refunded 2+ times in 12 months
• Action: limit to 1 active subscription; require manual approval for future refunds; gentle communication about pattern
• Do NOT ban; do NOT shame; just structure the relationship to be sustainable

Suspected fraud (the customer):

• Multiple cards from same IP, mismatched billing/shipping countries, behavioral signals (e.g., signups on Tor)
• Action: Stripe Radar handles most of this automatically; flag for human review on borderline cases
• Decline borderline cases rather than approve and refund later

Suspected fraud (their card was stolen):

• Customer reports unauthorized charge; chargeback follows
• Action: process the chargeback as accept (don't fight); investigate; ban the card if you can identify it
• Don't pursue further; it's not your customer

Subscription / billing bugs (your fault):

• Customer was charged twice; charged after cancel; charged wrong amount
• Action: refund proactively; explain in plain language; goodwill credit if significant
• Audit-log per Audit Logs; investigate root cause

Service-outage refund:

• Major outage affecting paying customers
• Action: proactive credit (not refund) for affected accounts; communicate via status page per Status Page
• "We had a [N]-hour outage on [date]; we've credited your account [$X]. Sorry."

Annual plan cancellation mid-cycle:

• Customer wants to cancel; pro-rate the refund
• Action: refund unused months; cancel subscription; clear communication
• Anti-gaming: limit to 1 such refund per customer per year

Enterprise contract refund:

• Customer paid annual upfront; wants out
• Action: per the contract terms; pro-rated default; legal review for large amounts

Output:

1. The special-case policies (one per case)
2. The internal escalation tree: which cases require founder approval
3. The customer-facing communication templates
4. The audit-log integration for every refund / chargeback / credit

The biggest mistake: **treating repeat refunders as adversaries.** Some customers genuinely don't fit your product; making them feel persecuted creates bad reviews. Limit them gracefully; don't punish.

---

## 7. Document, Communicate, Scale

The refund policy is a customer-facing trust signal. Treat it as such.

Design the customer-facing refund documentation.

Pages to publish:

1. Refund policy page (linked from pricing footer)

• The policy in plain language
• Examples
• The process (how to request)
• Timing (refund processed within 5 business days)
• Who to contact

2. Pricing page footer

• One sentence: "30-day money-back guarantee on all paid plans"
• Link to refund policy

3. Checkout page

• Subtle reminder: "30-day money-back guarantee"
• Removes purchase friction

4. Welcome / onboarding email

• Mention the refund policy; signal confidence
• Reassures customers who are still evaluating

5. Cancellation flow

• "Want a refund instead of just canceling? Click here."
• Self-serve refund request inline with cancel
• Per Reduce Churn: cancel flow is the right place

6. Support docs / KB

• "How do I get a refund?" with step-by-step
• Reduces support volume

Internal documentation:

• Refund decision tree for support staff
• Escalation paths
• Auto-approve / human-review boundaries
• Communication templates

Quarterly metrics review:

• Refund rate (should be <5% for self-serve B2C; <2% for B2B)
• Chargeback rate (should be <0.5%; alarm at 1%)
• Refund reasons distribution
• Win rate on disputes
• Time to refund (auto-approve should be <1 hour)
• Customer-satisfaction post-refund (NPS-style: how was your refund experience?)

Output:

1. The refund policy page copy
2. The pricing-page snippet
3. The cancellation-flow refund option
4. The internal documentation
5. The quarterly metrics dashboard

The single most undervalued effect: **a generous, visible refund policy reduces purchase friction.** Customers who see "30-day money-back guarantee" upfront are more likely to convert. The few who refund are net-positive vs the many who didn't convert without the guarantee.

---

## What Done Looks Like

By end of week 2 of building refund / chargeback discipline:
1. **Generous refund policy** documented and published
2. **Self-serve refund workflow** with auto-approve criteria
3. **Refund-reason tracking** in PostHog
4. **Chargeback webhook monitoring** with Slack alerts
5. **Dispute-response templates** ready
6. **Renewal-reminder emails** sent 7 days before charges
7. **Quarterly review process** scheduled

Within 90 days:
- Refund rate stable (1-5% for most indie SaaS)
- Chargeback rate <0.5%
- 1+ quarterly review completed with action items
- Refund reasons informing product / marketing decisions

Within 12 months:
- Refund / chargeback handling is invisible because it works
- Reduced support load due to self-serve workflow
- Stripe / processor account in good standing
- Customer goodwill maintained even with refunds (some refunders return as customers later)

---

## Common Pitfalls

- **"No refunds" policy.** Costs more in chargebacks + reputation than it saves.
- **Manual refunds for everything.** Auto-approve routine cases; reserve human review for edge.
- **Ignoring chargeback webhooks.** Silent killer; respond within 48 hours.
- **Not tracking reasons.** Refunds are data; ignoring them wastes the signal.
- **Restrictive cancellation flow.** Hard cancel = customers chargeback instead.
- **Treating repeat refunders as enemies.** Just structure the relationship; don't punish.
- **No renewal-reminder emails.** Surprise charges drive 30%+ of chargebacks.
- **Disputing every chargeback.** Some are unwinnable; fight the winnable ones; accept gracefully on others.
- **Slow refund processing.** Customers who wait turn into chargebackers.
- **Hidden refund policy.** Bury it in legalese; customers chargeback because they couldn't find it.

---

## Where Refunds & Chargebacks Plug Into the Rest of the Stack

- [Payment Providers](https://www.vibereference.com/auth-and-payments/payment-providers) — Stripe / Polar / Paddle handle the underlying refund + dispute
- [Reduce Churn](reduce-churn-chat.md) — easy cancel flow prevents chargebacks
- [Customer Support](customer-support-chat.md) — refund requests often arrive via support
- [Audit Logs](audit-logs-chat.md) — every refund / chargeback logged
- [Pricing Page](pricing-page-chat.md) — refund policy visible in footer
- [Trial-to-Paid Conversion](trial-to-paid-chat.md) — refund policy reduces purchase friction
- [Onboarding Email Sequence](onboarding-email-sequence-chat.md) — welcome email mentions refund policy
- [Email Deliverability](email-deliverability-chat.md) — renewal-reminder emails depend on inbox placement
- [Status Page](status-page-chat.md) — service-outage credits documented here
- [Public API](public-api-chat.md) — webhook receivers handle Stripe dispute events
- [Pre-Launch Revenue](https://www.launchweek.ai/launch/pre-launch-revenue) — companion for pre-launch refund philosophy

---

## What's Next

Refund and chargeback handling is one of those operational disciplines that fades into the background when done right. The team that ships generous policy + self-serve workflow + chargeback monitoring in week 2 of launch never has a refund-related crisis. The team that ignores it pays compounding interest — every month of bad data, every quarter of restrictive policies costs more than the policies "save."

Build the discipline now while the customer base is small enough that every refund is also a learning opportunity. By year 2, the policy is invisible because it works.

---

[⬅️ Growth Overview](README.md)