SUM(totalIncTax) for declined + incomplete orders. The gross ‘what’s leaking’ figure before recovery deduction.
At a glance
The gross dollar value of every BigCommerce checkout that failed in the period:paymentStatus = declinedplusstatus = Incomplete. This is what’s leaking, the upper bound on opportunity, before any recovery deduction. The “after recovery” view is BC Unrecovered Value (Size of the Prize).
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
Same US homewares store on BigCommerce, 30-day window 14 Mar 26 to 12 Apr 26.
The companion view, after recovery is subtracted (from BC Unrecovered Value):
What’s interesting:
- The headline $55,374 is the gross opportunity number. This is the total dollars that tried to come in and didn’t, before any natural recovery. CFOs reading this should understand it’s the upper bound on what’s at stake.
Incompleteorders are 80% of the failed value. 55,374. This is typical,Incompleteis usually higher volume thandeclinedbecause checkout-page friction creates abandonment regardless of payment-side success rate.- Recovery shaves 44% off the gross. 55,374 came back within 30 days organically (without any merchant action). That’s healthy organic recovery. The remaining $30,830 is what targeted recovery tooling addresses.
- Annualised: 674,000/year of attempted purchases failing, of which ~90,000/year) is meaningful.
- Up + Decline Rate up = real performance regression. Investigate.
- Up + traffic up = volume effect; check rates not absolute values.
- Up + AOV up = bigger orders are failing (higher-value cart abandonment patterns).
- Down + traffic down = quieter period, less to leak.
- Down + traffic flat = recovery tooling working, OR fraud rules eased (check for fraud-loss spike before celebrating).
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Orders, filter byDeclined, sum the order totals, then repeat for Incomplete, then add. This gives you the manual equivalent of this card. BC does NOT surface this aggregate as a single dashboard metric.
Why our number may legitimately differ from a manual BC sum:
Cross-connector reconciliation (when payment processors are connected):
The dollar value of failures should partially reconcile against processor-side decline value, but the relationship is not 1:1.
Cross-platform same-metric: Adobe Commerce’s
pending_payment value is a rough analog of Incomplete; Shopify’s “abandoned checkout value” is an even rougher analog. Direct cards on those platforms are tracked in the CONNECTOR_BACKLOG. Until those ship, this card is BC-specific.
Known limitations / merchant FAQs
Why is this number so much bigger than my Stripe declined number? Because this card includes BOTHpaymentStatus = declined AND status = Incomplete. Stripe only sees attempts that reached its API. Incomplete orders, where the customer hit Place Order but the payment iframe never returned, may never have hit Stripe at all (network timeout, customer closed the tab, 3DS interstitial got blocked). On BC, Incomplete is typically 3, 5× larger than declined by volume.
Is this number “lost revenue”?
Not quite. It’s the gross “attempted purchases that didn’t complete” figure. Some of these customers came back and bought (organic recovery), some won’t ever (lost). The “lost” view is BC Unrecovered Value (Size of the Prize), which subtracts organic recoveries.
The number is huge but my CEO is asking “is this real”?
Yes, the value is real, but framing matters. Most of these customers will buy elsewhere if you don’t recover them. The right CEO conversation is: “Of this 25k came back naturally, 30k annualised is $375k/year of P&L line that proper retry tooling could capture.”
My number jumped 2× this week, what should I check?
Check whether BC Decline Rate and BC Incomplete Rate both spiked, or just one. If only Incomplete spiked, the issue is checkout-page; if only Declined spiked, payment-side or fraud-rules; if both spiked together, it’s usually traffic-mix (a low-quality affiliate burst or a discount campaign brought worse customers).
Are test orders included?
No. BC test orders use a separate flag (is_test). Vortex IQ filters them. Note: developer-environment test orders sometimes leak into production indexes when is_test isn’t set; if you see weird-looking high-value entries on BC Top Unrecovered Today, check the developer environment.
What’s the relationship between this card and Refund Value?
None directly. Refunds happen after a successful order. This card is about orders that never succeeded. Track them as separate revenue-leakage signals.
My subscription store, do recurring failures inflate this?
Yes, every failed recurring billing attempt (declined card, expired card, insufficient funds) shows up as a paymentStatus = declined order. Subscription stores often see this card sit at higher absolute values than equivalent-revenue DTC stores; that’s normal. Pair with BC Repeat Failure Customers to identify subscribers in trouble.
My multi-currency BC store, what currency does this show?
Sums across currencies arithmetically without FX. Multi-currency stores see a meaningless mixed total. Use a currencyCode-filtered view, or filter at the BC Orders level when reconciling.
Why does this number include Incomplete but BC’s order list separates them?
Because the merchant’s commercial concern is “what failed”, regardless of the BC-internal taxonomy. The two failure types aggregate naturally for executive reporting; the type-specific cards exist for diagnosis.
Is this real-time or daily?
Re-evaluated every sync (every 15-30 minutes typically). The trend chart on the card uses 30-day rolling but the underlying figure is fresh.