> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Financial Status Breakdown, BigCommerce

> Financial Status Breakdown for BigCommerce stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it.

**Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained)  •  **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type)

## At a glance

> Order count grouped by `paymentStatus` (authorized, captured, declined, refunded, partially\_refunded, held\_for\_review). The financial-side complement to the order-fulfilment status breakdown, this card answers "where is the money in our orders, by state".

|                                        |                                                                                                                                                                                                                                                                                                                                                                                                  |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **What it counts**                     | `GROUP BY paymentStatus` over orders in the last 30 days. Each order falls into exactly one paymentStatus bucket.                                                                                                                                                                                                                                                                                |
| **VAT / tax treatment**                | n/a, this is a count-of-orders metric, not a money metric. To see revenue by paymentStatus, multiply by AOV per bucket.                                                                                                                                                                                                                                                                          |
| **Shipping**                           | n/a.                                                                                                                                                                                                                                                                                                                                                                                             |
| **Discounts**                          | n/a.                                                                                                                                                                                                                                                                                                                                                                                             |
| **Refunds**                            | Refunded orders show in the `refunded` and `partially_refunded` buckets explicitly; that is the entire purpose of this card.                                                                                                                                                                                                                                                                     |
| **Cancelled / voided orders**          | Cancelled orders may have any paymentStatus depending on whether payment was captured before cancellation. Most cancelled-pre-capture orders show as `authorized`; cancelled-post-capture show as `refunded`.                                                                                                                                                                                    |
| **Currency**                           | n/a, count metric.                                                                                                                                                                                                                                                                                                                                                                               |
| **Channels / sources**                 | All BC channels contribute. Different channels have characteristic distributions: web orders are typically 95%+ `captured`; POS is 99%+ `captured` (cash and card both finalise at the till); marketplace orders may be 85% `captured` + 10% `pending` waiting for marketplace settlement.                                                                                                       |
| **BC-specific paymentStatus values**   | BC distinguishes more states than Shopify or Adobe. Notable: `held_for_review` (fraud-rule flag), `authorized` (auth captured but not settled), `captured` (settled), `declined` (gateway said no), `refunded` (full refund), `partially_refunded` (partial refund), `disputed` (chargeback initiated). The richer state model means BC merchants get earlier signals for payment-flow problems. |
| **Why this differs from order status** | BC overloads `status` to mean *fulfilment* state (Shipped, Awaiting Fulfilment, Cancelled). `paymentStatus` is the *money* state. An order can be `Shipped` (fulfilment) but `partially_refunded` (payment); it can be `Awaiting Fulfilment` (fulfilment) but `captured` (payment). Use [Fulfillment Status](/nerve-centre/kpi-cards/bigcommerce/fulfillment-status) for the fulfilment view.    |
| **Held-for-review handling**           | The `held_for_review` bucket is BC's fraud-rules pause state. A growing share here usually means recent fraud-rule tightening; pair with [BC Decline Rate](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-rate) and BC Settings → Order Fraud to investigate.                                                                                                                          |
| **Time window**                        | `30D` (rolling 30 days)                                                                                                                                                                                                                                                                                                                                                                          |
| **Alert trigger**                      | None at this card; alerts live on the per-state cards (Refund Rate, Decline Rate).                                                                                                                                                                                                                                                                                                               |
| **Roles**                              | owner, operations                                                                                                                                                                                                                                                                                                                                                                                |

## Calculation

```
GROUP BY paymentStatus
  WHERE date BETWEEN [period_start, period_end]
```

## Worked example

A US homewares brand on BigCommerce Pro, last 30 days from 14 Mar 26 to 12 Apr 26.

| paymentStatus        | Order count | Share    | Notes                                   |
| -------------------- | ----------- | -------- | --------------------------------------- |
| `captured`           | 5,840       | 89.4%    | Successful, money settled               |
| `authorized`         | 110         | 1.7%     | Payment authed but not yet captured     |
| `refunded`           | 280         | 4.3%     | Full refund processed                   |
| `partially_refunded` | 145         | 2.2%     | One line item refunded                  |
| `declined`           | 95          | 1.5%     | Gateway-rejected; customer didn't retry |
| `held_for_review`    | 38          | 0.6%     | Fraud-rules pause                       |
| `disputed`           | 22          | 0.3%     | Chargeback opened                       |
| **Total**            | **6,530**   | **100%** |                                         |

What's interesting:

