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) andstatus = 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. |
| 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. |
| Channels / sources | Not filtered. Failures across all channel_id values are summed: Stencil web (1), Channel Manager marketplaces, POS. Use BC Failures by Channel ID to slice. |
| Do not merge with declined-rate | Declined and Incomplete have different fix levers (payment-vendor vs checkout-UX) and MUST be reported separately at the action layer. This card is a single headline for executives; pair it with BC Decline Rate and BC Incomplete Rate to see the split. |
| Time window | 30D vsP (default 30D vs the prior 30D) |
| Alert trigger | None directly. Companion alerts: BC Decline Rate and BC Incomplete Rate. |
| 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). 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% |
IncompleteoutweighsDeclined5.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.- 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.
- 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. - 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.
- Run BC Decline by Payment Method and BC Failures by Channel ID. If one segment dominates, fix that first.
- Wire up an abandonment-recovery flow (Klaviyo, Bloomreach Engage, Drip) to the unrecovered cohort, expect 8-15% conversion.
- Investigate BC Repeat Failure Customers, customers who failed multiple times need human follow-up.
- 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 | 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 | The rate version isolated to the paymentStatus = declined population. Useful when you want to compare to industry benchmarks (3-5% is typical). |
| BC Incomplete Rate | Same as above but for the status = Incomplete population. Different root causes and different fix levers, never merge with decline rate. |
| BC Size of the Prize | Failed value minus recovered value. The dollar headline for the recoverable opportunity. |
| BC Decline by Payment Method | Where the declines are concentrated. Often one method dominates and the fix is days, not weeks. |
| BC Failures by Channel ID | Per-channel_id breakdown. Use when a marketplace (Amazon, Facebook, eBay) goes wrong vs the Stencil web checkout. |
| BC Repeat Failure Customers | The customer-level view, customers who failed more than once. Highest priority for human intervention. |
| Total Revenue | The denominator context. A 12% failure rate on 100k. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Orders → All orders with filters set to statusDeclined 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
Incompleteorders. - Orders → All orders, status = Cancelled: don’t confuse Cancelled (merchant void) with Declined (gateway reject).
| 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 |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.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 | BC declines via PayPal map to PayPal D (denied) or F (failed) statuses | Same shape. |
google_analytics.ga_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. |
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.
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 statusDeclined 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.