Skip to main content

Playbook: Handle a Refund Request

Last updated . Copy page as text

TL;DR
  • Check payment, refund and dispute status before promising money back
  • Use your margins, support time and refund policy to set approval limits
  • Give the customer a response deadline your team can meet
  • Handle refund requests before customers turn to their bank. Compare your refund and chargeback costs using your processor's fees.
  • Empower your support team. Compare response times before and after giving agents refund authority, using similar requests.

Step-by-step guide for when a customer asks for their money back. The goal: resolve it before they call their bank. First check the payment state. If a formal card chargeback is open, use the dispute case and don't send a separate refund. If RDR already resolved it or a refund exists, don't credit it again.

Workflow Overview​

PhaseKey Tasks
ReceiveLog the request, acknowledge to customer by the response time you publish
AssessPull order details, check for fraud signals, review history
DecideRefund, partial refund, deny with explanation, or escalate
ResolveProcess refund, confirm to customer, update records

When to Use This Playbook​

  • Customer emails, calls, or chats asking for a refund
  • Customer posts a complaint on social media
  • You receive a manual Ethoca or CDRN alert; check for an existing credit and follow its deadline
  • Customer's bank contacts you before filing a formal dispute; use the provider's inquiry workflow

Step 1: Receive and Acknowledge​

□ Log the request with timestamp, channel, and customer ID
□ Acknowledge receipt by your published response time; tell the customer when you'll follow up
□ Use this template:

  "Hi [Name], I received your request about order [#].
   I'm looking into this now and will follow up within
   [24 hours / 1 business day]."

□ Do NOT ask the customer to "wait while we investigate"
  without giving a timeline
Speed Matters

Reply promptly and give a next-update time. Track how often unanswered requests become disputes; a fixed 24-hour cutoff won't tell you that for your business.

Step 2: Assess the Request​

Pull the order details and check these signals:

□ Order details:
   □ Transaction amount
   □ Order date and delivery date
   □ Product/service delivered?
   □ Digital or physical goods?

□ Customer history:
   □ First-time or repeat customer?
   □ Previous refund requests? How many?
   □ Previous chargebacks?

□ Fraud signals:
   □ Does the request match the order? (e.g., "never received" but tracking shows delivered)
   □ Multiple refund requests in short period?
   □ Pattern matches known friendly fraud?

□ Timing:
   □ Within your posted refund window?
   □ If outside window, how far outside?

Quick Decision Matrix​

RequestWhat to checkAction
Clear delivery or billing errorOrder, payment and refund statusCorrect it through the supported workflow
Policy-covered returnPolicy at sale, condition and any return requirementsExplain the return and refund steps
Conflicting records or repeat requestsDelivery, usage, prior credits and customer explanationInvestigate and promise a next update
Large or ambiguous requestYour approval limit and evidenceEscalate to the person authorized to decide

Set approval limits from your own ticket size, margins and support time. This table applies only after the payment-state check above.

Step 3: Decide​

Option A: Full Refund​

Use when:

  • The request is within your own refund approval limit
  • Customer has a legitimate complaint
  • Product was genuinely not delivered or defective
  • You're outside the return window but the request is reasonable
□ Process refund through your processor dashboard
□ Use your provider's supported refund route for the original payment
□ Send confirmation email with refund amount and expected timing
□ Check your provider's estimate for this payment method; separate submission time from bank posting time

Option B: Partial Refund​

Use when:

  • Customer used part of the service before requesting refund
  • Product was partially delivered or partially defective
  • Shipping costs were incurred that can't be recovered
  • You want to retain some value while satisfying the customer
□ Calculate fair partial amount
□ Explain the breakdown to the customer before processing
□ Get customer agreement before processing (email confirmation)
□ Process and confirm

Option C: Deny with Explanation​

Use when:

  • Strong evidence of friendly fraud (confirmed delivery, usage logs)
  • Request is clearly outside policy and unreasonable
  • Customer has a pattern of abuse
□ Prepare evidence (tracking, delivery confirmation, usage logs)
□ Respond with specific reasons, not just "policy says no"
□ Offer alternatives allowed by your policy and applicable law: exchange, store credit, partial refund. An open chargeback stays in the dispute workflow
□ Document everything in case this becomes a chargeback
□ Save all communication for potential representment
The Alternatives Save You

For an eligible direct request, offer an alternative allowed by your policy and applicable law. An open formal chargeback stays in the dispute workflow; don't send a separate partial refund. Track how often similar requests become chargebacks before and after the change, allowing the same follow-up time.

Option D: Escalate​

Use when:

  • Amount is large and circumstances are ambiguous
  • Customer is threatening legal action
  • Request involves a product safety issue
  • You need manager approval per your internal policy
□ Inform customer of escalation and revised timeline
□ Escalate with full context (don't make the next person start over)
□ Follow up within the promised timeline

Step 4: Resolve and Follow Up​

□ Process the decided action (refund, partial, denial)
□ Send confirmation to customer with:
   □ What was decided
   □ If refund: amount and your provider's timing estimate for this payment method
   □ If denied: clear reasoning and alternatives offered
□ Update customer record with outcome
□ If this was a manual alert: report the outcome by its deadline; if RDR already resolved it, don't issue another credit
□ Flag patterns for review (is this product generating lots of requests?)

After Resolution: Prevent Repeats​

After every 10 refund requests, review for patterns:

□ Are refunds clustering around a specific product?
□ Are refunds clustering around a specific timeframe (e.g., 30 days post-purchase)?
□ Is your refund policy clearly visible before checkout?
□ Are your billing descriptors recognizable? (Check: would a customer
  recognize the charge on their statement?)
□ Are confirmation and shipping emails being sent and received?

Measuring Success​

MetricTargetWhat It Tells You
Refund response timeYour published response commitmentSpeed of customer resolution
Refund-to-chargeback ratioCompare before and after changes on similar ordersAre requests resolving before customers dispute?
Repeat refund rateCompare repeat requests within the same customer and product segmentsWhich requests need a closer look?
Refund rateCompare similar products and sales periods, allowing the same time for refundsWhere are refund reasons changing?

See Also​

Something wrong on this page? Email matt at paymentsandrisk.com and say what needs fixing.