1. **89.4% captured is healthy.** US D2C peers run 88-94% captured share; UK D2C peers (with stricter SCA / 3DS rules) typically run 84-91%. Multi-channel BC stores tend to be 1-3pp lower than single-channel because marketplace orders settle slowly.
2. **The 1.7% authorized share is the watch-out bucket.** These are orders where the payment got authorisation but the merchant hasn't captured (manual capture mode, or capture-on-fulfilment configuration). Authorisations expire after 5-7 days depending on issuer, an order stuck in `authorized` past day 5 means revenue at risk. Pair with BC's auth-expiry settings under [Settings → Payments](https://login.bigcommerce.com/deep-links/manage/payments).
3. **6.5% combined refunded share** is concerning if not normal for the category. Homewares typically runs 4-7% refund rate; fashion 12-25%. If this number is climbing month-over-month, pair with [BC Refunded Products](/nerve-centre/kpi-cards/bigcommerce/most-refunded-products) to identify the SKUs driving it.
4. **0.6% held\_for\_review** is a small but informative bucket. Each held order is a real customer waiting for a manual fraud review; review queue length is a service-level signal. If the team can't clear them in 4 hours, customers walk away (the order is still in BC but the customer has stopped checking back). Pair with operational SLA on the fraud team.
5. **0.3% disputed (22 chargebacks in 30 days)** is significant. Each chargeback costs \$15-50 in fees plus the disputed amount, plus risk-score points with the gateway. A 0.3-0.5% dispute rate is borderline acceptable; over 0.6% triggers gateway warning programs (Visa Risk Program, Mastercard Excessive Chargeback Program) which raise processing fees.

The diagnostic playbook by bucket:

1. **For `authorized` over 1%**: investigate manual-capture configuration. Capture-on-fulfilment is the safer pattern for high-value goods; capture-immediately is healthier for digital / low-value goods.
2. **For rising `refunded`**: drill via [Refund Rate](/nerve-centre/kpi-cards/bigcommerce/refund-rate) and [BC Refunded Products](/nerve-centre/kpi-cards/bigcommerce/most-refunded-products). Most refund spikes trace to one SKU or one campaign cohort.
3. **For rising `declined`**: check [BC Decline Rate](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-rate) and Settings → Payments → Fraud Tools. Recent fraud-rule tightening is the most common cause.
4. **For rising `held_for_review`**: same fraud-rule audit, plus check whether your fraud team is staffed to clear the queue.
5. **For rising `disputed`**: gateway dashboard (Stripe / Cybersource / PayPal) for the chargeback reason codes. "Product not received" usually means a fulfilment problem (pair with [BC Alert Fulfilment Delay](/nerve-centre/kpi-cards/bigcommerce/fulfilment-delay-alert)); "Fraudulent transaction" usually means a fraud-tool gap.

## Sibling cards merchants should reference together

| Card                                                                             | Why pair it with Financial Status Breakdown                                                                              |
| -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| [Fulfillment Status](/nerve-centre/kpi-cards/bigcommerce/fulfillment-status)     | The fulfilment-side complement. An order's two states (payment + fulfilment) tell you where in the chain a problem sits. |
| [Refund Rate](/nerve-centre/kpi-cards/bigcommerce/refund-rate)                   | The threshold version of the refunded buckets.                                                                           |
| [BC Decline Rate](/nerve-centre/kpi-cards/bigcommerce/declined-transaction-rate) | The declined bucket as a rate metric. Rising decline % maps to declining `captured` share here.                          |
| [Total Revenue](/nerve-centre/kpi-cards/bigcommerce/total-revenue)               | The revenue-side correlation. Rising `held_for_review` and `declined` map to lost revenue.                               |
| [Order Count](/nerve-centre/kpi-cards/bigcommerce/total-orders)                  | The denominator for any rate-style cut of this distribution.                                                             |
| [Payment Methods](/nerve-centre/kpi-cards/bigcommerce/payment-methods)           | The "by gateway" view. Different gateways have characteristic decline / hold patterns.                                   |
| [`stripe.stripe_dispute_count`](/nerve-centre/stripe/stripe_dispute_count)       | The disputed bucket as seen on the gateway side; should reconcile within 1-2 disputes.                                   |

## Reconciling against the vendor's own dashboard

**Where to look in BigCommerce Control Panel:**

[Orders → All orders](https://login.bigcommerce.com/deep-links/manage/orders) supports a "Payment status" filter that shows orders by paymentStatus. Filter to last 30 days and group by status to get the same distribution. [Analytics → Sales](https://login.bigcommerce.com/deep-links/manage/analytics/in-store-conversion) on Plus / Pro shows a "Payment status mix" tile.

For payment-side reconciliation, [Settings → Payments](https://login.bigcommerce.com/deep-links/manage/payments) shows the active gateways; the gateway-side dashboard (Stripe, Cybersource, PayPal) shows captured / declined / disputed at the processor level.

**Why our number may legitimately differ from BC Orders view:**

| Reason                                                                                                                                                                                                                                            | Direction               |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------- |
| **State transitions during the window.** An order that started `held_for_review` and ended `captured` shows in BC Orders as the latest state; we assign the latest state too, but a sync-time discrepancy can make the totals differ by 0.1-0.5%. | Boundary effects        |
| **Time zone.** UTC vs store time zone.                                                                                                                                                                                                            | Boundary effects        |
| **Cancelled orders.** BC Orders may filter cancelled orders out of the financial-status view by default; we include them.                                                                                                                         | Vortex IQ HIGHER total  |
| **Sync lag.** Recent state transitions (last 5-15 minutes) may not be reflected.                                                                                                                                                                  | Vortex IQ slightly LAGS |
| **Custom paymentStatus values.** Some BC stores have custom states via apps; we count them under "other".                                                                                                                                         | Mixed                   |

**Cross-connector reconciliation:**

| Card                                                                         | Expected relationship                                     | What causes legitimate divergence                                                                                 |
| ---------------------------------------------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| [`stripe.stripe_charge_status`](/nerve-centre/stripe/stripe_charge_status)   | Stripe's charge status should align with BC paymentStatus | Stripe-side has more granular states (`succeeded`, `pending`, `failed`); BC collapses to `captured` / `declined`. |
| [`paypal.pp_transaction_status`](/nerve-centre/paypal/pp_transaction_status) | PayPal status mirror                                      | PayPal-side shows e-check holds and currency conversion holds that BC may collapse to `captured`.                 |

**Same-metric documentation cross-reference:**

* [`shopify.financial_status`](/nerve-centre/kpi-cards/shopify/financial-status-breakdown) (planned)
* [`adobe_commerce.financial_status`](/nerve-centre/kpi-cards/adobe-commerce/financial-status-breakdown) (planned)

## Known limitations / merchant FAQs

**What's a healthy `captured` share to target?**
US D2C: 88-94%. UK / EU D2C: 84-91% (3DS authentication friction). B2B: 95-99% (invoiced or pre-authorised buyers). Marketplace-heavy: 82-89% (settlement timing pulls share into transient `pending` states). Below your category benchmark by 5+ pp triggers investigation.

**Why is `authorized` so high on my store?**
Almost always a manual-capture configuration. Some merchants (especially in custom-build, B2B, and high-value categories) set BC to authorise at order time and capture only on fulfilment. That's safe but exposes you to authorisation-expiry risk (most card auths expire 5-7 days, some 30 days). If your `authorized` share is over 3% and your fulfilment SLA is over 5 days, you're losing some authorisations to expiry.

**My `held_for_review` count just spiked, what changed?**
Almost always a fraud-rule update. Check [Settings → Order Fraud](https://login.bigcommerce.com/deep-links/manage/settings/order-fraud) for recent rule changes; revert anything from the past 7 days first as a quick test. If no recent rule changes, check whether your fraud-tool vendor (Signifyd, Riskified, Kount) tightened internally without notice; their merchant dashboards show rule cadence.

**My `disputed` rate hit 0.5%, am I in trouble?**
Approaching trouble. Visa Risk Program triggers at 0.65% for the rolling 12-month dispute rate; Mastercard Excessive Chargeback Program at similar thresholds. At 0.5% you have a 6-12 month window before risk-program intake. Investigate the chargeback reason codes (your gateway dashboard) and address the most common one. "Product not received" usually means a fulfilment problem; "Fraudulent transaction" means a fraud-tool gap.

**Can a single order have multiple paymentStatus over time?**
Yes, and BC keeps only the latest. An order placed today as `authorized`, captured tomorrow as `captured`, refunded next week as `refunded` shows here as `refunded` in week 2. We follow the same pattern; the historical state transitions are not preserved in this card. For state-transition analytics, BC Webhooks → Order events are the right source.

**How does this card differ from Shopify's financial\_status?**
Shopify uses a smaller state vocabulary: `paid`, `authorized`, `partially_paid`, `partially_refunded`, `refunded`, `voided`, `pending`. BC's vocabulary is richer (adds `held_for_review`, `disputed`, `declined`). The merchant-facing implication: BC merchants get earlier, more granular signals about where money is in the funnel.

**Why is `partially_refunded` so common on multi-line orders?**
Common pattern for stores with frequent partial returns (one item out of three). The order stays `partially_refunded` permanently after the partial refund; it's a terminal state for that order. A high `partially_refunded` share usually correlates with multi-line cart structure, not with poor product quality.

**My POS terminal shows 99.5% `captured`, is that normal?**
Yes. POS payments finalise at the till, usually with no auth-then-capture delay. POS-only stores see `captured` shares of 98-99.5%. If you see meaningful `authorized` or `declined` on POS, the terminal hardware or the till's network connection is the issue.

**Should I include test orders in this view?**
No. Filter known test customer IDs upstream. Test orders typically pass through `captured` and skew the rate slightly higher than reality. Most stores with active dev work should expect 1-3 percentage points of dilution if test orders aren't excluded.

***

### Tracked live in Vortex IQ Nerve Centre

*Financial Status Breakdown* is one of hundreds of KPI pulses Vortex IQ tracks across BigCommerce and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

[Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.