E-commerce
August 7, 2026
"Where is my refund?" "You said 48 hours, it's been 10 days." "Shopify says refunded but my bank says nothing." Three messages where a generic bot promises an immediate credit or invents a date without reading the actual refund status.
Gorgias estimates that 12 to 18% of post-return tickets concern refund status or delays, often resolvable by order lookup (Gorgias, Customer Support 2026). Shopify points out that refunds can remain pending processor for 5-10 business days before bank credit (Shopify, refunds 2026).
This guide #370 formalizes the e-commerce AI refund status chatbot: reassuring without over-promising. A new post-return AI use case distinct from returns bot (#10) (RMA) and expired card (#369) (closed payment method ops): ref_stat_* intents, REF-STAT-GATE flow, and anti-promise guardrails.
Summary
Why automate the refund status with a bot?
A refund status bot answers: is my refund initiated, pending bank transfer, or blocked? It does not promise an exact credit card date: it cites the Shopify status, standard turnaround time, and next step.
Three generic bot failures
24h promise: bot guarantees credit without a refund lookup
Invented date: "you will be refunded tomorrow" without a pending status
Overlooked uninitiated refund: bot says OK when the return has not yet been received at the warehouse
Narvar observes that transparency regarding refund timelines reduces post-return "where is my money" inquiries by 20 to 30% (Narvar, 2025 returns).
Angle #370
#10 guides return/RMA. #369 handles closed payment methods ops. #370 implements the bot layer ref_stat_* lookup timeline refund post-return or post-cancellation.
ROI ref stat bot
For a DTC brand with 120 "refund status" tickets/month, a targeted bot achieves 70 to 80% auto-resolution vs. a generic bot at 25%.
DTC Example
Fashion brand, 98 ref_stat tickets/month. After implementing REF-STAT-GATE bot: ref_stat_bot_resolution 81%, ref_stat_false_promise 1.5%, response time 25 s, refund status CSAT 4.6/5.
Journey timing
Post-RMA Day 1 to Day 15, post-cancellation, post-partial (#368). Triggers: refund, reimbursement, money, bank, delay.
Ops prerequisites
Refund timeline policy published (/returns). Return received webhook → documented refund trigger. Bot handoff #369 if there are ref_exp signals.
Reassure without overpromising
Empathetic tone + facts: amount, initiation date, processor status, typical bank processing time of 5-10 days. Never say "tomorrow in your account".
Deterministic vs. LLM
Status and timelines = order timeline lookup. LLM reformulates reassuring message, but does not decide if refund is initiated.
Seasonal volume
Peak in January post-holiday returns (#253) and clearance sales. Bot reduces agent workload on WISMO-refund hybrid cases.
Chargeback prevention
A customer uninformed about bank processing times opens a chargeback on Day 7. REF-STAT-GATE bot + proactive email reduces "refund not received" disputes by 25 to 40% according to equipped DTC stores.
Difference between WISMO and refund status
WISMO = package in transit. ref_stat = money after return. Separate routing avoids tracking responses when a customer asks for a refund.
How does it differ from return bot #10 and REF-EXP #369?
Eight neighboring contents, eight distinct bot roles post-return.
Returns Bot (#10)
Returns Bot (#10): RMA and exchange. The #370 intervenes after the return is shipped or refund is initiated.
Expired Card (#369)
REF-EXP (#369): closed payment method, IBAN. The #370 hands off to ref_stat_expired if > 10 days or failed.
Partial Refund (#368)
Partial (#368): partial amount. The #370 quotes partial_amount if ref_stat_partial.
Eligibility Bot (#365)
Eligibility (#365): upstream of return. The #370 = downstream of refund timeline.
Split Payments (#194)
Split (#194): BNPL sync. The #370 hands off to ref_stat_bnpl if Klarna/Alma.
Prequalification (#138)
Prequalification (#138): upstream collection. The #370 assumes the return is already initiated or cancelled.
Holiday Returns (#253)
Holiday Returns (#253): peak volume. The #370 scales status lookup in January.
Promise #370
Intents ref_stat_*, flow REF-STAT-GATE, safeguards REF-STAT-GUARD, handoff #369/#194, KPI ref_stat_bot.
Which ref_stat intents should the bot classify?
Map the ref_stat intents before flows. Scope: inform status, do not launch refund bot alone.
Twelve refund bot status intents
ref_stat_where_money: where is my generic refund
ref_stat_not_started: return not received at warehouse, refund not initiated
ref_stat_pending_processor: Shopify pending, normal waiting time
ref_stat_success_waiting_bank: Shopify success, bank processing delay
ref_stat_partial_amount: partial initiated, amount question
ref_stat_failed: processor failed, handoff #369
ref_stat_expired_card: expired card, handoff REF-EXP
ref_stat_bnpl: Klarna/Alma installment schedule, handoff #194
ref_stat_cancel_order: pre-shipment cancellation refund
ref_stat_arn_request: ARN bank reference request
ref_stat_too_early: customer follow-up D+1, delay education
ref_stat_angry_handoff: chargeback threat, P1 escalation
Required session fields
order_id, return_status, refund_status, refund_amount, refund_date, days_since_refund, arn, payment_method, ref_stat_intent.
Parent Router
"remboursement", "refund", "argent", "banque", "délai" post-order → ref_stat_*. "Comment retourner" → #365 or #10.
Mining 90-day tickets
Export "remboursement", "pas reçu", "statut". Prioritize top verbatim flows.
MVP Prioritization
Week 1: ref_stat_success_waiting_bank + ref_stat_not_started. Week 2: ref_stat_pending + ref_stat_too_early. Week 3: ref_stat_failed + handoff #369.
How to build the REF-STAT-GATE flow?
The REF-STAT-GATE flow routes each message via the lookup order timeline before the status response.
Seven sequential gates
Auth gate: email + order_id
Return status gate: RMA created, parcel in transit, received at warehouse
Refund exists gate: refund event timeline yes/no
Refund status gate: none, pending, success, failed
Payment method gate: Credit Card, PayPal, BNPL → branch if necessary
Days_since gate: too_early vs normal vs escalate
Exit gate: status message, delay education, handoff
ref_stat_not_started branch
Return not received: "We process refunds within 48 hours after receipt at the warehouse. Return tracking: [status]." No promise of refund initiated.
ref_stat_success_waiting_bank branch
"Refund of [X] € initiated on [date]. Status: processed. Bank credit delay: 5-10 business days. Check full statement if card is expired."
ref_stat_pending_processor branch
"Refund pending on the processor side. Normal delay 3-5 business days before final status. We invite you to check back if there is no change after 7 days."
ref_stat_failed branch
Immediate handoff #369 REF-EXP. Bot does not retry refund on its own.
Bank delay template
Fixed policy: EU Credit Card 5-10 days, PayPal 3-5 days, BNPL see #194. Bot quotes range, not exact date.
ref_stat_arn_request
If ARN is available in Shopify Payments metafield: bot shares REF-STAT-ARN template. Customer communicates to bank if credit is missing after 10 days.
days_since threshold escalation
Success + days_since > 10: handoff #369 ref_exp. Pending + days_since > 7: supervisor verification of processor.
Which data sources does the status bot read?
The refund status bot reads live Shopify data + return portal without hallucinating the timeline.
Required Shopify sources
Order timeline: refund events, amounts, status
Fulfillment/return: return received date at warehouse
Payment method: gateway, last4, PayPal email
ARN metafield: if captured post-refund Shopify Payments
Partial refunds: list of PART-REF amounts #368
Return portal sources
Loop/ReturnGO API: return status in_transit, delivered, inspected
Policy RAG: indexed return timeframes
REF-EXP doc #369: handoff rules for expired/failed
Webhook sync return received
Trigger refund ops within 48 hours post-reception. Bot ref_stat_not_started cites refund launch ETA from policy.
BNPL flag
Tag order klarna/alma: ref_stat_bnpl handoff #194, not standard credit card timeframes.
What REF-STAT-GUARD safeguards should be imposed?
The REF-STAT-GUARD safeguards prevent refund promises and made-up dates.
Six strict rules
No exact card date: 5-10 day range only
No bot-initiated refund: inform of status, handoff if action required
Lookup before replying: auth + timeline mandatory
Failed = handoff #369: no bot retry
BNPL = handoff #194: no generic card timeframe
Empathy without admitting fault: "we understand" without "store error" unless proven
System prompt ref stat
"You inform about refund status according to the order timeline. You never promise credit tomorrow. You state the amount, launch date, processor status, and typical bank timeframe. If failed or expired card, handoff #369. If BNPL, handoff #194." See anti-hallucination.
ref_stat_too_early
D+1 post-refund success: patient education, no escalation. "Normal processing timeframe in progress."
Audit false promise
Sample 50 conversations/month: ref_stat_false_promise_rate. Target < 2%. Monthly review of bot transcripts vs order timeline.
On which customer journeys should the status bot be deployed?
The refund status bot is deployed on anxious post-return touchpoints.
"Where is my refund" chat flow
Auth → REF-STAT-GATE → status message or handoff.
Return received email flow Day+0
"Return received, refund within 48h" + pre-filled status chat link with order_id.
Refund initiated email flow Day+0
"Refund of [X] € initiated. Bank credit 5-10 days. Questions? [chat]" Reduces ref_stat follow-ups.
Customer account flow
Order badge: "Refund initiated on [date], bank processing time pending" live lookup.
Loop return portal flow
Status "Refund processing": "Delay details" button → ref_stat chat.
ref_stat_angry_handoff flow
Chargeback threat Day+7: P1 supervisor payload timeline + ARN.
Proactive notification
Webhook refund success → auto email/SMS with estimated time frame. Bot handles follow-up questions.
Portal post-return widget
Loop status "Refund initiated": Integrated chat CTA with session order_id. Customer does not leave portal for support email.
Consistent multi-channel
Same REF-STAT-GATE on site chat, WhatsApp if connected to Shopify lookup, and email auto-reply parser ref_stat keywords.
How to set up the status bot on Shopify?
The Shopify refund status bot setup connects timeline, return portal, and delay RAG.
Technical Checklist
Document refund policy/return delays
Sync return received webhook + refund trigger SLA
Index timeline refund API order lookup
Integrate Loop return status API
Configure router ref_stat_* keywords
Implement REF-STAT-GATE section 4
Write prompt REF-STAT-GUARD section 6
Connect handoff #369 and #194 payloads
Test 25 regression scenarios
Weekly ref_stat_bot_resolution dashboard
Aligned Email Templates
Same wording for bot delays and post-refund emails. Consistency reduces ref_stat_too_early disputes.
Gradual Launch
Phase 1: ref_stat_success + not_started. Phase 2: pending + too_early. Phase 3: failed + bnpl handoffs.
Which ref_stat_bot KPIs should be measured?
Without the ref_stat_bot KPI, it is impossible to prove ROI vs agents alone.
Seven Key Metrics
ref_stat_bot_resolution: resolved without agent / ref stat sessions
ref_stat_deflection: refund status tickets avoided / sessions
ref_stat_false_promise_rate: incorrect bot date/amount promise
ref_stat_handoff_rate: #369 + #194 + angry / sessions
ref_stat_too_early_rate: D+1-3 reminders / total ref stat
ref_stat_repeat_contact_7d: customer returns within 7 days / sessions
CSAT intent ref_stat: refund status bot satisfaction
DTC Benchmark
Target ref_stat_bot_resolution > 78%, ref_stat_false_promise < 2%, ref_stat_repeat_contact_7d < 15%, CSAT > 4.5/5.
Impact on Chargebacks
Measure "refund not received" chargebacks before/after proactive bot + REF-STAT-GATE.
Reduction in Agent Tickets
Track agent refund status hours before/after. Target -40% volume in ref_stat tickets.
Correlation Between CSAT and Delay
Measure ref_stat CSAT by days_since_refund bracket. Adjust ref_stat_too_early messaging if CSAT drops on D+1-3 despite education.
What edge cases and handoffs should be planned for?
Seven edge cases ref stat bot require handoff or specific message.
Split refund multi-parcel
Partial refund parcel 1 only. Bot lists line items refunded. Link split (#356).
Gift order refund status
Refund to buyer. Recipient contacts: explain buyer's payment method, do not transfer credit card info.
Store credit vs credit card refund
If partial (#368) chose store credit: bot quotes credit code, not bank processing time.
Manual IBAN pending
#369 manual refund pending: bot states 5-day transfer delay, not Shopify success status.
Return lost in transit
Return parcel lost: handoff ops, not ref_stat_success message.
Multi-refund same order
List all timeline refund events with cumulative amounts.
Multi-currency markets
State amount in original order currency, not approximate conversion.
Preorder cancel refund
ref_stat_cancel_order: charge-later capture void delay 5-7 days.
Exchange vs refund confusion
Customer requested exchange (#367) but expects refund: bot checks order resolution_type. Handoff if mismatch reship vs refund launched.
How does Qstomy report reimbursement status?
Qstomy lookup refund timeline, apply REF-STAT-GATE and handoff #369/#194 if needed.
Refund status capabilities
ref_stat_lookup: refund timeline + live return status
ref_stat_gate: 7 deterministic gates section 4
ref_stat_delay_edu: payment method transit time range
ref_stat_arn_share: ARN if metafield available
ref_stat_handoff: #369 failed/expired, #194 bnpl
Quantified DTC Scenario
Home brand, 112 ref_stat tickets/month, agents repeated inconsistent turnaround times.
After Qstomy REF-STAT flows: 74% self-resolved, ref_stat_bot_resolution 83%, ref_stat_false_promise 1.2%, repeat contact 7d 11%, CSAT 4.7/5.
Explore AI support, Shopify, request a demo.
What is the checklist for launching REF-STAT?
Refund status bot checklist (10 steps)
Audit ref_stat tickets 90 days
Publish refund / return timeframes aligned with bot
Connect order timeline + return portal API
Index RAG policy timeframes + REF-EXP #369
Implement REF-STAT-GATE section 4
Configure router ref_stat_* intents
Write prompt REF-STAT-GUARD section 6
Post-refund emails aligned with bot wording
Test 25 regression scenarios
Weekly ref_stat_bot_resolution dashboard
In brief
#370 = post-return refund status bot, not RMA (#10)
REF-STAT-GATE : return → refund status → timeframe → message
12 ref_stat_* intents: pending, success, failed, BNPL
Reassure without overpromising: range, not exact date
KPI ref_stat_bot_resolution: target > 78%
FAQ
Can the bot issue a refund?
No. Inform status and handoff to agent if ops action is required.
Difference with #369?
#370 = status lookup and timeframes. #369 = closed payment method ops and manual IBAN.
Customer at D+2 after refund success?
ref_stat_too_early: education on normal 5-10 day timeframe.
BNPL Klarna?
Handoff #194, not standard credit card timeframe message.
Refund failed Shopify?
Immediate handoff #369 REF-EXP, bot does not retry.
Going further
Test with mystery shopping: order refund success D+3, verify bot quotes amount + date + 5-10 day range without promising tomorrow.
Share this guide #370 with support and ops: a well-calibrated refund status bot turns post-return anxiety into factual confidence, without promising impossible dates.
Enzo
August 7, 2026
