> ## 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. # Declined Transaction Rate, BigCommerce > Declined Transaction Rate 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:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) ## 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. | | **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. | | **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** | **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: 1. **The `paymentStatus = declined` cohort is small but meaningful, \$7,840 of attempted purchases.** Most of these will not recover (declined customers tend to leave for a competitor faster than `Incomplete` customers). 2. **The `Incomplete` cohort 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](/nerve-centre/kpi-cards/bigcommerce/bc-failed-orders-value) of \$16,912. 3. **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%. **What raises decline rate fast (in order of likelihood):** 1. **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. 2. **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. 3. **Expired-card cohort.** Common in January (annual subscriptions renewing on December-issued cards) or post-card-replacement events (post-breach mass reissuance). 4. **Fraud-rule mis-tuning.** Stripe Radar or BC's fraud filter blocking too aggressively, often after a recent rule update. 5. **3DS regression.** A theme update broke the 3DS iframe; customers can't complete authentication. **What to do at 6%:** open BC Decline by Payment Method. If one method is at 12%+ while others are at 2%, that method has the issue, fix in days. If decline rate is uniformly elevated across methods, check fraud rules or external issuer signals. ## Sibling cards merchants should reference together | Card | Why pair it with Decline Rate | | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | | [BC Failed Orders Value](/nerve-centre/kpi-cards/bigcommerce/bc-failed-orders-value) | Dollar value of declines + incompletes combined. | | [BC Failed Orders Count](/nerve-centre/kpi-cards/bigcommerce/bc-failed-orders-count) | Order-count companion. | | [Stripe Decline Rate](/nerve-centre/kpi-cards/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](https://login.bigcommerce.com/deep-links/manage/orders) and filter to status `Declined`. 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 | **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. | Card | Expected relationship | What causes legitimate divergence | | --------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`stripe.stripe_decline_rate`](/nerve-centre/kpi-cards/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. | **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](/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](/nerve-centre/stripe/str_decline_reasons) for `bank_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](/nerve-centre/kpi-cards/bigcommerce/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. *** ### Tracked live in Vortex IQ Nerve Centre *Declined Transaction Rate* 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.