Per-channel COUNT(paymentStatus=declined OR status=Incomplete). Pinpoints which storefront has the worst checkout, typically a POS-vs-online divergence after a checkout deploy.
At a glance
Failed-order count per BigCommerce channel_id, with the failure rate (failures ÷ total orders for that channel) shown alongside. Pinpoints which storefront has the worst checkout, typically a POS-vs-online divergence after a checkout deploy or a marketplace integration that’s silently mis-configured.
| What it counts | GROUP BY channel_id of COUNT(paymentStatus = 'declined') + COUNT(status = 'Incomplete'), plus the per-channel rate computed against per-channel total orders. Methodology mirrors BC Failed Orders Count, partitioned by channel. |
| VAT / tax treatment | n/a, count metric. |
| Shipping | n/a, count metric. |
| Discounts | n/a, count metric. |
| Refunds | Excluded. paymentStatus = refunded succeeded first. |
| Cancelled / voided orders | Excluded. Cancelled is a merchant void on a previously-captured order. |
Incomplete quirk | Incomplete orders count toward the failure side, but a quirk worth knowing: marketplace channels (Amazon, eBay, Facebook via Channel Manager) almost never produce Incomplete orders because the marketplace pre-authorises payment before BC sees the order. So Incomplete is structurally a Stencil-web / POS problem; it does not even occur on Channel Manager. |
| Currency | Currency-agnostic in the count, but channel_id and currency often correlate (an Amazon UK channel transacts in GBP, an Amazon US channel in USD), so per-channel views indirectly approximate per-currency views for marketplace stores. |
| Channel ID conventions | 1 is the Stencil web storefront for every BC store. Channel Manager assigns integer IDs per integration: Amazon, eBay, Facebook, Walmart, custom B2B portals, POS terminals all get distinct IDs. Use BC Orders by Channel ID to map IDs to human names. |
| Time window | 30D vsP (default 30D vs the prior 30D) |
| Alert trigger | any channel failure-rate >2× store average, fires when one channel is failing at twice the store-wide rate. Surfaces structurally broken channels. |
| Roles | owner, operations, 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 with three live channels: Stencil web, Amazon (Channel Manager), Facebook Shop. The 30-day window covers 14 Mar 26 to 12 Apr 26. Store-wide failure rate is 12.0%.channel_id | Channel name | Total orders | Declined | Incomplete | Failures | Failure rate | Ratio vs store avg | Verdict |
|---|---|---|---|---|---|---|---|---|
1 | Stencil web storefront | 3,232 | 56 | 392 | 448 | 13.9% | 1.16x | Slightly elevated |
1019847 | Amazon Channel Manager | 624 | 12 | 0 | 12 | 1.9% | 0.16x | Healthy |
1019850 | Facebook Shop | 95 | 3 | 0 | 3 | 3.2% | 0.27x | Healthy |
1020114 | POS Terminal A (NYC) | 74 | 0 | 22 | 22 | 29.7% | 2.48x | Broken |
| Store total | 4,025 | 71 | 414 | 485 | 12.0% |
- POS Terminal A is failing at 2.48x the store average. Almost all of these are
Incomplete(22 of 22Incomplete, 0 declined). On a POS device,Incompletetypically means the customer-side flow stalled, the chip-and-PIN reader timed out, the receipt printer failed, or the cashier abandoned mid-transaction. Walk this terminal physically before assuming a software issue. - Amazon and Facebook are running cleanly. Both marketplace channels show low failure rates (1.9% and 3.2%) with zero
Incompleteorders, which is structurally expected. If either started showingIncomplete > 0, that would indicate the Channel Manager sync was importing partial-state orders, a critical integration bug. - Stencil web is slightly elevated at 1.16x. Not alarming on its own, but it carries 92% of the store’s total failures by absolute count. Worth running BC Decline by Payment Method filtered to web to see if one method is dragging the average up.
- POS-vs-online failure rates can flip overnight. The most common cause of a sudden spike in this card is a checkout-page deploy on the web channel that breaks one device class (Safari iOS, Chrome on Android 12, etc). The second most common is a payment-terminal firmware update on POS. Always check this card after any checkout-related change.
- Physically walk POS Terminal A. Test a card payment, watch for chip-reader timeout, confirm the receipt printer is online. Hardware issues account for most POS
Incompletespikes. - Open the Stencil web checkout in a real browser and step through with a known-good card. If the checkout completes cleanly, the issue is concentrated in a device / browser segment, audit with FullStory or similar.
- Compare to the prior 30D window. If the pattern is stable (POS Terminal A was 28% last month too), it’s a chronic hardware issue worth replacing the device. If it spiked this period, something changed.
- Pair with BC Decline by Payment Method per channel. The intersection (e.g. “PayPal on Stencil web”) often reveals the broken surface.
Sibling cards merchants should reference together
| Card | Why pair it with Failures by Channel |
|---|---|
| BC Failed Orders Count | The store-wide headline. This card is the channel breakdown of that headline. |
| BC Orders by Channel ID | The volume-share denominator. Lets you compute failure rate per channel correctly. |
| BC Revenue by Channel | The dollar context. A 30% failure rate on a tiny POS terminal is annoying; a 5% spike on a $2M/month web checkout is an emergency. |
| BC Decline by Payment Method | The other dimension of the failure cube. Channel + Method intersection often surfaces the exact broken surface. |
| BC Decline Rate | The store-wide trend. If this spikes, this card tells you which channel caused it. |
| BC Incomplete Rate | The UX-side store-wide trend. Same drill-down logic. |
| BC Channel Revenue Mix | The healthy view of the same channel breakdown. Compare side-by-side: a channel can be carrying meaningful revenue while also being structurally broken. |
| BC Size of the Prize | Recovery view, fixing one broken channel can shift the prize materially. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Channel Manager shows the list of integrated channels and their IDs, then Orders → All orders with the Channel filter applied for each ID and status filterDeclined or Incomplete. BC does not natively show a chart of failures-per-channel; you have to read each filtered view manually.
Other BC Control Panel views that look like this card but aren’t:
- Analytics → Sales by channel: shows successful revenue by channel, the inverse view.
- Channel Manager → Health indicators: shows whether a channel integration is connected and recent sync status. Doesn’t surface checkout failure rates.
- POS Settings → Devices: lists POS terminals; doesn’t surface failure counts per device.
- Storefront → Performance: a pre-Channel-Manager legacy view, not reliable on modern Enterprise stores.
| Reason | Direction |
|---|---|
| Channel Manager backfill timing. New channels added mid-period start indexing only from the day they were connected. Failure counts on day 1-2 of a new channel are artificially low. | Vortex IQ LOWER for new channels |
POS offline-mode orders. POS devices in offline mode buffer orders locally and sync when reconnected. The dateCreated is the buffer time, not the original swipe time, so boundary-day failures can shift. | ±1 day at boundary |
| Channel ID renaming. BC allows renaming a channel’s display name without changing its ID. The card buckets by ID; if you renamed mid-period the table shows the current name but historical orders. | Cosmetic only |
| Time zone. UTC vs store timezone. | ±1 day boundary |
Test orders. POS-test mode orders sometimes carry channel_id of a real terminal. Not currently filtered. | Marginal |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
amazon_sp.amazon_failed_orders | Amazon’s Seller Partner API exposes order-status events including Cancelled and Unshipped flows. Should correlate with BC channel_id = <Amazon> failure counts. | Amazon and BC’s failure semantics differ; Amazon counts buyer-cancelled orders separately, BC counts them as Cancelled not Declined. |
stripe.stripe_decline_rate | Stripe processes Stencil web (channel_id = 1) failures only, not marketplace channels (those run through Amazon Pay / Facebook Pay / etc.). | Stripe ≈ this card filtered to channel_id = 1. |
channel_id field is unique to BC’s data model. Shopify uses sourceName (a string) and Adobe Commerce uses store_id plus a separate channel taxonomy, neither of which maps cleanly to BC’s integer IDs. Channel-level failure analytics on Shopify and Adobe Commerce live on the CONNECTOR_BACKLOG.
Known limitations / merchant FAQs
Why is my Stencil web channel always the worst? Volume bias plus structural reasons. Web carries the highest order volume so it carries the most absolute failures. It also sees the most diverse customer base (every device, browser, geography), so it surfaces every checkout edge case. Marketplaces (Amazon, eBay, Facebook) pre-authorise payment before BC sees the order, so their failure rate is structurally near-zero. POS sees only successful in-store payments most of the time. Web being highest is normal; web being above 1.5x the store average is the alert threshold. A POS terminal shows 30% Incomplete, what’s happening? Almost always a hardware issue. Common causes: (1) chip-and-PIN reader timing out (firmware update needed), (2) receipt printer offline (BC POS treats this as an Incomplete state), (3) the cashier’s tablet/iPad has lost network mid-transaction, (4) a specific peripheral driver (cash drawer, barcode scanner) is failing. Walk the device physically before assuming a software problem. Most POS Incomplete spikes resolve with a device reboot or peripheral reseat. A new Channel Manager integration shows zero failures, is that real? Probably yes, for the first 30-60 days. Channel Manager integrations only flow orders that the marketplace has already authorised payment for; failures only surface for non-payment reasons (inventory mismatch, address validation, listing-state drift). Healthy marketplace channels run 0.5-3% failure rates indefinitely. If you’re seeing exactly zero on a channel that’s been live more than 60 days and processing meaningful volume, double-check the Channel Manager sync isn’t filtering out failed orders before they hit BC. Why does the same physical terminal show up under multiple channel_ids over time? BC POS reassignschannel_id when a terminal is re-paired with a different store location, when the BC POS app is reinstalled, or after some firmware upgrades. The card doesn’t merge IDs across these events; if you see “POS Terminal A” appear and disappear in the bar chart, that’s the cause. Cross-reference the BC Settings → POS → Devices admin to map IDs back to physical hardware.
Can I drill into one channel’s failures by date?
Yes, click into the channel from this card and Vortex Mind opens a per-channel daily timeseries (see the daily-revenue-leakage report). The day-level pattern often reveals the deploy or config change that broke the channel: if failures cluster on a single day and stay elevated, that day is when something changed.
My B2B portal channel shows high failures, is it broken?
B2B portals on BC commonly use Net-30 / Net-60 invoice payment, which BC may flag as paymentStatus = pending or Manual, not paymentStatus = captured. Some B2B integrations write Incomplete for these orders even though they’re not really failures, the merchant intends to capture payment offline. Check the B2B portal’s documentation before treating these as recoverable failures; the order may already be paid through a different settlement path.
My Facebook Shop channel suddenly shows declines, what changed?
Facebook / Meta tightened payment rules in late 2025; certain product categories (supplements, alternative-health, regulated goods) are now blocked at the Facebook Pay layer. If your Facebook Shop revenue dropped and this card shows new Facebook declines, the most likely cause is a category-level Meta policy change. Check Meta Business Help Centre for current restrictions in your category.
Should I set the alert threshold lower than 2x?
Probably not, unless you’re a pure-DTC store with one high-volume channel. The 2x threshold cuts through noise on small channels (where small absolute counts produce volatile rates) and only fires when one channel has structurally diverged from the rest. If you have a five-figure channel that you want tighter alerting on, configure a per-channel custom alert in the Vortex IQ Nerve Centre rather than lowering the global threshold.
Multi-currency stores: does this card split by currency too?
No, only by channel_id. But because Channel Manager integrations are usually currency-locked (Amazon UK = GBP, Amazon US = USD), the per-channel view often gives you the per-currency view for free. For Stencil web stores transacting multiple currencies on a single channel_id = 1, use BC Revenue by Currency for the volume side and the OpenSearch direct view for currency-aware failure analytics.