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.
| The formula | COUNT(orders WHERE paymentStatus = declined) ÷ COUNT(orders) × 100. |
| What “declined” means in BC | The payment processor returned an explicit failure response. Reasons range from issuer-side (do_not_honor, insufficient_funds, expired_card, pickup_card) to merchant-rule-side (Stripe Radar, BC’s own fraud filters) to network-side (3DS authentication failed). BC stores the failure but does NOT void the order; the order persists with total_inc_tax populated. |
| What’s NOT counted as declined | (a) Incomplete orders (those count separately, see BC Incomplete Rate), (b) Cancelled orders (where merchant or shopper cancelled post-success), (c) any order where the gateway never returned (those go Incomplete). |
| Denominator | All orders in the window, including successes, declines, incompletes, cancellations, and refunds. The denominator is the total order shape, not just successes. |
| Refunds | Not in scope. Refunds happen after a successful auth; declines never had an auth. |
| Currency | Rate metric, currency-neutral. |
| Channels / sources | All channel_id values are summed. Use BC Failures by Channel to slice (some channels run different fraud rules, e.g. Amazon vs Stencil). |
| Time window | T/7D vsP (default 7-day rolling vs the prior 7 days). 7-day is preferred over 30-day for this metric because rate movements need fast detection. |
| Alert trigger | > 8%, when the 7-day decline rate crosses 8% the merchant gets alerted. The threshold is set conservatively, structural issues usually start showing in the 5, 7% range. |
| Roles | owner, operations |
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.| Status | Order count | Total total_inc_tax |
|---|---|---|
Successful (Awaiting Shipment, Shipped, Completed) | 1,142 | $138,420 |
Declined | 56 | $7,840 |
Incomplete | 84 | $9,072 |
Cancelled | 11 | $1,460 |
| Total | 1,293 | $156,792 |
- 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
| Card | Why pair it with Decline Rate |
|---|---|
| BC Incomplete Rate | The other failure type. Always watched together, the dynamics are different. |
| BC Failed Orders Value | Dollar value of declines + incompletes combined. |
| BC Failed Orders Count | Order-count companion. |
| BC Decline by Payment Method | The first card to open when this rate spikes. Tells you where to look. |
| BC Repeat Failure Customers | Customers who failed multiple times, highest priority for recovery action. |
| BC Unrecovered Value (Size of the Prize) | The dollars left on the table when declined customers don’t come back. |
| BC Organic Recovery Rate | The natural recovery rate. Decline rate × (1 − organic recovery) = addressable opportunity. |
| Stripe Decline Rate | The Stripe-side companion when Stripe is the BC processor. Should track this card closely; divergences flag config issues. |
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:
| Reason | Direction |
|---|---|
| Time-zone. BC Control Panel runs on store timezone; Vortex IQ runs on UTC by default. Boundary-day effects on counts. | Marginal |
| Index lag. If the BC API throttled during the most recent indexer run, the latest orders may be a few minutes stale. | Self-resolves |
Status mapping. BC has both paymentStatus and status fields; some merchants override the mapping. We use paymentStatus = declined as the canonical signal. | None for default-config stores |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_decline_rate | BC decline rate ≈ Stripe decline rate (when Stripe is the only BC processor) | One BC order can have multiple Stripe charge attempts (3DS retry, partial). Stripe rate may be slightly higher because BC counts only the final order outcome. |
paypal.pp_decline_rate | BC decline rate (PayPal subset) ≈ PayPal decline rate | Same shape. Filter by BC Decline by Payment Method to isolate the PayPal subset. |
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.