Refund review

This playbook manages one customer refund request against purchase records, merchant policy, and payment gateway history. It delivers an authorized decision, followed by either a verified payment refund or an accountable finance execution handoff with verified customer communication. Fallback during tool or platform outages requires documenting the collected evidence in the support ticket, assigning manual review to the finance team, and keeping the case pending until an authorized human decides the outcome.

• Locate the customer request in the support platform and extract the order reference, customer identity, claimed reason for refund, and requested amount. Inspect earlier ticket threads to verify whether previous concessions, exchanges, or partial refunds were already discussed or promised.
• Retrieve the corresponding order details from the commerce platform, including order date, line items, item condition requirements, fulfillment status, and delivery confirmation timestamps. Check whether physical return tracking shows the item was received and restocked if required by store policy.
• Examine the payment processor record to verify the original transaction ID, net charged amount, currency, and settlement state. Confirm the cumulative amount already refunded across all prior transactions and verify whether any active dispute or chargeback inquiry is open with the issuing bank.
• Compare the request against store policy rules for refund windows, non-refundable product categories, restocking fees, and shipping cost deductions. If an active dispute or chargeback is detected, inspect the specific payment processor and merchant policy rules regarding concurrent refunds, and route the case to the authorized disputes owner to decide whether to issue an immediate concession or preserve the dispute representation path, avoiding double debiting.
• Information request. When decisive evidence is missing—such as an unverified delivery discrepancy, absent return tracking for returned goods, or required photos for claimed physical defects—request the specific missing information from the customer or fulfillment partner and hold the case in Checking history. If the requested party refuses evidence or the policy window expires without a response, route the case with the missing-evidence record to the authorized finance owner for disposition rather than automatically declining.
• Synthesize the request into a recommendation specifying whether the refund should be full, partial excluding original shipping, store credit, or declined. Itemize the calculation showing original payment, prior refunds, proposed net amount, recipient, and policy justification.
• Approval. Present the reconciliation summary, policy comparison, proposed refund amount, and drafted customer communication to the authorized finance manager for a formal decision. The manager approves, modifies, or declines the refund, sets any policy exception, and approves the outgoing message text and recipient. Any altered amount, revised terms, or materially changed transaction history requires renewed manager authorization before disbursement; never disburse funds, offer credit, or send payment promises without explicit approval.
• If an automated payment integration is configured, execute the approved refund against the payment gateway with the exact authorized amount and currency. Read back the transaction receipt immediately, confirming the returned refund ID, amount, and status equal to succeeded. If the call times out or returns an ambiguous network error, inspect the transaction record and prior gateway effects before attempting any manual or automated retry to prevent duplicate disbursements; hold the case if processor status remains unconfirmed.
• If an automated payment tool is not connected or returns a persistent technical failure, record an accountable finance task containing the charge ID, authorized amount, reason code, and approval reference. Require explicit written acceptance from the receiving finance operator with a recorded follow-up tracking reference before considering the review handoff complete; keep the case pending manual execution rather than marking funds refunded.
• Deliver the approved customer communication through the support platform or designated manual channel, confirming message transmission or delivery receipt. Explain the rationale and applicable policy deductions for partial or declined requests, or provide the gateway transaction reference and expected banking posting window for approved refunds.
• In a fictional example, a customer requests a full refund of $145.00 for order #8492 on Help Scout, claiming defective merchandise. Shopify records show order delivery 12 days prior, well within the 30-day window, but Stripe records show $20.00 of shipping fees that policy classifies as non-refundable unless shipping was delayed. The agent proposes a partial refund of $125.00 for goods value and drafts the response. The finance manager reviews the recommendation, approves the $125.00 payout and message text. The Stripe refund is executed and verified with refund ID re_3N9x12, and the Help Scout reply is delivered and confirmed.
• A case is complete when either the approved refund is verified on the payment processor with delivery of the customer communication confirmed, or an authorized decline decision is recorded with policy rationale and transmitted to the customer, or an unexecuted manual refund achieves a complete review handoff through explicit acceptance and recorded follow-up by the receiving finance operator while remaining pending execution. Never mark funds refunded from a pending or unconfirmed handoff status.