At a glance
Refund rate decomposed by channel_id over the trailing 30 days, with prior-30-day comparison. Different channels have structurally different refund profiles: Amazon’s A-Z claim system makes refund rates higher than web; B2B portal’s relationship-based selling makes refunds rare; POS in-store returns are walk-up-only and rarely come back through this metric. Aggregate refund rate hides the channel that’s actually problematic.
| What it counts | (refunded_orders_30d / total_orders_30d) * 100 GROUP BY channel_id with vs prior 30 days. Refunded includes any order where a refund transaction was posted (full or partial). |
| API endpoint | BC GET /v3/orders/{order_id}/transactions filtered to refund-type plus GET /v2/orders for the denominator. Channel mapping via GET /v3/channels. |
| VAT / tax treatment | Tax-inclusive on refund computation. The rate is unitless. |
| Shipping | n/a (rate metric). |
| Discounts | n/a. |
| Refunds | The numerator. |
| Cancelled orders | Excluded from both numerator and denominator (cancellations aren’t refunds). |
Incomplete orders | Excluded. |
| Currency | n/a. |
| Channel coverage | All BC channels. Marketplaces show structurally higher rates (Amazon 6-12% typical, eBay 4-8%, web 3-6%, B2B portal 0.5-2%, POS 0.2-1%). The alert’s 8% threshold catches problems on web channels but is loose enough to avoid false positives on marketplace channels. |
| B2B Edition behaviour | B2B portal refund rate is structurally low (0.5-2%); the alert’s 8% threshold rarely fires. Configure tighter B2B threshold (3%) if your B2B book matters; an 8% B2B refund rate would already be a five-alarm event. |
| A-Z claim handling | Amazon’s A-Z claims often resolve as refunds and appear on this card. Amazon-channel refund rate above 10% is a seller-rating concern (above the LSR-equivalent 4% threshold for A-Z claims) and should be investigated immediately. |
| Partial vs full refund | Both count. Stores wanting only-full-refund metric should configure under Settings → Refund definition → Full only. |
| Time window | 30D vsP (rolling 30 days vs prior 30). |
| Alert trigger | any channel >8%. Channel-cohort thresholds available: web 8%, marketplace 12%, B2B 3%, POS 2%. Configure under Settings → Alerts → Channel cohort. |
| 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. Snapshot for 1 Apr to 30 Apr 26 vs 1 Mar to 31 Mar 26.channel_id | Channel | Orders | Refunds | Rate | vs P30D | Status |
|---|---|---|---|---|---|---|
1 | DTC web | 4,820 | 232 | 4.8% | -0.2pp | Healthy |
1019847 | Amazon Channel Manager | 1,140 | 138 | 12.1% | +2.3pp | ALERT FIRES (cohort threshold) |
1019850 | Facebook Shop | 380 | 24 | 6.3% | flat | Healthy |
12000004 | B2B portal | 612 | 8 | 1.3% | flat | Healthy |
1020111 | Walmart | 220 | 19 | 8.6% | +0.3pp | Healthy (marketplace cohort) |
1020114 | POS | 380 | 4 | 1.1% | flat | Healthy |
| Headline | 7,552 | 425 | 5.6% | flat | Hidden alert |
- Amazon at 12.1% (+2.3pp) fires the alert under the marketplace-cohort threshold of 10%. This is the actionable signal. Amazon refund rate above 10% triggers concern about A-Z claim escalation; sustained above 12% raises seller-rating risk.
- The headline 5.6% looks healthy and would not fire any alert. This is exactly why per-channel decomposition matters: aggregate rates hide channel-specific problems. Amazon’s 138 refunds (32% of total refunds despite 15% of orders) is the concentration the headline obscures.
- Diagnostic sequence: (a) Decompose Amazon refunds by SKU, find the SKU dominating, (b) check Amazon Seller Central for A-Z claim reasons (fit, quality, late shipment), (c) check whether Channel Manager ship-time has slipped (late shipments cause A-Z claims at 5x normal rate). In this case 87 of 138 Amazon refunds were on a single SKU “summer dress, M, blue”, with sizing complaints, identical to a known DTC issue.
- The DTC channel rate (4.8%) is structurally lower than Amazon (12%) for the same SKU. Amazon’s customer base trends toward higher refund rates (lower brand loyalty, easier returns) and the A-Z claim escalation pathway. A 2-3x Amazon-vs-web refund rate gap is the BC-ecosystem norm, not a problem.
- B2B portal at 1.3% is healthy. B2B refunds are rare because customers test product before placing PO; when they happen, they tend to be large credit memos rather than small returns. Watch for B2B drift above 3%, that’s an account-management problem, not an operational one.
- Apply cohort thresholds. Web 8%, marketplace 10-12%, B2B 3%, POS 2%; never use a single threshold across cohorts.
- For Amazon spikes specifically, decompose by SKU first. One SKU dominating = quality / sizing issue.
- For SKUs visible in Amazon refunds, check DTC web for the same SKU, often the issue is product-wide and Amazon is the leading indicator due to harsher buyer base.
- For B2B drift, contact the affected wholesale customer directly rather than relying on operational fix; B2B refunds are relationship signals.
- Pair with BC Refunded Products for SKU-level decomposition.
Sibling cards merchants should reference together
| Card | Why pair it with Refund Rate by Channel |
|---|---|
| BC Alert Refund Rate Spike | The real-time alarm; this card is the trend view. |
| BC Refunded Products | The per-SKU decomposition. |
| BC Repeat Failure Customers | Surfaces customers refunding repeatedly, often a fraud pattern. |
| BC Channel Fulfilment Rate | Late fulfilment drives refunds; the two often co-move. |
| BC Channel AOV | High-AOV channels with high refund rates may be selling premium items that disappoint. |
| BC Channel Conversion Rate | A high-conversion channel with high refund means misleading product description. |
| BC Top SKUs | Cross-reference with refund concentration. |
| Total Revenue | Net revenue context (gross less refunds per channel). |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Orders → All orders, filter byStatus = Refunded, then by individual channel. BC does not natively compute per-channel refund rate; the closest is Reports → Refund Report (Plus / Pro / Enterprise) which shows refunds but not per-channel rate. For per-marketplace refunds: Channel Manager → individual marketplace → Refunds tab.
Why our channel refund rate may differ from BC / marketplace view:
| Reason | Direction |
|---|---|
| A-Z claim treatment. We count A-Z claims that resolved as refunds; Amazon’s seller dashboard separates A-Z claims from refunds. | Vortex IQ HIGHER on Amazon |
| Partial refund handling. We count event-level; some BC reports count by dollar-weighted. | Either direction |
| B2B credit memos. We count credit memos as refunds for rate computation; BC distinguishes them in some plan tiers. | Vortex IQ HIGHER on B2B |
| Channel attribution. We attribute refunds to the original-order channel; some marketplaces attribute to the refund channel (e.g. customer service refund attributed to web). | Either direction |
| Window alignment. We use rolling-30; BC reports calendar-month. | Either direction near boundaries |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_refund_rate_by_processor_id | Stripe refunds match web channel rate within 1-2% | Stripe sees Stripe-paid orders only; multi-gateway stores have additional refunds elsewhere. |
amazon_sp.amazon_a_z_claim_rate | A-Z claim rate co-moves with Amazon channel refund rate | A-Z claims have a 90-day window; rate computation differs. |
paypal.pp_refund_rate | PayPal refunds match the PayPal-paid subset | PayPal includes some non-checkout refunds (manual invoices). |
source_name) and Adobe Commerce (per store_id); merchant-facing semantics are equivalent.
Known limitations / merchant FAQs
My Amazon refund rate is 12% but my web is 5%. Is Amazon a worse market for my brand? Probably not. Amazon’s customer base structurally returns more (lower brand loyalty, easier returns process via A-Z claims). A 2-3x Amazon-vs-web refund rate is the BC-ecosystem norm. Be concerned only when Amazon exceeds 12-15% or when the gap widens beyond 3x your web rate. Why is my B2B portal at 1.3% so much lower than DTC? B2B customers test product before placing PO; refunds when they happen are large credit memos rather than small returns. Plus B2B sales reps build relationships that resolve issues before they become refunds. Watch for B2B drift above 3%, that’s an account-management problem. The alert fired on Amazon at 10.5% but my web is fine. What’s the cause likely? Most common: an Amazon-specific SKU has a quality / sizing issue that DTC web doesn’t see (because the SKU is Amazon-only or the listing copy is different on Amazon). Decompose by SKU. Second most common: late shipments are causing A-Z claims; cross-reference BC Channel Fulfilment Rate for the Amazon channel. My POS shows 1.1% refund rate but our store has a “no refund except for defects” policy. Why isn’t it 0%? The 1.1% likely covers (a) defective returns, (b) post-purchase staff adjustments (price corrections, sale-application after the fact), (c) employee-discount fixes. POS refund rates of 0.5-1.5% are normal even on strict-policy stores. What’s the right cohort threshold? Defaults: web 8%, marketplace 12%, B2B 3%, POS 2%. Tighten if your brand has lower-than-norm refund rates; loosen if higher. Configure under Settings → Alerts → Channel cohort. My headline refund rate is 5.6% but Amazon alone is 12%. Should the headline alarm at 5.6%? No, that’s a healthy aggregate. The whole point of per-channel decomposition is catching channel-specific issues before they degrade the headline. The cohort-based per-channel alert fires at 10% on Amazon (correctly catching the issue) without alerting on the healthy aggregate. Should this card include cancelled orders? No. Cancellations happen pre-fulfilment and are operationally distinct from refunds. Including them would inflate the rate without reflecting customer dissatisfaction. My B2B portal credit memo workflow doesn’t writerefund transactions; will the rate read 0%?
Probably yes. We detect credit memos via the BC credit_memo field (Enterprise plan only). For Pro and below, B2B credit memos may not flow into refund counting. Configure under Settings → Refund detection if your B2B workflow uses non-standard fields.
My marketplace refunds spiked but my customer service queue is normal. Where are the refunds coming from?
Likely auto-refunds from the marketplace (Amazon A-Z claims, eBay buyer-protection, Walmart returns). These resolve without involving your customer service team but appear here. Check Amazon Seller Central → A-Z Claims for the recent spike.
Why exclude Incomplete and Cancelled from the denominator?
Because including them would understate the rate (the denominator inflates with non-fulfilled orders that never had a chance to refund). Including them makes the metric meaningless across stores with different abandonment / cancellation patterns.