Sudden refund volume, quality issue, packaging change, payment dispute wave. Often the first signal a SKU has gone wrong.
At a glance
Real-time alarm when the rolling-24h refund rate exceeds two standard deviations above the prior 30-day baseline. Catches a quality-defect wave on a hot SKU, a packaging-change regression, a payment-dispute storm from a fraudulent batch, or a sizing chart error on apparel before the customer service queue catches fire. BigCommerce stores typically have higher refund-rate variance than Shopify stores because of the longer fulfilment cycle and broader B2B mix; the alert engine auto-tunes baselines per customer group.
| What it counts | refund_count_24h / order_count_24h against a 30-day rolling baseline computed by hour-of-day-and-day-of-week. Z-score is computed using the historical standard deviation per slot. Fires when current z-score > 2 AND absolute refund rate > 4% (dual condition prevents low-volume false positives). |
| API endpoint | BC GET /v3/orders/{order_id}/transactions filtered to refund-type transactions, plus GET /v2/orders for the order denominator. Webhooks: store/order/refund for real-time updates. |
| VAT / tax treatment | Tax-inclusive on both sides. The rate is unitless. |
| Shipping | Refunded shipping is counted as part of the refund event regardless of whether the merchant chose to refund shipping. |
| Discounts | Refunds are processed against the customer-billed amount (post-discount). |
| Refunds | This is the metric. |
| Cancelled orders | Cancelled-before-fulfilment orders are NOT counted as refunds; they’re cancellations. The denominator excludes them too. |
Incomplete orders | Excluded. |
| Currency | Multi-currency, the rate is unitless so currency is not a concern. |
| Channels | All channels included by default. Per-channel decomposition is critical for diagnosis, a refund spike on Amazon is usually a different cause than a refund spike on web (Amazon: A-Z claims; web: customer service requests). |
| B2B Edition behaviour | B2B refunds typically run through a different process (issued credit memo, not refund). The alert auto-detects B2B orders and applies a B2B-appropriate baseline (typically 0.5-2% range, much lower than DTC 3-8%). |
| Partial refunds | Counted at refund-event granularity. A 20 partial refund counts as one refund. The dollar-weighted version is on BC Refunded Products. |
| Disputes / chargebacks | Disputes initiated through the gateway (Stripe, PayPal) appear as refunds in BC if the merchant resolved by refunding. Chargebacks resolved by losing-the-dispute also appear; chargebacks won by the merchant do not. |
| 30-day baseline | Same hour-of-day, same day-of-week, averaged over the prior 30 days. Holidays in the baseline window distort the comparison. |
| Time window | RT (rolling 24-hour window evaluated every 15 minutes). |
| Alert trigger | rolling-24h refund rate >2σ vs 30D baseline |
| Sentiment key | refund_rate |
| Roles | owner, operations, finance |
Calculation
Calculated automatically from your BigCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US fashion brand on BigCommerce Pro. Baseline 30-day refund rate: 4.2% with σ = 0.6%. The 75th percentile day reads ~5%; a 2σ excursion would be 5.4% or higher. Window: 24 hours ending 18:00 UTC on 18 Apr 26.| Day | Orders | Refunds | Refund rate | Z-score | Status |
|---|---|---|---|---|---|
| 14 Apr | 412 | 18 | 4.4% | +0.3σ | Normal |
| 15 Apr | 388 | 16 | 4.1% | -0.2σ | Normal |
| 16 Apr | 425 | 19 | 4.5% | +0.5σ | Normal |
| 17 Apr | 401 | 20 | 5.0% | +1.3σ | Elevated |
| 18 Apr | 445 | 31 | 7.0% | +4.7σ | ALERT FIRES |
- The 17 Apr “elevated” reading was the early warning. A 1.3σ deviation isn’t a fire but is informative; combined with the 18 Apr fire, the pattern is a 48-hour ramp-up. Investigation should include orders placed 5-7 days ago (typical refund-request lag).
- Decompose by SKU first. Open the alert payload, sort refunds by SKU. If 70%+ are one SKU, you have a quality issue on that SKU. If they’re distributed, the cause is likely sizing-chart, packaging, or fulfilment.
- In this scenario, 22 of 31 refunds were on a single SKU: “Linen camp shirt, men, M”. The merchant looked at customer-service notes: “fits two sizes too small” was the dominant complaint. The cause was a manufacturing variance on the M-size production run; a batch shipped 7 days earlier had run small.
- The action sequence: (a) pull the SKU from active marketing immediately, (b) email all customers who ordered in the affected window with a proactive refund offer, (c) audit warehouse stock for the bad batch and quarantine, (d) update the product page sizing guide to reflect the variance until the batch is exhausted.
- Total cost exposure: 22 refunds at AOV 1,870 in direct refunds, plus ~8,000 in lifetime-value damage from negative reviews. Catching this 24 hours earlier would have prevented ~$2,000 of the LTV damage by getting ahead of the review wave.
- Decompose by SKU. One SKU dominating = quality / sizing / fulfilment. Distributed = systemic.
- Decompose by channel. Amazon-heavy = A-Z claim wave; web-heavy = customer-service spike.
- Decompose by ship date. A cluster of refunds for orders shipped on the same day points to a packaging-day defect (wrong glue, contaminated packaging, wrong picker).
- Pull the affected SKU from ads to stop adding fuel.
- Email the affected cohort proactively with refund offer, this is the highest-LTV-protection move available.
- Document for post-incident review. Repeat refund-rate spikes on the same SKU family flag deeper supplier-quality issues.
Sibling cards merchants should reference together
| Card | Why pair it with Refund Rate Spike Alert |
|---|---|
| BC Channel Refund Rate | The per-channel decomposition. After this alert fires, this card shows whether one channel dominates. |
| BC Refunded Products | The per-SKU decomposition. The single most useful diagnostic view when this alert fires. |
| BC Repeat Failure Customers | Surfaces customers refunding multiple times, often a fraud pattern. |
| BC Top SKUs | Cross-reference to identify high-velocity SKUs in the refund pool. |
| BC Alert Fulfilment Delay | Often co-fires; delayed-fulfilment customers refund more. |
| BC Alert OOS Spike | Cross-reference; OOS-then-restocked SKUs sometimes have quality issues from rushed restock. |
| BC Alert Revenue Drop | Refund rate spikes within 24-48 hours of order events; if both alerts fire same day, the revenue cause may be quality, not funnel. |
| Total Revenue | Net revenue context (gross less refunds). |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Orders → All orders, filter byStatus = Refunded, sort by date descending. The count over the last 24h should match this card’s numerator within 1-2 (boundary timing).
For per-product refund history: Reports → Refund Report (Plus / Pro / Enterprise) shows per-SKU refund counts but on a daily cadence rather than real-time.
For payment-side reconciliation: Settings → Payments → individual gateway dashboards (Stripe, PayPal) show refund transactions independently.
Why our refund rate may differ from BC’s daily report:
| Reason | Direction |
|---|---|
| Window alignment. We use rolling-24h; BC’s report uses calendar-day. Same total spread differently. | Either direction |
| Partial refund treatment. We count at event-level; BC’s reports vary, some show $-weighted, some count-weighted. | Either direction depending on BC view |
| B2B credit memos. BC distinguishes credit memos from refunds in some plan tiers; we treat both as refunds for rate purposes. | Vortex IQ HIGHER on B2B-heavy stores |
| Chargeback timing. A chargeback won 30 days post-fact appears in our refund metric on the resolution date; BC may show it on the original transaction date. | Different timing |
| Store credit refunds. Some merchants refund to store credit rather than original payment; we count both, BC’s gateway view shows only payment-back. | Vortex IQ HIGHER if store credit used |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_refund_rate | Should match within 1-2% on Stripe-paid orders | Stripe sees only Stripe-paid transactions; BC sees all gateways. Differences flag a gateway-specific issue. |
paypal.pp_refund_rate | Should match for PayPal-paid orders | PayPal includes some non-checkout refunds (manual invoices) that BC won’t surface. |
amazon_sp.amazon_a_z_claim_rate | Amazon A-Z claims often correlate with this alert on Amazon channel orders | A-Z claims have a 90-day window; the cards align in trend but not in event timing. |
gorgias.gorgias_refund_request_volume | Customer-service refund-request volume leads this card by 4-24 hours | Gorgias / Zendesk volume is the leading indicator; this card is the lagging confirmation. |
Known limitations / merchant FAQs
My refund rate is always around 8-12% as a baseline, much higher than your 4% floor. Why? You’re probably in a high-refund category (apparel, footwear, custom goods). The alert auto-tunes its baseline to your store’s history; the 4% floor is the absolute minimum. Your alerts will fire only when your store-specific baseline plus 2σ is exceeded, regardless of the absolute floor. Configure category-aware presets under Settings → Alerts → Industry baseline. The alert fired but my customer service team says everything is normal. Are they right? Possibly, possibly not. Customer service sees the volume reaching them; the refund alert sees what merchants choose to process. A spike in proactive refunds (auto-refund for delayed shipments, for example) doesn’t reach customer service. Cross-reference with BC Alert Fulfilment Delay, if fulfilment delayed and you auto-refund, that’s the silent cause. Why is the dual condition (>4% AND z-score >2)? Single-condition gets noisy. A z-score-only fire on a low-volume slot (3 AM Sunday with 10 orders and 2 refunds = 20%, +5σ) doesn’t represent a meaningful event. The 4% floor combined with z-score ensures both statistical AND practical significance. B2B Edition shows credit memos but not refunds. How does this affect the alert? We treat credit memos as refunds for rate-calculation purposes. B2B Edition stores typically have refund rates in the 0.5-2% range; the alert’s auto-tune detects this and applies appropriate sensitivity. Don’t apply DTC thresholds to B2B, you’ll get constant noise. My alert fires on the day I roll out a generous “no questions asked” returns policy. Is that the cause? Yes, almost certainly. A policy liberalisation lifts refund rate by 2-5 percentage points permanently. Wait 30 days for the new baseline to stabilise, then resume normal alert sensitivity. For known policy changes, manually shift the baseline forward by 30 days under Settings → Alerts → Baseline reset. A customer keeps refunding orders. Should this trigger the alert? Possibly. A single repeat-refunder doesn’t usually move the rate enough to fire, but a small group of fraud-pattern refunders can. Pair with BC Repeat Failure Customers, if the alert correlates with a fraud cluster, block the customers and the alert resolves itself. Should I forward this to the operations team or the marketing team? Operations first, marketing CC. Operations triages the SKU / quality / fulfilment cause; marketing pauses ads / emails pointing at affected products. Finance gets a separate notification with the dollar exposure. My alert says 7% but my Shopify-clone storefront shows 5% for the same store. Are they synced? No, they’re computing differently. BC’stotal_inc_tax aggregates more line components (handling, regional fees) than Shopify’s total_price; refunds against those line components count in BC but not in Shopify. Don’t try to reconcile across platforms; reconcile within-platform against the gateway processor.
The alert fired but my refund-rate dashboard reads only 5%. Why?
The dashboard is daily; the alert is rolling-24h. A 24-hour spike to 7% averages out across the day to 5% if the prior 16 hours were normal. The alert is the leading-edge view; the dashboard is the lagging-stable view. Both running together is the right pattern.
Why doesn’t the alert decompose by SKU automatically in the payload?
Payload size constraints; an alert with 30 SKU breakdowns is unwieldy. The payload includes the top-3 contributing SKUs and a deep-link to the BC Refunded Products card, which has the full decomposition.