At a glance
The percentage of BigCommerce orders that the payment processor declined in the period. A 2, 4% rate is healthy; > 6% is a sign something structural is wrong (issuer outage, fraud rules tuned wrong, expired cards, or 3DS friction). Decline rate is a leading indicator for Size of the Prize, declines drive most unrecovered revenue.
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. The 7-day window covers 06 Apr 26 to 12 Apr 26.
Decline rate (this card) = 56 ÷ 1,293 × 100 = 4.33%
Inside the healthy band (2, 6%). The week-prior rate was 4.1%, so up slightly but not meaningfully.
What’s interesting:
- The
paymentStatus = declinedcohort is small but meaningful, $7,840 of attempted purchases. Most of these will not recover (declined customers tend to leave for a competitor faster thanIncompletecustomers). - The
Incompletecohort is bigger than the declined cohort. 84 incompletes vs 56 declines. Incomplete is also a failure type but tracked separately, see BC Incomplete Rate. Together they contribute to BC Failed Orders Value of $16,912. - The 4.33% rate is below the 8% alert threshold. No notification, but watching for trend deterioration is still the move. If next week the rate hits 6.5% the merchant should investigate before it crosses 8%.
- Promotion brought worse customers. A heavy discount campaign or affiliate burst usually pulls in higher-risk traffic with higher decline rates. Healthy lift; expected to normalise post-promo.
- Issuer-side outage. A specific bank’s card issuance pipeline goes down for hours. Usually self-resolves; visible in BC Decline by Payment Method as a single method spiking.
- Expired-card cohort. Common in January (annual subscriptions renewing on December-issued cards) or post-card-replacement events (post-breach mass reissuance).
- Fraud-rule mis-tuning. Stripe Radar or BC’s fraud filter blocking too aggressively, often after a recent rule update.
- 3DS regression. A theme update broke the 3DS iframe; customers can’t complete authentication.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Orders and filter to statusDeclined. Count vs total orders for the same period gives you decline rate. BigCommerce does NOT surface this as a single dashboard metric, you compute it from the order list.
To verify: divide count of declined orders by count of all orders for the same date range. Should match this card to within 0.1%.
Why our number may legitimately differ from a manual BC count:
Cross-connector reconciliation (when the merchant has connected payment processors):
The decline rate on this card should track closely with the equivalent on the actual processor. Divergence is a data-quality signal.
Cross-platform same-metric: Shopify and Adobe Commerce have analogous metrics (Shopify’s
displayFinancialStatus = VOIDED plus paymentGateway error counts; Adobe’s state = canceled due to payment failure). Direct cards are on the CONNECTOR_BACKLOG. Until those ship, decline-rate on this BC card is BC-specific.
Known limitations / merchant FAQs
What’s a “good” decline rate? 2, 4% is healthy for typical DTC traffic. 0, 2% is unusually low and often means your fraud rules are too lenient (high fraud loss). 5, 8% is concerning, structural issue likely. >8% triggers an alert and demands immediate investigation. My decline rate jumped overnight, what’s the playbook? First, open BC Decline by Payment Method, if one method is much higher than others, you’ve found the issue (90% of cases). If decline is uniform across methods, check fraud rules (Stripe Radar, BC Fraud Filter), someone may have tightened them. Then check for promotional / affiliate traffic, a low-quality cohort can lift decline rate temporarily. Last, check for issuer-side outage (rare but happens), look at Stripe Decline Reasons forbank_specific codes clustering.
Is Incomplete the same as Declined?
No. Declined = the gateway returned an explicit failure response. Incomplete = the gateway never returned at all (timeout, network error, customer abandoned the iframe). They’re different problems with different fixes. The merchant should track BC Incomplete Rate alongside this card.
Why does my Stripe Dashboard say a different number?
Two reasons: (1) Stripe sees individual charge attempts (a 3DS retry is one charge attempt; the original failed attempt is another). BC sees one order per failed checkout. So Stripe’s decline count can be higher. (2) Timezone differences. (3) Stripe Dashboard may include test-mode charges if filter isn’t set; BC orders exclude test mode by default.
Can I reduce decline rate by switching processors?
Sometimes. Different processors have different default fraud-rule strictness, different decline-recovery infrastructure (Stripe’s Smart Retries, Adyen’s RevenueProtect), and different issuer-side relationships. A 1, 2 percentage point reduction is realistic by switching processors, beyond that you’re optimising the rules / 3DS configuration, not the processor itself.
Decline reasons, where can I see them?
At the order level: open the order in BC Control Panel and look at the order notes / payment notes. Aggregated: BC Decline by Payment Method shows method-level concentration. For granular decline reasons (do_not_honor, insufficient_funds, etc.), the Stripe / PayPal connector cards are more detailed than BC’s own data.
My multi-currency BC store, does decline rate work?
Yes. Rate metric, currency-neutral. Multi-currency stores get a single, valid decline rate.
Why does the rate look stable but my unrecovered value is rising?
Volume is rising. A 4% rate on 10x traffic is 4x the dollar leak. Watch this card alongside BC Failed Orders Value (volume) and BC Unrecovered Value (after recovery). Rate stability + volume growth = absolute losses growing too.
Does declined include cards rejected by my own fraud rules?
Yes, every reason that causes the processor or BC to reject the order ends up as paymentStatus = declined. We don’t separate “issuer-declined” from “merchant-declined” at the headline level, but the per-method breakdown often surfaces the distinction.