Carts that started checkout but never paid (status=Incomplete). UX-side leak, distinct from declined payments. Industry baseline 8-15%; above 20% suggests checkout friction, slow page, or payment-method gap.
At a glance
The percentage of BigCommerce orders that ended at status = Incomplete, customers who got past payment-page initialisation but the gateway never returned a successful capture. This is the UX-side leak, structurally distinct from outright payment declines. Industry baseline 8-15%; above 20% means real checkout friction.
| What it counts | COUNT(orders WHERE status = 'Incomplete') ÷ COUNT(all orders) × 100. Note: BC indexes Incomplete orders even though no payment was captured, the order skeleton is created the moment the customer hits Place Order. This is what makes BC’s Incomplete analytically useful in a way that doesn’t exist on Shopify or Adobe Commerce. |
| VAT / tax treatment | n/a, the rate is a count ratio. Note: Incomplete orders carry a populated total_inc_tax (always tax-inclusive) even though no cash was taken, this is the “phantom revenue” effect that inflates BC Total Revenue. |
| Shipping | n/a, count metric. |
| Discounts | n/a, count metric. |
| Refunds | Excluded. Refunded orders had successful payment first; they don’t belong in the Incomplete population. |
| Cancelled orders | Excluded. Cancelled is merchant-initiated voids on captured orders. |
Declined orders | Excluded from this card. Declined is the payment-side failure population; this card isolates the UX-side population. The two have different fix levers and must NOT be merged. For the payment-side rate use BC Decline Rate. |
| What “Incomplete” actually means in BC | The customer reached the payment page, BC committed an order record, the payment processor was called, and one of these happened: (a) payment iframe timed out, (b) 3DS challenge never resolved, (c) network glitch dropped the success callback, (d) customer closed the tab mid-3DS, (e) processor returned an ambiguous response BC couldn’t classify. BC defaults all five to Incomplete rather than Declined. |
| Currency | Currency-agnostic (rate is a count ratio). Multi-currency stores often see significantly different incomplete rates per currency, EUR/GBP traffic carries SCA / 3DS2 friction USD/CAD traffic doesn’t. |
| Channels / sources | Not filtered. All channel_id values contribute. Incomplete is structurally a Stencil web (channel_id = 1) and POS phenomenon, marketplace channels (Amazon, Facebook via Channel Manager) pre-authorise payment so they almost never produce Incomplete orders. |
| Time window | 30D vsP (default 30D vs the prior 30D) |
| Alert trigger | >15% (checkout friction), fires when more than 15% of orders end Incomplete. The threshold is the upper edge of “normal”; sustained breaches indicate fixable checkout-page issues. |
| Sentiment key | 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 UK-based fashion retailer on BigCommerce Plus. The 30-day window covers 14 Mar 26 to 12 Apr 26.| Cohort | Total orders | Incomplete | Incomplete rate | Verdict |
|---|---|---|---|---|
| All channels combined | 4,025 | 414 | 10.3% | Healthy band |
channel_id = 1 (Stencil web) | 3,232 | 392 | 12.1% | Slightly elevated |
| Channel Manager (Amazon, Facebook) | 719 | 0 | 0.0% | Structurally expected |
| POS Terminal A | 74 | 22 | 29.7% | Broken |
| Mobile Safari (iOS 17+) traffic only | 1,140 | 215 | 18.9% | Investigate |
| Desktop Chrome traffic only | 1,560 | 78 | 5.0% | Healthy |
| Prior 30D window (vsP) | 4,180 | 376 | 9.0% | (baseline for comparison) |
- The headline 10.3% is healthy, sits in the 8-15% industry baseline. The store-wide rate is fine; the problem is concentration.
- Mobile Safari is failing 3.8x more than desktop Chrome. Almost always a 3DS / Apple Pay iframe issue specific to iOS Safari’s stricter cookie handling. Common root cause:
SameSite=Laxcookie policy breaks the BC payment iframe on iOS. Fix is a server-side cookie configuration change, takes hours, not weeks. - POS Terminal A is at 29.7% (matches the BC Failures by Channel ID finding). All POS Incompletes are usually hardware: chip-reader timeout, receipt-printer offline, network drop on the till’s tablet. Walk the device.
- The +1.3 percentage-point vsP increase looks small but matters. A 14% relative increase (10.3 vs 9.0) on a Hero card moves the alert needle even though both numbers are in the “healthy” band. Investigate whether the rise is concentrated in one segment (the iOS Safari segment in this example) or distributed.
- Run device-class breakdown (Vortex Mind incomplete-cohort report). The mobile Safari segment is almost always where the action is.
- Audit checkout iframes (FullStory / Hotjar session recordings of customers who hit Incomplete). Look for: 3DS challenge that never resolves, geo-IP redirect interruption, payment-method iframe that loads then disappears.
- Walk POS terminals. Hardware fixes are fast but require physical access; don’t put them off.
- If iOS Safari is the segment, BC support has a known runbook for
SameSitecookie issues; raise a ticket with the segment data attached. - Pair with BC Decline Rate. If decline rate is also elevated, the problem is store-wide (gateway / payment-vendor); if decline is fine and only Incomplete is elevated, the problem is checkout-page UX.
Sibling cards merchants should reference together
| Card | Why pair it with Incomplete Rate |
|---|---|
| BC Decline Rate | The payment-side rate. Together they form the full failure picture. Never merge them, different fix levers (UX vs payment vendor). |
| BC Failed Orders Count | The combined headline (declined + incomplete). Use this card to drill into the UX-side half. |
| BC Failed Orders Value | The dollar twin. Lets you size the cost of a 1pp Incomplete-rate reduction (typically 5M-revenue store). |
| BC Size of the Prize | The recoverable opportunity. Incomplete recovery rates are usually higher than Decline recovery, so a high Incomplete rate doesn’t fully translate to a high prize. |
| BC Failures by Channel ID | The channel breakdown. Incomplete on POS = hardware; on web = iframe / 3DS; on Channel Manager = should be near-zero. |
| BC Decline by Payment Method | Cross-cut: a method that’s pre-decline-but-also-pre-incomplete (e.g. a slow PayPal Express iframe) shows up on both this card and the decline-by-method card. |
| Conversion Rate (when GA4 connected) | The funnel-view trade-off. Rising Incomplete rate often correlates with falling GA4 checkout conversion in the same period. |
| Total Revenue | The “phantom revenue” context, Incomplete orders carry total_inc_tax even though no cash arrived. The wider the Incomplete gap, the more inflated Total Revenue is. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Orders → All orders, filter by statusIncomplete for the period. The count divided by total orders for the same period should match this card to within 0.5 percentage points (timezone effects).
Other BC views that look adjacent:
- Storefront → Abandoned carts: a different stage of the funnel (pre-checkout abandonment). Customers there haven’t started checkout yet; here they did but never paid.
- Analytics → Insights → Customer behaviour → Conversion: tracks session-level conversion, not order-level Incomplete state.
- Analytics → Sales: defaults to excluding Incomplete entirely. The headline order count there is your “successful” denominator.
| Reason | Direction |
|---|---|
| Time zone. BC export uses store timezone; we use UTC. Incomplete orders near midnight on the boundary fall on different sides. | ±0.5 pp at boundary |
Cancelled confusion. Some merchants think a Cancelled order with no payment was Incomplete. BC distinguishes them; we follow BC’s distinction. | Vortex IQ LOWER if merchant counts cancelled |
| Indexer lag. Incomplete orders sometimes take 5-15 minutes longer to index than Captured orders (BC writes them in a slower path). | Vortex IQ slightly LOWER for “today” |
Manual Verification Required. Some BC stores configure orders to land in Manual Verification Required instead of Incomplete for certain fraud-rule outcomes. We don’t count MVR here. | Vortex IQ LOWER if MVR is being used as a synonym |
| Test orders. Not currently filtered. | Marginal |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
google_analytics.ga_ecommerce_conversion_rate | Inverse correlation, rising Incomplete rate should depress GA4 checkout conversion in the same period | GA4 measures session-to-purchase; this card measures order-creation-to-payment-success. Different stages, different denominators. |
google_analytics.ga_begin_checkout minus google_analytics.ga_purchases_trend | The GA4 checkout-funnel drop approximates the BC Incomplete count | GA4 is missing 10-25% of orders due to ad blockers / cookie rejection; treat as directional only. |
Incomplete status is unique to BC’s data model. Shopify uses displayFinancialStatus = ABANDONED for similar abandonment-after-checkout-start flows, but Shopify’s status fires later in the funnel and on different triggers; the populations are not 1:1. Adobe Commerce uses pending_payment, which is the closest structural analogue but still differs in indexing semantics. Equivalent UX-side incomplete-rate cards on those platforms are tracked on the CONNECTOR_BACKLOG.
Known limitations / merchant FAQs
My Incomplete rate is 18%, is that bad? Yes, that’s above the alert threshold (15%) and warrants action. Industry baseline for healthy BC stores is 8-15%; 15-20% means real checkout friction; above 20% means something is materially broken. The action sequence is in the Worked example above, start with device-class breakdown, then iframe audit. Why is my Incomplete rate higher on mobile than desktop? Three structural reasons specific to mobile checkout: (1) iOS SafariSameSite cookie strict-mode breaks BC payment iframes; this is the single biggest cause of mobile-Safari Incompletes. (2) Network drops are far more common on mobile than desktop; a tunnel ride or a shaky 4G signal kills the success callback. (3) Apple Pay / Google Pay flow timing sometimes mis-aligns with BC’s redirect-back logic. Mobile checkout problems compound; a 2x mobile-vs-desktop ratio is normal, 4x or higher is fixable.
What’s the difference between Incomplete and Declined?
Declined is the gateway saying no, the customer’s card was rejected for insufficient funds, fraud rules, expired card, etc. The decision is structural; retry alone won’t fix it. Incomplete is the gateway never returning a clear answer, the iframe timed out, the network dropped, the customer closed the tab during 3DS. The decision is transient; the customer can usually retry past it. Different problems, different fix levers, never merge them.
A customer paid me by bank transfer / cheque / on credit, why does that show as Incomplete?
BC creates Incomplete when the order skeleton is created but no payment was captured through the payment processor. Manual / offline payment workflows often leave the order in Incomplete state until you mark it Paid manually in the admin. This is a configuration question: if you handle B2B / wholesale via Net-30 invoicing, configure those orders into a different status path (Awaiting Payment, Manual Verification Required, etc.) so they don’t pollute this card.
Why does my Incomplete rate fluctuate so much between days?
Small denominator. If you do <100 orders/day, single-digit Incompletes can move the rate by 5+ points. Use the rolling 30-day window for stable numbers; that’s why this card defaults to 30D vsP and not 1D.
My BC Sales dashboard shows a lower order count than this card’s denominator, why?
The BC Sales dashboard excludes Incomplete by default, so its denominator is “successful orders only”. This card’s denominator is all orders including Incomplete. They serve different purposes: the BC dashboard answers “how much did we sell”; this card answers “what fraction of attempted purchases never paid”.
Should I set my own threshold lower than 15%?
For most BC merchants, 15% is the right alert level, it’s the upper edge of “normal” and below the level where real money is being left on the table. Set lower (10%) only if you have a high-margin, low-volume business where each lost order matters disproportionately. Do not set higher; rates above 15% have measurable revenue impact even if they “feel” normal.
Why does BC create an order at all if no payment was taken?
Because the customer hit Place Order, BC committed inventory, BC reserved stock, BC fired post-checkout webhooks. The order skeleton exists for those operational reasons. The post-checkout cleanup of unpaid skeletons happens via BC’s stale-order-purge process, but skeletons typically persist for the full 30-day reporting window. This is why Incomplete is analytically useful, it gives merchants visibility into a population that other platforms hide.
Multi-currency: do EU / UK customers really fail more than US?
Yes, materially. EU/UK customers face Strong Customer Authentication (SCA / PSD2) which adds a 3DS challenge step. Each step is a chance for the iframe to time out, the customer to abandon, or the bank-side challenge to fail. Healthy EU/UK Incomplete rates run 2-4 percentage points higher than US rates. Don’t compare your UK number against US benchmarks; use UK-specific 12-18% as the normal band.
Should I incentivise customers to retry after Incomplete?
The first move is to remove the friction, not bribe past it. A discount nudges past one Incomplete but doesn’t fix the underlying issue, the next customer hits the same iframe bug. Fix-then-incentivise sequence: audit the checkout, fix what’s broken, then if Incomplete recovery is still low, layer abandonment-recovery emails with optional 5-10% incentive on top of the now-clean checkout.