Failed value − recovered value. The addressable opportunity for payment retry, abandonment recovery, and account-update tooling. CFO-facing single number from the decline-recovery-intelligence report.
At a glance
The dollar value of BigCommerce checkouts that failed (declined or incomplete) and that the merchant didn’t recover within the 30-day window. The single CFO-facing number from the Decline Recovery Intelligence report. This is real money you would have collected if your retry / abandonment / account-update tooling had been working.
| What it counts | total_failed_value − total_recovered_value, where: failed_value = SUM(total_inc_tax) for paymentStatus = declined OR status = Incomplete, and recovered_value = SUM(total_inc_tax) of the same customers’ subsequent successful orders within a 30-day window (joined by email-first / customerId-fallback). |
| VAT / tax treatment | Tax-inclusive. Both sides of the subtraction use total_inc_tax. |
| Shipping | Included. Standard total_inc_tax semantics. |
| Discounts | Already deducted, the failed values reflect what the customer was trying to pay. |
| Refunds | Not in scope. Refunds happen after successful orders; this card looks at orders that never succeeded in the first place. |
| Recovery join semantics | Email-first, customerId-fallback, 30-day window. If the failed checkout had an email, we look for any subsequent successful order from the same email within 30 days. If no email (rare), we fall back to customerId (logged-in shoppers only). Crucial: we treat Declined and Incomplete as separate failure types and DO NOT merge their recovery rates. A customer who hit decline then completed a fresh checkout is “recovered”; a customer who left an Incomplete skeleton then returned and bought is also “recovered”. But a customer who failed once and never came back is unrecovered. |
| What “recovered” excludes | Recovery does NOT count if (a) the recovery order is on a different customerId than the failed order, or (b) the recovery is more than 30 days later (our window), or (c) the recovery is via a different email (the customer used Apple Pay private email on retry). These are real recoveries we miss; treat the unrecovered figure as a conservative upper bound on opportunity. |
Incomplete quirk | An Incomplete order in BC means the shopper got past payment-page initialisation but the gateway didn’t return success. Sometimes the customer retried successfully within seconds; sometimes they gave up. The card treats both cases consistently, count the Incomplete as failed, then check for any successful order from same email in 30 days. |
| Currency | Multi-currency arithmetic sum WITHOUT FX conversion. Same gotcha as BC Total Revenue. For multi-currency stores prefer per-currency views. |
| Channels / sources | Not filtered. Failures across all channel_id values are summed. Use BC Failures by Channel to slice. |
| Time window | 30D vsP (default 30D vs the prior 30D). Re-evaluated every sync. |
| Alert trigger | None directly, this is a “size of the prize” view, not a deterioration alert. Companion alerts: BC Decline Rate and BC Incomplete Rate. |
| Roles | owner, finance, marketing |
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.| Failure cohort | Count | Total failed value | Recovered (same email, ≤30d) | Recovered value | Unrecovered |
|---|---|---|---|---|---|
paymentStatus = declined | 71 | $11,076 | 28 customers retried successfully | $4,420 | $6,656 |
status = Incomplete | 414 | $44,298 | 188 retried within window | $20,124 | $24,174 |
| Combined (this card) | 485 | $55,374 | 216 | $24,544 | $30,830 |
- **The store is leaking 375,000, larger than most BC merchants’ marketing budgets. This is real money that proper recovery tooling would collect.
Incompleterecovery rate is much higher thanDeclined. 188 of 414Incomplete(45%) came back vs 28 of 71Declined(39%).Incompleteis more likely a network glitch or a momentary distraction;Declinedis more likely a structural payment issue (insufficient funds, fraud rules) that retry alone won’t fix.- The unrecovered count of 269 is the marketing list to act on. These are customers who showed strong intent (got to checkout, attempted payment) and walked away. A targeted abandonment-recovery email or SMS to this list typically converts at 8, 15%, vs 1, 3% for cold list emails.
- Annualised “Size of the Prize” = 375,000/year. This is what the BC Size of the Prize Annualised card surfaces, the same number scaled to a full year so the conversation moves from “interesting metric” to “this is a P&L line item”.
- Run BC Decline by Payment Method. If 80% of declines are on one method (e.g. PayPal Express), that’s a configuration / iframe issue you can fix in days.
- Email recovery for the 269 unrecovered. Klaviyo or Bloomreach Engage abandoned-cart flow; expect 8, 15% conversion with a small discount.
- Account-update / dunning tools. Stripe / BC have card-account-updater services; declined cards often retry-pass after the issuer pushes a new expiry.
- Checkout-page analytics. Use a session recorder on the
Incompletecohort to see what’s breaking (slow tax calc? geo-IP redirect? 3DS interstitial timing out?).
Sibling cards merchants should reference together
| Card | Why pair it with Size of the Prize |
|---|---|
| BC Failed Orders Value | The numerator before recovery is subtracted. Open this to see total at-risk dollars. |
| BC Failed Orders Count | The order-count denominator. Recovery rate = recovered_count ÷ failed_count. |
| BC Decline Rate | Trend signal. Rising decline rates mean the prize will grow if nothing changes. |
| BC Incomplete Rate | Same but for the Incomplete failure type, often a different root cause. |
| BC Organic Recovery Rate | What fraction of failures recover without any merchant action. Higher = lower addressable prize. |
| BC Size of the Prize Annualised | This card × 365 ÷ period_days. Better for board / P&L conversations. |
| BC Decline by Payment Method | Where the failures are concentrated. The fastest “fixable” wedge. |
| BC Repeat Failure Customers | Customers who failed multiple times. Highest-value list for retry / customer-service intervention. |
| BC Top Unrecovered Today | The daily action list, the largest unrecovered failures from yesterday for sales / support to chase manually. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: BigCommerce does not surface this metric natively. Size of the Prize is computed by Vortex IQ from the order index by joining failed orders to subsequent successful orders by the same customer. To partially verify, you can:- Filter Orders by status
DeclinedandIncompletefor the period, sum the order totals, that’s the numerator. - There is no native BC view for the recovery join; the closest is per-customer order history (Customers → Customer profile → Orders).
| Reason | Direction |
|---|---|
Email-first join semantics. Manual exports usually filter by customerId only. We use email-first and fall back to customerId, so we capture more recoveries (logged-out shoppers who retry). | Vortex IQ slightly LOWER unrecovered (we count more recoveries) |
| 30-day recovery window. Manual analysis often uses 7-day or 14-day windows; we use 30 days (the typical merchant abandonment-recovery email cadence). Longer window = more recoveries counted. | Vortex IQ slightly LOWER unrecovered |
| Time-zone. BC uses store timezone; we use UTC. Boundary-day effects. | Marginal |
| Currency. We sum across currencies without FX. | Mixed-currency stores see meaningless totals |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_decline_rate | BC paymentStatus = declined orders should map to Stripe status = failed charges (when Stripe is the BC processor) | One BC order can have multiple Stripe charges (3DS retry, partial captures); BC order count can be lower than Stripe charge count. |
paypal.pp_decline_rate | BC declines via PayPal map to PayPal D (denied) or F (failed) statuses | Same shape. |
pending_payment orders that are roughly analogous to BC’s Incomplete, and Shopify has displayFinancialStatus = ABANDONED for similar abandonment patterns, but the recovery-join logic is BC-specific in the current build. Equivalent cards are tracked on the CONNECTOR_BACKLOG for Shopify and Adobe Commerce.
Known limitations / merchant FAQs
Is this number really money I could capture? Most of it, with the right tooling. The 269 customers in the example showed strong purchase intent (got to checkout) and walked away. Industry benchmarks: 8, 15% of unrecovered failures convert if you reach them with an abandonment recovery email or SMS within 24 hours. Stripe’s account-update / smart-retry tooling captures another 5, 10% of declines. Together, with serious tooling investment, expect to recover 25, 40% of this number; with no tooling, expect 0%. Why is the recovery rate forIncomplete higher than for Declined?
Incomplete is usually a transient failure: customer hit Place Order, the network glitched or the iframe timed out, the customer reloaded and retried successfully. Declined is structural: insufficient funds, fraud rules, expired card, the customer can’t just reload to fix it. Different problems → different recovery rates.
The number jumped 30% week-over-week, what should I check?
Three common causes: (1) Payment-processor outage. Check BC Decline by Payment Method, if one method spiked, that’s the cause. (2) Promotion / sale brought a higher-risk traffic cohort (more declines from new customers). (3) Checkout-page regression. A theme update or a 3DS configuration change can break the iframe. Use a session recorder on Incomplete orders to spot the breakage.
Why don’t you count post-30-day recoveries?
Most abandonment-recovery tooling fires within 24, 72 hours. By 30 days the customer either converted or moved on. Counting day-31+ recoveries would inflate the recovery rate without giving the merchant actionable information. The 30-day window is a deliberate trade-off, real recoveries beyond that are missed, but they’re also outside the merchant’s intervention window.
My recovery-tooling spend is high but this number isn’t dropping, what’s going on?
Two possibilities: (1) your traffic mix shifted and gross failures are growing as fast as recoveries, masking the tooling impact. Look at BC Failed Orders Value and BC Organic Recovery Rate trends separately. (2) Recovery tools are sending emails but conversion is poor, segment performance and check copy / discount strength.
Does this card include refund-driven recoveries?
No. A customer who failed checkout, then succeeded, then refunded counts as recovered (the failed → success transition is what we measure). Refunds are a separate signal tracked elsewhere. We don’t double-penalise.
My multi-currency BC store, what currency is this in?
Sums across currencies arithmetically without FX. Multi-currency stores get a mixed-currency total, which is usually meaningless. Use per-currency views (BC Failed Orders by Currency, planned) or filter by currencyCode for accuracy.
Why is the annualised version more useful for board reporting?
A monthly 375k feels meaningful. Same data, but framing matters. Use BC Size of the Prize Annualised for executive conversations, this card for daily / weekly operational tracking.
Customers using guest checkout, do those failures count?
Yes. Guest checkout still captures email at the address-entry step in BC. We use email-first joining, so guest customers’ failures and recoveries are correctly tracked. Only customers who fail BEFORE entering an email (very rare, only on theme-misconfigured stores) fall outside the join.