Refund Processing Policy

Refund or credit processed in billing system. Customer notified via email with amount and timeline. Ticket closed with outcome logged: category, amount, policy applied. Monthly refund report: volume by category, total refunded, denial rate, escalation rate.

Before you start

Refund policy documented with tier-specific rules and dollar limits
Billing system access (Stripe, Chargebee, or equivalent)
Escalation path for out-of-policy requests defined
Customer refund request (ticket or email with reason stated)
Customer account data: plan tier, payment history, account age, prior refunds
Refund reason category (as stated or inferred)

The steps

Verify identity and locate account — Match requestor email to billing account. Confirm the charge they are referencing (amount, date, description). If charge cannot be located, ask for the last 4 digits of the card used or the invoice number. Do not process a refund without confirming the charge exists on the account.
Classify refund reason — Categories: (a) billing error — charged wrong amount or duplicate, (b) service failure — product was down during their billing period, (c) buyer's remorse — didn't use the product, (d) cancellation — want out of subscription, (e) dissatisfied — product didn't meet expectations, (f) fraud — charge not recognized. Log category on ticket. Fraud must immediately escalate to billing ops — do not process autonomously.
Apply tier-based policy — Billing error (a): full refund always, no approval needed. Service failure (b): pro-rate refund for downtime period; calculate from incident log; full refund if downtime > 50% of billing period. Buyer's remorse (c): full refund within 7 days of charge if first-time customer; no refund if more than 7 days or if customer has requested refund before. Cancellation (d): no refund on annual plans unless within 30-day window; monthly plans: no refund for current period, cancel forward. Dissatisfied (e): escalate to CSM if customer LTV > $1k; offer credit instead of refund for first request; refund on second request.
Execute refund or credit in billing system — In Stripe: navigate to payment record, click Refund, enter amount (partial or full), select reason from dropdown, add internal note with ticket number and policy basis. Process returns to original payment method within 5-10 business days (communicate this to customer). For credits: apply to account balance in billing system — specify expiry if policy-limited.
Notify customer with confirmation — Send email confirming: amount refunded (or credited), expected timeline for refund to appear, and any account changes (e.g., subscription cancelled). If request was partially granted (credit instead of full refund), explain the policy clearly — do not be vague. If request was denied, explain the specific policy rule that applies and offer an alternative (extension, credit, or escalation path).
Log outcome and tag for pattern review — Update ticket with: refund amount, reason category, policy applied, outcome (full/partial/denied/escalated). Tag ticket in help desk with refund reason for monthly pattern review. If same reason appears > 3 times in a week, flag to product or ops team — likely a systemic issue.

If it goes wrong

Customer disputes policy denial via chargeback

Document all communications in ticket. In Stripe, submit evidence package: charge date, service delivery logs, policy communicated to customer, and prior refund history. Respond to chargeback within 7 days of notification.

Refund processed to wrong account or payment method

Stripe refunds return to original payment method automatically — do not issue manual bank transfers unless explicitly directed by billing ops. If wrong account refunded, contact Stripe support immediately.

Refund volume spikes — pattern not caught until month-end

Set weekly alert: if refunds in any category exceed baseline by 50%, auto-notify ops lead. Do not wait for monthly review to surface systemic issues.

All OpenLabor playbooks