> ## 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. # Decline Spike vs Checkout Funnel Drop, Stripe > When Stripe declines spike, do we see Shopify/BC/Adobe checkout completion drop? If yes, declines are causing real revenue loss, not just b... How to read... **Metrics type:** [Cross-Platform Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type) > When Stripe declines spike, do we see Shopify/BC/Adobe checkout completion drop? If yes, declines are causing real revenue loss, not just buyer remorse. ## At a glance > A dual-axis chart that overlays Stripe's 15-minute decline rate against the commerce sibling's checkout-completion rate over a 24-hour window. The card answers a single question: when Stripe declines spike, does our funnel actually drop? If yes, the spike is costing real money. If no, customers are retrying with a different card or processor. | | | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | Two series side-by-side: (a) Stripe `decline_rate(15min)` from `/v1/charges`, and (b) commerce sibling `checkout_step_completion_rate` from Shopify / BigCommerce / Adobe. The card itself is the *correlation read*, not a single number. | | **API resources & fields** | Stripe `/v1/charges` (`status`, `created`); commerce sibling's checkout funnel events (`checkout_started`, `checkout_completed`). | | **Currency** | n/a. Both series are rates (percentages); no currency involved in the visualisation. | | **Fees / processing cost** | n/a (rate metric on both sides). | | **Refunds** | NOT a factor. Refunds happen post-success and don't appear in either series. | | **Disputes / chargebacks** | NOT a factor. Disputes are weeks-later events. | | **Failed / declined payments** | This **is** the metric on the Stripe side. Strict `status = failed` definition (matches [Decline Rate](/nerve-centre/kpi-cards/stripe/decline-rate), excludes 3DS abandons). | | **3DS abandons** | NOT in the Stripe-side numerator (consistent with the Decline Rate definition), but they DO appear in the commerce sibling's funnel-drop side because the customer abandoned the checkout. This asymmetry is intentional and documented in the FAQ. | | **Page cap relevance** | 24-hour window typically fits inside 1,000 charges for low/mid merchants. High-volume merchants (>1,000/day) see decline-rate computed on the most recent slice only, the lookback can miss the early hours. | | **Time window** | `24H` (rolling) | | **Alert trigger** | `decline_rate ≥ +5pp above 24h baseline` **AND** `commerce_completion ≤ -5pp below 24h baseline`. Both must fire; either alone is half a story. | | **Roles** | owner, finance, marketing | ## Calculation Calculated automatically from your Stripe 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 UK fashion DTC store on Shopify + Stripe. Two incidents over the same week show how the card reads. **Incident A: 28 Mar 26, real revenue loss** A Stripe Radar model update at 11:00 UTC began flagging a cluster of legitimate AmEx Platinum cards as `highest_risk_level`. Decline rate climbed; the customers had no fallback ready. | Time | Stripe decline rate (15min) | Shopify checkout completion (15min) | Card reads | | --------- | --------------------------------------- | ----------------------------------- | -------------------------------------------------- | | 10:30 UTC | 5.1% (baseline) | 73% (baseline) | calm | | 11:00 UTC | 8.4% | 71% | both moving, alert imminent | | 11:15 UTC | 11.2% | 68% | **alert fires** (both thresholds crossed) | | 11:30 UTC | 12.6% | 65% | confirmed real loss; 8 pp below baseline on funnel | | 12:30 UTC | 13.1% | 64% | sustained; revenue at risk climbing | | 13:00 UTC | 6.8% (Radar rule rolled back by Stripe) | 70% | recovering | | 13:30 UTC | 5.4% | 73% | back to baseline | **Reading:** declines and funnel moved together. Customers who hit the AmEx decline did not switch to a different card; they walked away. Real lost revenue. The companion [Revenue at Risk (live)](/nerve-centre/kpi-cards/stripe/revenue-at-risk) projection peaked at \$1,840. **Incident B: 30 Mar 26, decline spike with no funnel drop** A subscription dunning batch at 06:00 UTC retried 240 previously-failed cards. As expected, most failed again, briefly pushing the 15-min decline rate up. | Time | Stripe decline rate (15min) | Shopify checkout completion (15min) | Card reads | | --------- | --------------------------- | ----------------------------------- | ---------------------------------- | | 05:45 UTC | 5.3% (baseline) | 73% (baseline) | calm | | 06:00 UTC | 9.1% (dunning batch hit) | 73% | declines spiking, funnel holding | | 06:15 UTC | 11.8% | 73% | declines high but funnel UNCHANGED | | 06:30 UTC | 9.4% | 73% | dunning batch winding down | | 07:00 UTC | 5.6% | 73% | recovering | **Reading:** declines moved, funnel didn't. The card does **not** fire (the alert requires both thresholds). The dunning batch is causing decline-rate movement but not customer-side abandonment, because the affected customers aren't actively shopping (they're being retried in the background). Three things to take from the comparison: 1. **The card filters noise.** Without the funnel overlay, both incidents look identical on a Stripe-only dashboard. The cross-platform view is the only way to tell them apart. 2. **Both axes need to be live.** The card requires both a Stripe and a commerce-platform connector. If only one is connected, the card displays a "needs commerce sibling" state. 3. **The alert deliberately under-fires.** A real Stripe-only spike (no funnel impact) does NOT trigger this card; it triggers the simpler [Decline Rate Spike Alert](/nerve-centre/kpi-cards/stripe/decline-rate-spike-alert). This card is for *revenue-loss* incidents, not all decline-rate movement. ## Sibling cards merchants should reference together | Card | Why merchants reach for it next to Decline vs Funnel | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | | [Decline Rate](/nerve-centre/kpi-cards/stripe/decline-rate) | The Stripe-only series. When this card fires, the Stripe-side number is the first place to drill into. | | [Decline Reasons](/nerve-centre/kpi-cards/stripe/top-decline-reasons) | The decomposition of *why* the spike is happening. Often the cause is visible here before the funnel impact lands. | | [Revenue at Risk (live)](/nerve-centre/kpi-cards/stripe/revenue-at-risk) | The dollar quantification of what this card detects. When both axes confirm real loss, this card multiplies it out. | | [Recoverable Revenue (decline-driven)](/nerve-centre/kpi-cards/stripe/recoverable-revenue) | The 30-day rolling version. Where this card is the live signal, that one is the historical accounting. | | [Decline Rate Spike Alert](/nerve-centre/kpi-cards/stripe/decline-rate-spike-alert) | The Stripe-only alert. Fires on decline movement alone; will be louder than this card by design. | | Shopify [Checkout Completion Rate](/nerve-centre/shopify/checkout_completion_rate) / BC [Conversion Rate](/nerve-centre/bigcommerce/conversion_rate) / Adobe [Conversion Rate](/nerve-centre/adobe_commerce/conversion_rate) | The commerce-side input. One of the three must be live for the card to display. | | [3DS Friction Loss](/nerve-centre/kpi-cards/stripe/3ds-friction-revenue-loss) | If the funnel drop is happening but Stripe declines aren't moving, 3DS abandons may be the cause. | | [Payment Health Score](/nerve-centre/kpi-cards/stripe/payment-health-score) | A real cross-platform incident drags the Health Score along with it; useful for executive comms during incidents. | ## Reconciling against the vendor's own dashboard **Where to look in Stripe Dashboard:** There is **no direct Stripe-Dashboard counterpart** for this card. Stripe doesn't model the commerce-platform funnel because Stripe doesn't have visibility into Shopify / BigCommerce / Adobe checkout events. This card exists precisely because the cross-platform view is invisible from either side alone. The closest Stripe-native screens for cross-checking the Stripe-side input: * [Payments → Realtime](https://dashboard.stripe.com/payments) for the live decline rate. * [Reports → Decline analysis report](https://dashboard.stripe.com/reports) for the 24-hour baseline. The closest commerce-side screens for cross-checking the funnel input: * Shopify Admin → Analytics → "Online store sessions to checkout" funnel report. * BigCommerce Control Panel → Analytics → "Conversion summary". * Adobe Commerce Admin → Reports → Sales → "Abandoned carts". A few views that *look* like this card but aren't: * **Stripe Sigma "decline-by-hour" reports**. Stripe-only; missing the funnel side. * **Google Analytics 4 "checkout abandonment" reports**. Funnel-only; GA4 doesn't see Stripe declines. * **Slack #payments incidents channels**. Often display either the Stripe side or the funnel side, rarely both correlated; this card is the correlation. **Why our card may legitimately differ from either dashboard:** | Reason | Direction | Why | | ----------------------------------------------- | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Stripe page cap** (1,000 charges per refresh) | Stripe-side rate sampled | High-volume merchants see the decline-rate computed on the most recent slice; the 24h lookback can miss early-window data. | | **Commerce sibling tag-fire failures** | Funnel rate **higher than reality** | Ad blockers and consent rejections drop \~10, 20% of `checkout_started` events, so the apparent completion rate runs higher than the real rate (matching denominator effect). | | **Time zone alignment** | Boundary effects | Stripe Dashboard runs on the merchant account time zone; we use UTC. The 24-hour rolling window overlaps differently for the two systems. | | **Definition of `requires_action`** | Asymmetry **by design** | We exclude `status = requires_action` from the Stripe decline numerator (matching [Decline Rate](/nerve-centre/kpi-cards/stripe/decline-rate)) but include the resulting customer abandonment in the funnel side (the customer dropped off, regardless of which Stripe state ended the charge). | | **Refresh lag** | Both sides 5, 15 min behind | The latest 15-minute bucket is always slightly stale on both axes. | **Cross-connector reconciliation:** This card *is* a cross-connector card. The reconciliation is the entire point. | Comparison | Expected pattern | What different patterns mean | | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | `stripe.decline_rate(15min)` ↔ commerce `completion_rate(15min)` | Both move together → real revenue loss; only Stripe moves → recoverable noise; only commerce moves → upstream issue (page errors, validation, shipping) | Pattern A: alert worth waking someone for. Pattern B: skip. Pattern C: not a Stripe issue, escalate to ecom team. | | `stripe_xc_decline_vs_funnel` ↔ [`paypal.pp_decline_rate`](/nerve-centre/kpi-cards/paypal/decline-failure-rate) | If both Stripe and PayPal declines spike with funnel drop, the cause is upstream (traffic source, fraud wave); if only Stripe spikes, the cause is Stripe-specific. | A simultaneous spike on multiple processors is a strong signal it's not a processor problem. | For the dollar-value quantification of any "Pattern A" incident this card surfaces, [`stripe_revenue_at_risk_live`](/nerve-centre/kpi-cards/stripe/revenue-at-risk) is the live \$ projection and [`stripe_xc_recoverable_revenue`](/nerve-centre/kpi-cards/stripe/recoverable-revenue) is the rolling 30-day view.
Documentation cross-reference (no direct counterpart on other connectors) This card is a Stripe + commerce-sibling synthesis. PayPal has the analogous [`paypal.pp_xc_decline_vs_funnel`](/nerve-centre/kpi-cards/paypal/decline-spike-vs-checkout-funnel-drop) where the same logic runs against PayPal declines. They cover different processors and don't reconcile to each other.
## Known limitations / merchant FAQs > Reconciliation questions are answered in the **Reconciling against the vendor's own dashboard** section above. **"Why do I need a commerce connector for this card?"** The whole purpose of the card is to overlay Stripe declines onto checkout-funnel completion. Without a commerce connector (Shopify, BigCommerce, or Adobe Commerce) the funnel side has no data, so the card displays a "needs commerce sibling" state and won't fire alerts. If your merchant is on a non-supported commerce platform, watch [Decline Rate](/nerve-centre/kpi-cards/stripe/decline-rate) directly until the connector lands. **"My Stripe declines spiked but the card didn't fire, why?"** The funnel side held steady. That means customers who hit a Stripe decline did *not* abandon checkout, typically because they retried with another card or switched to PayPal. The decline rate moved on paper but no real revenue was lost. The card is designed to filter out exactly these false alarms. If you want the broader "any Stripe decline movement" signal, [Decline Rate Spike Alert](/nerve-centre/kpi-cards/stripe/decline-rate-spike-alert) fires on the Stripe side alone. **"My funnel dropped but Stripe declines didn't, why?"** Something other than Stripe is breaking the funnel: page errors, form validation, shipping calculation, address verification, an outage in a third-party app. Stripe is healthy; the issue is upstream. This card won't fire (it requires both axes), but the merchant's commerce-side conversion-rate alert should. Common causes: * A theme deploy broke the cart page. * A shipping API timeout is blocking the rate-calculator step. * A new tax-calculation service is intermittently failing. * A discount-code service is rejecting valid codes. **"What about 3DS-failed charges, do they show up?"** Asymmetrically. They're excluded from the Stripe-side decline rate (`requires_action` and `canceled` aren't `failed`), but if the customer abandoned the checkout, they ARE in the commerce-sibling funnel-drop side. So a pure-3DS friction event may show up as funnel-drop-only and *not* trigger this card. Use [3DS Friction Loss](/nerve-centre/kpi-cards/stripe/3ds-friction-revenue-loss) for that case. **"How does the card handle a planned dunning batch?"** Subscription stores running scheduled retries push 100, 1,000+ failed charges through Stripe in a few minutes. Decline rate spikes; commerce funnel doesn't move (those customers aren't actively shopping). The card correctly stays silent. Confirm by checking `metadata.retry_attempt` populated on the spiked charges; that's the dunning marker. **"Can the card fire during Black Friday / a flash sale?"** Yes, and often does. High-traffic events bring in higher-risk first-time buyers, so decline rate spikes at the same time as funnel completion drops (because the conversion rate of new buyers is lower than the baseline). The card correctly identifies this as real lost revenue. The merchant typically already knows it's happening; the card surfaces the size. **"What window does the 'baseline' use for the alert thresholds?"** 24 hours. The +5pp / -5pp thresholds are measured against the rolling 24-hour means of each series. The window is short on purpose, longer baselines miss intra-day patterns and let slow drift accumulate without firing. **"Multi-currency, what does the card show?"** Both axes are rates (percentages), so multi-currency stores see a single, valid card. The dollar-value version of the same loss is on [Revenue at Risk (live)](/nerve-centre/kpi-cards/stripe/revenue-at-risk), which uses the commerce sibling's primary currency. **"Can I see the historical version of this card?"** The card itself is a 24-hour rolling view. For the rolling 30-day accumulation of "real lost revenue from past spikes", [Recoverable Revenue (decline-driven)](/nerve-centre/kpi-cards/stripe/recoverable-revenue) is the matching card. *** ### Tracked live in Vortex IQ Nerve Centre *Decline Spike vs Checkout Funnel Drop* is one of hundreds of KPI pulses Vortex IQ tracks across Stripe 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.