> ## 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. # Failed Orders (count), BigCommerce **Metrics type:** [Card](/nerve-centre/overview#metrics-types-explained) > COUNT(paymentStatus=declined) + COUNT(status=Incomplete). Headline failure volume across both populations. ## At a glance > The number of BigCommerce orders in the window that ended in payment failure or never reached a paid state. The arithmetic sum of two distinct populations: `paymentStatus = declined` (the gateway said no) and `status = Incomplete` (the shopper hit Place Order but checkout never resolved). | | | | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `COUNT(orders WHERE paymentStatus = 'declined') + COUNT(orders WHERE status = 'Incomplete')`. Two failure populations summed into one headline. The dollar-value twin lives at [BC Failed Orders Value](/nerve-centre/kpi-cards/bigcommerce/bc-failed-orders-value). | | **VAT / tax treatment** | n/a, this is a count of orders, not a money figure. The dollar twin uses `total_inc_tax`, which is always tax-inclusive. | | **Shipping** | n/a, count metric. | | **Discounts** | n/a, count metric. | | **Refunds** | **Refund-status orders are NOT counted here.** A `paymentStatus = refunded` order succeeded first, then was reversed; it doesn't belong in the failure count. Only orders that never collected cash count. | | **`Incomplete` status quirk** | `Incomplete` is BigCommerce-specific: an order skeleton with `total_inc_tax` populated but no payment captured. It happens when the shopper got past payment-page initialisation but the gateway didn't return success (network glitch, 3DS timeout, customer closed tab). Healthy stores run 8-15% incomplete; persistent rates above 20% suggest checkout friction. | | **Cancelled / declined orders** | `Declined` orders count (that is the metric). `Cancelled` orders do NOT count, those are typically merchant-initiated voids on previously-authorised orders. | | **Currency** | Currency-agnostic, this is a count. Splits by `currencyCode` available via filtered views. | | **Time window** | `30D vsP` (default 30D vs the prior 30D) | | **Roles** | owner, marketing, operations | ## 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 homewares brand on BigCommerce Enterprise (same store as the [BC Total Revenue worked example](/nerve-centre/kpi-cards/bigcommerce/total-revenue)). The 30-day window covers 14 Mar 26 to 12 Apr 26. The merchant takes orders on Stencil web plus Amazon and Facebook via Channel Manager. | Failure population | `channel_id` breakdown | Order count | Avg `total_inc_tax` | At-risk dollars | | ----------------------------- | ------------------------------ | ----------- | ------------------- | ------------------------------- | | `paymentStatus = declined` | 56 web, 12 Amazon, 3 Facebook | 71 | \$156 | \$11,076 | | `status = Incomplete` | 392 web, 18 Amazon, 4 Facebook | 414 | \$107 | \$44,298 | | **Failed Orders (this card)** | | **485** | | \$55,374 | | Total successful orders | 3,540 | | | \$411,732 | | Headline failure rate | | | | **485 / (485 + 3,540) = 12.0%** | What's interesting: 1. **`Incomplete` outweighs `Declined` 5.8 to 1.** This is typical for BigCommerce stores. Declines are a payment-vendor problem (insufficient funds, fraud rules); Incompletes are a checkout-UX problem (slow page, 3DS interstitial, browser closed). The two need different remediation, see BC Decline by Payment Method for declines and the checkout-page session recorder for incompletes. 2. **485 failed orders, \$55,374 at-risk dollars, 269 unrecovered customers.** The customer-level recovery picture lives in BC Size of the Prize. Of these 485 failures, the 30-day email-first recovery join finds 216 of them later succeeded; the remaining 269 walked away. **That 269 number is the actionable marketing list.** 3. **Web absorbs the failures disproportionately.** 92% of failures are on `channel_id = 1` (Stencil web), but only 70% of total revenue is web. Marketplace orders (Amazon, Facebook) are pre-authorised by the marketplace before they hit BC, so failure rates there are structurally lower. The web checkout is the problem zone. 4. **The headline 12% failure rate is high by industry standard.** Healthy DTC stores sit 6-10%. A 12% rate annualised costs this merchant \~\$675k of gross revenue at risk, of which roughly half is recoverable with the right tooling. Action priority order on a 12% failure rate: 1. Run BC Decline by Payment Method and BC Failures by Channel ID. If one segment dominates, fix that first. 2. Wire up an abandonment-recovery flow (Klaviyo, Bloomreach Engage, Drip) to the unrecovered cohort, expect 8-15% conversion. 3. Investigate BC Repeat Failure Customers, customers who failed multiple times need human follow-up. 4. Audit the checkout page on real-customer devices (BrowserStack, FullStory, Hotjar). Slow tax calc, geo-IP redirects, and 3DS timing are the usual suspects. ## Sibling cards merchants should reference together | Card | Why pair it with Failed Orders Count | | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [BC Failed Orders Value](/nerve-centre/kpi-cards/bigcommerce/bc-failed-orders-value) | The dollar twin of this card. Count tells you "how many", value tells you "how much". A spike in count without a value spike means cheap orders are failing (low-priority); the reverse means high-AOV checkouts are leaking. | | [BC Decline Rate](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-rate) | The rate version isolated to the `paymentStatus = declined` population. Useful when you want to compare to industry benchmarks (3-5% is typical). | | [Total Revenue](/nerve-centre/kpi-cards/bigcommerce/total-revenue) | The denominator context. A 12% failure rate on $1M is more material than 12% on $100k. | ## 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) with filters set to status `Declined` and `Incomplete` for the period. The order count at the bottom of the table should match this card to within 1-2 orders (boundary timezone effects). Other BC Control Panel views that *look* like the same number but aren't: * **Analytics → Sales**: this view excludes failures by default. The headline "Orders" tile shows successful orders only. * **Analytics → Insights → Customer behaviour**: tracks abandoned carts at the *cart* layer (before checkout starts), this card tracks failures at the *checkout* layer (after Place Order was clicked). Different stages of the funnel. * **Storefront → Abandoned carts** (Plus / Pro plans): yet another stage, the cart-abandonment recovery email tool. Counts pre-checkout abandonment, not `Incomplete` orders. * **Orders → All orders, status = Cancelled**: don't confuse Cancelled (merchant void) with Declined (gateway reject). **Why our number may legitimately differ from BC Control Panel:** | Reason | Direction | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | | **Time zone**. BC Control Panel runs on store timezone; Vortex IQ runs on UTC by default. Boundary-day failures fall on different sides. | ±1 day's failures at the boundary | | **`Cancelled` inclusion**. Some BC reports group `Cancelled` and `Declined` together under "non-fulfilled". This card excludes `Cancelled`. | Vortex IQ slightly LOWER if the BC view groups them | | **Test orders**. BC test orders are flagged, Vortex IQ does not yet filter them out. Most stores have \<10 test orders/period. | Marginal | | **API rate-limit gaps**. If the BC API throttled during the most recent indexer run, the latest day's failures may be missing for a few minutes. | Self-resolves at next sync | | **Refund-vs-decline confusion**. Some merchants think a refunded order is a "failed order". This card excludes `Refunded`, those orders succeeded first. | Vortex IQ LOWER if the merchant included refunds | **Cross-connector reconciliation (when the merchant has connected payment processors):** | Card | Expected relationship | What causes legitimate divergence | | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_decline_rate`](/nerve-centre/kpi-cards/stripe/decline-rate) | BC `paymentStatus = declined` count should map to Stripe `status = failed` charge count when Stripe is the BC processor | One BC checkout can produce multiple Stripe attempts (3DS retry, customer corrects card). BC count \<= Stripe failed-charge count. The right ratio is BC `declined` ÷ Stripe `failed_charges` ≈ 0.5-0.8. | | [`paypal.pp_decline_rate`](/nerve-centre/kpi-cards/paypal/decline-failure-rate) | BC declines via PayPal map to PayPal `D` (denied) or `F` (failed) statuses | Same shape. | | [`google_analytics.ga_purchases_trend`](/nerve-centre/kpi-cards/google-analytics/purchases-trend) | GA4 doesn't fire `purchase` for failed orders; this card has no GA4 counterpart | Use GA4 `begin_checkout` minus `purchase` for a checkout-funnel approximation; the gap correlates with this card. | **The BC `Declined` + `Incomplete` distinction is unique.** Shopify uses `displayFinancialStatus = ABANDONED` for similar abandonment patterns and Adobe Commerce uses `pending_payment` for the structural twin of `Incomplete`, but neither platform splits payment-side failures from UX-side failures into separate statuses the way BC does. This makes the BC failure-recovery cards meaningfully different from the equivalents on other connectors. ***
Same-metric documentation cross-reference (for agencies running multiple platforms) The same conceptual definition lives on other commerce platforms with different status names: * [`shopify.failed_orders_count`](/nerve-centre/shopify/failed_orders_count) (planned, on the [CONNECTOR\_BACKLOG](/CONNECTOR_BACKLOG)) * [`adobe_commerce.failed_orders_count`](/nerve-centre/adobe_commerce/failed_orders_count) (planned)
## Known limitations / merchant FAQs **Why doesn't my BC Sales dashboard show this number?** The default *Analytics → Sales* view excludes failures. BigCommerce's executive dashboard is built around successful orders, so you have to go to *Orders → All orders* and filter by status `Declined` and `Incomplete` to see the same population this card counts. That filter UI is why most BC merchants underestimate their checkout leakage by a factor of 2-3x. **What's the difference between this card and the abandoned-cart count in BC?** Different stages of the funnel. BC's *Storefront → Abandoned Carts* tool tracks shoppers who added items but never started checkout (pre-checkout abandonment). This card tracks shoppers who *did* start checkout and either had their payment declined or abandoned mid-payment. Both matter; this card focuses on the post-checkout-start population because they showed harder intent and are more recoverable. **Should I worry more about Declined or Incomplete?** **Declined first if it's above 5%, Incomplete first if it's above 15%.** Declines are usually concentrated in 1-2 root causes (a fraud-rule mis-config, an expired BIN, a 3DS configuration glitch), so the fix is fast. Incompletes are usually death-by-a-thousand-cuts: slow tax calc, geo-IP redirects, browser plugin conflicts, payment iframe timing. Both need attention, but declines tend to have a single fixable lever, incompletes a checkout-page audit. **Why does this card include `Incomplete` orders that customers may have retried successfully?** Because we measure the failure side first, then check for recoveries separately in BC Size of the Prize. A customer who retried successfully shows up in BOTH the failure count here AND the recovery count there. The difference, *unrecovered* failures, is the actionable opportunity. Treating one-and-retried customers as not-a-failure would hide important checkout-friction signal. **My Stripe failed-charge count is much higher than this card, why?** Stripe counts every payment attempt; BC counts every order. One BC checkout can produce 2-3 Stripe attempts (initial decline, customer corrects expiry, 3DS retry). A 1.5x to 2x ratio between Stripe failed charges and BC failed orders is normal. If the ratio is much higher, your customers are persisting through 3+ retries before giving up, which is itself a checkout-friction signal. **Does this card include marketplace failures (Amazon, eBay, Facebook via Channel Manager)?** Yes. All `channel_id` values are summed. In practice marketplace failures are rare because the marketplace pre-authorises payment before BC sees the order. If you want web-only checkout-failure analytics, filter by `channel_id = 1` via BC Failures by Channel ID. **What is a "good" failure rate?** Industry baseline for BC Enterprise stores: 6-10% combined (declined + incomplete) on the web checkout. Above 12% means real money is leaking. Below 4% is unusual and usually means the checkout is silently rejecting traffic somewhere upstream (rate-limit, IP-block, geo-fence). Neither extreme is desirable. **Why is my count today much smaller than yesterday?** Today is incomplete data. `Incomplete` orders especially can sit in BC for hours before the indexer picks them up (the order skeleton is created when Place Order fires, but the payment-side polling can take 5-15 minutes to fail). **Use the rolling 7-day or 30-day view for stable numbers**, that's why the alert window is `30D vsP` and not `1D`. **Customers using guest checkout, do those failures count?** Yes. Guest checkout still creates an order record with `customerId = 0` (or null on some BC versions); we count the order regardless. The recovery join in BC Size of the Prize uses email-first matching, so guest customers' failures still get matched to subsequent successful orders if they used the same email. *** ### Tracked live in Vortex IQ Nerve Centre *Failed Orders (count)* 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.