> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Refund Rate Spike Alert, BigCommerce > Sudden refund volume, quality issue, packaging change, payment dispute wave. Often the first signal a SKU has gone wrong. How to read it, why it matters, ... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > 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 $100 order with a $20 partial refund counts as one refund. The dollar-weighted version is on [BC Refunded Products](/nerve-centre/kpi-cards/bigcommerce/most-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** | What's interesting: 1. **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). 2. **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. 3. **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.** 4. **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. 5. **Total cost exposure**: 22 refunds at AOV $85 = $1,870 in direct refunds, plus \~$3,000 in reverse logistics, 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.** The rapid-response playbook (when this alert fires): 1. **Decompose by SKU.** One SKU dominating = quality / sizing / fulfilment. Distributed = systemic. 2. **Decompose by channel.** Amazon-heavy = A-Z claim wave; web-heavy = customer-service spike. 3. **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). 4. **Pull the affected SKU from ads** to stop adding fuel. 5. **Email the affected cohort** proactively with refund offer, this is the highest-LTV-protection move available. 6. **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](/nerve-centre/kpi-cards/bigcommerce/refund-rate-by-channel) | The per-channel decomposition. After this alert fires, this card shows whether one channel dominates. | | [BC Refunded Products](/nerve-centre/kpi-cards/bigcommerce/most-refunded-products) | The per-SKU decomposition. The single most useful diagnostic view when this alert fires. | | [BC Top SKUs](/nerve-centre/kpi-cards/bigcommerce/top-skus) | Cross-reference to identify high-velocity SKUs in the refund pool. | | [BC Alert Fulfilment Delay](/nerve-centre/kpi-cards/bigcommerce/fulfilment-delay-alert) | Often co-fires; delayed-fulfilment customers refund more. | | [BC Alert OOS Spike](/nerve-centre/kpi-cards/bigcommerce/oos-spike-alert) | Cross-reference; OOS-then-restocked SKUs sometimes have quality issues from rushed restock. | | [BC Alert Revenue Drop](/nerve-centre/kpi-cards/bigcommerce/revenue-drop-alert) | 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](/nerve-centre/kpi-cards/bigcommerce/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](https://login.bigcommerce.com/deep-links/manage/orders), filter by `Status = 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](https://login.bigcommerce.com/deep-links/manage/reports) (Plus / Pro / Enterprise) shows per-SKU refund counts but on a daily cadence rather than real-time. For payment-side reconciliation: [Settings → Payments](https://login.bigcommerce.com/deep-links/manage/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 | **Cross-connector reconciliation (when payment processors are connected):** | Card | Expected relationship | What causes legitimate divergence | | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_refund_rate`](/nerve-centre/kpi-cards/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`](/nerve-centre/kpi-cards/paypal/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`](/nerve-centre/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`](/nerve-centre/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. | **The refund-rate-spike alert shape is BC-aligned with similar alerts on Shopify and Adobe Commerce; merchant-facing semantics are equivalent.** ***
Same-metric documentation cross-reference (for agencies running multiple platforms) * [`shopify.alert_refund_rate_spike`](/nerve-centre/shopify/alert_refund_rate_spike) (planned) * [`adobe_commerce.alert_credit_memo_spike`](/nerve-centre/adobe_commerce/alert_credit_memo_spike) (planned)
## 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](/nerve-centre/kpi-cards/bigcommerce/fulfilment-delay-alert), 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 an appropriately tuned alert threshold. **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 the normal alert threshold. **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's `total_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](/nerve-centre/kpi-cards/bigcommerce/most-refunded-products) card, which has the full decomposition. *** ### Tracked live in Vortex IQ Nerve Centre *Refund Rate Spike Alert* is one of hundreds of KPI pulses Vortex IQ tracks across BigCommerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.