At a glance
Period-over-period change in the count of orders that failed at payment. Failed orders are demand that reached checkout, picked items, attempted payment, and was rejected, the highest-intent revenue leak in any ecommerce store. A rising failed-orders trend is one of the most recoverable signals on the dashboard: each failed order has a known customer, known basket, and a payment-method or risk reason that is often fixable. The trend exposes whether the failure rate is staying flat or growing, which determines whether to investigate or escalate.
| What it counts | The change in failed-order count between the current 30-day period and the preceding 30-day period. “Failed” includes orders with payment_status = declined, payment_status = failed, or equivalent terminal-failure states from the BC Orders API. Excludes pending and authorisation-only states. |
| Sample type | Backend API data from BigCommerce orders, refreshed on the standard data refresh. |
| Why failed-orders trend matters | Failed orders represent the highest-intent revenue leak in the store. The customer wanted to buy, picked the item, entered payment, and was rejected. Recovering even 30% of failed orders typically returns 5-10% lift on net revenue with no new acquisition cost. A rising trend means either fraud-rule overreach, payment-gateway issues, or a new failure mode that needs immediate investigation. |
| Reading the value | (1) Below -2: failures decreasing; payment health improving. (2) -2 to +2: stable. (3) Above +2: alert state; new orders are failing at a higher rate than the prior period. (4) Cross-reference bc_decline_by_payment_method and bc_decline_reasons for the failure-pattern decomposition. (5) Pair with failed_orders_count (absolute) and failed_orders_value (revenue at risk) for the full picture. |
| Currency | absolute count change. |
| Time window | 30D vsP. |
| Alert trigger | failed_orders_trend > 2 (BAD threshold; +2 or more failures vs prior period). |
| Sentiment key | failed_orders_trend (TREND_BASED in SentimentClassifier; GOOD ≤ -2, BAD ≥ +2). |
| Roles | owner, operations, finance |
Calculation
Worked example
A UK-based BigCommerce fashion store, failed orders trend reading on Wednesday 15 May 26.| Period | Failed order count | Failed order value | Top failure reason |
|---|---|---|---|
| Current (15 Apr - 15 May) | 113 | £51,580 | Card declined by issuer (Visa, 67 orders) |
| Previous (16 Mar - 15 Apr) | 128 | £58,420 | Card declined by issuer (Visa, 71 orders) |
| Change | -15 orders | -£6,840 | n/a |
- Failures are decreasing period-over-period. The shift from 128 to 113 failed orders is a healthy direction. The £51,580 still in the failed pool is the recoverable revenue target, regardless of trend direction.
- Why this matters even though the trend is good. A static failed-order pool of 113 per month, at average AOV £457, represents £51K of high-intent revenue at risk. Even 30% recovery via decline-recovery flows (re-prompt with alternative payment, send recovery email with one-click checkout, retry on different network) is £15K/month of net-new revenue.
-
Decomposing the 113 failed orders by reason:
- 67 (59%): Card declined by issuer, typically insufficient funds, wrong CVV, or expired card. Recoverable via “try a different card” prompt or recovery email.
- 18 (16%): 3DS / SCA challenge failed. Recoverable via re-attempt with proper redirect handling.
- 14 (12%): Risk score too high (PSP rule rejection). Not directly recoverable; review fraud rules.
- 9 (8%): Network or gateway timeout. Recoverable via automatic retry.
- 5 (4%): Other (currency mismatch, BIN block).
-
Top recovery levers, in priority order:
- Decline-recovery email flow: trigger 30 minutes after failure with a one-click “complete your order” link to a different payment provider. Typical recovery rate 25-35%.
- In-checkout re-prompt: instead of generic “payment failed”, show “try a different card” with the basket preserved. Typical incremental recovery 5-10 percentage points.
- Network-error retry: for timeout errors (8% above), automatic retry resolves about 60% of failures.
- 3DS handling fix: if the 16% 3DS-failed bucket is unusually high, audit the redirect flow (some themes break 3DS challenges on mobile).
-
What “alert state” looks like. If next month the trend reads +5 (failures rising by 5 vs prior period), the dashboard would flag red. Likely root causes:
- Fraud rule change: PSP added a new rule that’s catching legitimate orders.
- 3DS rollout regression: a new SCA rule is rejecting non-EU customers incorrectly.
- Gateway issue: the PSP is having intermittent failures.
- BIN block expansion: the merchant is blocking BINs that historically converted.
-
Recommended response if trend goes alert:
- Day 1: Review fraud-rule changes in the PSP dashboard; revert any rule added in the prior 30 days.
- Day 1-2: Decompose failures by reason (use
bc_decline_reasons). - Day 2-3: Test checkout flow on mobile + desktop, multiple payment methods, multiple geographies.
- Day 7: Confirm trend has reverted toward GOOD.
- Read trend (count delta). Above +2 triggers alert.
- Decompose by reason via
bc_decline_reasons. - Apply recovery levers for the dominant reason buckets.
- Retest weekly to confirm recovery sticks.
| Time horizon | Action |
|---|---|
| First 1 hour | Read trend. Decompose by reason. |
| First day | Review fraud rules, test checkout. |
| First week | Stand up decline-recovery email flow. |
| Day 14 | Confirm trend reversed; recovery rate measured. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
bc_failed_orders_count | Absolute failed count for current period. |
bc_failed_orders_value | Revenue at risk from failed orders. |
bc_declined_rate | Declined % of total orders. |
bc_decline_by_payment_method | Failure decomposition by card scheme. |
bc_failures_by_channel_id | Failures by sales channel. |
order_count_trend | Successful orders trend; decline-recovery feeds back. |
stripe_decline_reasons | If Stripe is the PSP, reason decomposition lives there. |
Reconciling against the vendor’s own dashboard
Where to look in the BigCommerce control panel: Orders list filtered to status “declined” or “failed”; the PSP dashboard (Stripe, PayPal, Authorize.Net) for the failure-reason breakdown. Why the Vortex IQ failed-order trend may differ:| Reason | Direction | What to do |
|---|---|---|
| Status definition. BC has multiple “failed-like” statuses (declined, cancelled, refused). Vortex IQ aggregates the terminal-failure states. | Vortex IQ broader | Confirm which BC statuses are being counted. |
| Period boundary. BC defaults to calendar months; Vortex IQ uses 30-day rolling. | Variable | Match the period. |
| PSP-side declines vs BC-side declines. A PSP may decline before BC creates the order; only BC-recorded declines appear here. | Vortex IQ may understate | Pull PSP authorisation logs for the full picture. |
stripe.stripe_refund_rateand Stripe-specific decline cards complement this card when Stripe is the PSP.paypal.pp_decline_event_codesfor PayPal-specific decline reasons.
Known limitations / merchant FAQs
Q: We had 100 failed orders last month and 90 this month. The trend says -10. Is that good? Yes, failed-order trend below 0 (and especially below -2) is the GOOD direction. Fewer failures means more orders captured. Note that the absolute count of 90 is still a recoverable revenue pool worth attention via decline-recovery flows; trend-direction-good and absolute-count-still-meaningful can coexist. Q: Why is the threshold +2 / -2 instead of percentages? Failure counts are typically small numbers (often 0-200 per period for mid-size stores). Percent change of small numbers amplifies noise, going from 5 failures to 7 failures is a 40% increase but only 2 absolute failures. The absolute count delta is more diagnostic at the typical store size. Stores with very high failure volumes can switch to a percent-denominated alternative threshold. Q: Our failed orders dropped by 50%, did we lose customers or fix something? Either or both. Cross-reference: (a)order_count_trend, if successful orders rose proportionally, you fixed the failure mode (good); (b) if successful orders also fell, the failure rate of attempted-orders may be unchanged but fewer attempts (bad, traffic or top-of-funnel issue).
Q: We restored a paused fraud rule and failures went up. What threshold should we set?
After a fraud rule change, expect 1-3 weeks of elevated failed-order trend while the rule’s impact stabilises. Either widen the BAD threshold temporarily (+5 instead of +2) or annotate the dashboard with the rule change to provide context for the temporarily-elevated trend.
Q: Should decline-recovery be measured here or somewhere else?
The recovery rate (% of failed orders that ultimately complete) is a separate metric, see bc_organic_recovery_rate and the Vortex Mind decline-recovery report. This card surfaces the count trend; the recovery report surfaces the recovery rate.
Q: Why don’t we count payment-cancelled-by-customer orders here?
Customer cancellations (the user dismissing the 3DS challenge, closing the payment popup) are a different signal, they reflect UX friction or customer change-of-mind, not payment failure per se. Those flow into cancellation_rate (pre-payment) and the cart-abandonment metrics.
Q: We use a one-page checkout. Are failed orders different from a multi-step checkout?
The failure modes are similar (declined cards, 3DS, fraud rules) but the recovery dynamics differ. One-page checkouts have less ability to re-prompt because the customer has fewer points to interact with the page; recovery emails become the primary lever. Multi-step checkouts allow in-flow re-prompt with the basket preserved.
Q: How does this card complement failed_orders_count?
failed_orders_count shows the absolute number for the current period. This card shows the change vs prior period. Use the count for “how big is the recoverable pool right now” and the trend for “is the pool growing or shrinking.”