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, 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 ashighest_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 |
| 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 |
- The card filters noise. Without the funnel overlay, both incidents look identical on a Stripe-only dashboard. The cross-channel view is the only way to tell them apart.
- 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.
- 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. 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 | The Stripe-only series. When this card fires, the Stripe-side number is the first place to drill into. |
| 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) | The dollar quantification of what this card detects. When both axes confirm real loss, this card multiplies it out. |
| Recoverable Revenue (decline-driven) | The 30-day rolling version. Where this card is the live signal, that one is the historical accounting. |
| 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 / BC Conversion Rate / Adobe Conversion Rate | The commerce-side input. One of the three must be live for the card to display. |
| 3DS Friction Loss | If the funnel drop is happening but Stripe declines aren’t moving, 3DS abandons may be the cause. |
| Payment Health Score | A real cross-channel 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-channel view is invisible from either side alone. The closest Stripe-native screens for cross-checking the Stripe-side input:- Payments → Realtime for the live decline rate.
- Reports → Decline analysis report for the 24-hour baseline.
- Shopify Admin → Analytics → “Online store sessions to checkout” funnel report.
- BigCommerce Control Panel → Analytics → “Conversion summary”.
- Adobe Commerce Admin → Reports → Sales → “Abandoned carts”.
- 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.
| 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) 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. |
| 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 | 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. |
stripe_revenue_at_risk_live is the live $ projection and stripe_xc_recoverable_revenue is the rolling 30-day view.
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 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 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.
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 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), 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) is the matching card.