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 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 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
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% |
- 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.
- 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
authorizedpast day 5 means revenue at risk. Pair with BC’s auth-expiry settings under Settings → Payments. - 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 to identify the SKUs driving it.
- 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.
- 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.
- For
authorizedover 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. - For rising
refunded: drill via Refund Rate and BC Refunded Products. Most refund spikes trace to one SKU or one campaign cohort. - For rising
declined: check BC Decline Rate and Settings → Payments → Fraud Tools. Recent fraud-rule tightening is the most common cause. - For rising
held_for_review: same fraud-rule audit, plus check whether your fraud team is staffed to clear the queue. - 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); “Fraudulent transaction” usually means a fraud-tool gap.
Sibling cards merchants should reference together
| Card | Why pair it with Financial Status Breakdown |
|---|---|
| Fulfillment Status | The fulfilment-side complement. An order’s two states (payment + fulfilment) tell you where in the chain a problem sits. |
| Refund Rate | The threshold version of the refunded buckets. |
| BC Decline Rate | The declined bucket as a rate metric. Rising decline % maps to declining captured share here. |
| BC Incomplete Rate | Pre-financial-status state. Incomplete orders never get a paymentStatus assigned. |
| Total Revenue | The revenue-side correlation. Rising held_for_review and declined map to lost revenue. |
| Order Count | The denominator for any rate-style cut of this distribution. |
| Payment Methods | The “by gateway” view. Different gateways have characteristic decline / hold patterns. |
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 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 on Plus / Pro shows a “Payment status mix” tile. For payment-side reconciliation, Settings → 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 |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
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 | PayPal status mirror | PayPal-side shows e-check holds and currency conversion holds that BC may collapse to captured. |
shopify.financial_status(planned)adobe_commerce.financial_status(planned)
Known limitations / merchant FAQs
What’s a healthycaptured 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 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.