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).
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.
What’s interesting:
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
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).
Cross-connector reconciliation (when the merchant has connected payment processors):
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.
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.