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”.
Calculation
Worked example
A US homewares brand on BigCommerce Pro, last 30 days from 14 Mar 26 to 12 Apr 26.
What’s interesting:
- 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
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:
Cross-connector reconciliation:
Same-metric documentation cross-reference:
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.