Live decline-driven revenue loss while the spike is active.
At a glance
A live, real-time projection of how much revenue is currently leaking through the checkout because Stripe declines are above their normal baseline. The merchant’s live “this incident is costing me 0 when nothing is wrong, climbs as soon as a decline-rate spike begins.
| What it counts | (current_decline_rate − 30D_baseline_decline_rate) × commerce_sibling.checkout_attempts_per_min × commerce_sibling.avg_order_value × elapsed_minutes_in_spike. Pure projection, not a sum of actual lost charges. |
| API resource & fields | GET /v1/charges for live decline rate; commerce sibling (Shopify / BigCommerce / Adobe) for checkout_attempts_per_min and aov. Cross-channel derivation: this card cannot work without a commerce connector also being live. |
| Currency | The commerce sibling’s primary store currency (the one aov is reported in). Stripe declines themselves are multi-currency; the projection collapses to a single currency for the merchant’s read. |
| Fees / processing cost | n/a. This is “lost top-line revenue”, not net. Real recovered revenue would be net of fees, but you cannot pay fees on a charge that didn’t happen. |
| Refunds | NOT a factor. The card measures revenue that should have happened; refunds are something else. |
| Disputes / chargebacks | NOT a factor. Same reason. |
| Failed / declined payments | This is the metric source. Specifically, the excess failures above a 30-day rolling baseline. Normal-rate failures don’t contribute. |
| Spike detection | A spike is “decline rate ≥ baseline + 1.5σ for ≥ 5 consecutive minutes”. The card resets to $0 when the rate falls back to baseline. |
| Page cap relevance | Live mode polls the most recent ~200 charges per minute, well under the 1,000-page cap. Daily-mode versions of this card would hit the cap on high-volume merchants. |
| Time window | RT (real-time, recomputed every sync) |
| Alert trigger | > $0, the moment the projection ticks above zero a Slack / email goes out. There is no “how much” threshold; any spike triggers. |
| Roles | owner, finance |
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 US DTC apparel store on Shopify + Stripe. On 12 Apr 26 at 14:00 ET a Radar rule rolled out by a Stripe model update started flagging legitimate AmEx charges ashighest_risk_level. Decline rate climbed from a steady 5.2% baseline to 11.8% over the next 18 minutes.
| Input (live snapshot at 14:18 ET) | Value | Source |
|---|---|---|
| Current 5-min decline rate | 11.8% | stripe.charges last 5 min |
| 30D baseline decline rate | 5.2% | rolling, computed nightly |
| Excess decline rate | 6.6 pp | derived |
| Commerce sibling: checkout attempts / min | 18 | shopify.checkout_attempts_per_min |
| Commerce sibling: AOV | $94.50 | shopify.aov (30D) |
| Elapsed minutes in spike | 18 | counted from spike start |
- The number is a projection, not a sum. No 94.50`. The card multiplies the excess decline rate by the commerce sibling’s typical traffic and ticket size to estimate the lost revenue. Treat it as a live indicator of severity, not as a precise dollar figure to put in a P&L.
- The card needs the commerce sibling to be live. If Shopify / BigCommerce / Adobe isn’t connected for this organisation, the card cannot estimate
checkout_attempts_per_minoraovand shows 0”, check the commerce-connector status first. - The card freezes when the spike clears. The 0 on the next baseline-holding minute. That’s why the card is paired with Recoverable Revenue, which captures the rolling 30-day version of the same loss.
Sibling cards merchants should reference together
| Card | Why merchants reach for it next to Revenue at Risk |
|---|---|
| Decline Rate | The numerator. When this card fires, open Decline Rate first to see the size of the spike. |
| Decline Reasons | The decomposition of why the spike is happening. highest_risk_level (Radar), do_not_honor (issuer), authentication_required (3DS) each call for a different fix. |
| Decline vs Funnel | The companion cross-channel view. Confirms the spike is also showing up in the commerce sibling’s checkout completion rate, separating “real lost revenue” from “buyer remorse”. |
| Recoverable Revenue (decline-driven) | The 30-day version of this card. Where this card is “live, frozen at spike end”, that card is “rolling 30-day total”. |
| Decline Rate Spike Alert | The alert version. Fires when this card’s projection ticks above $0. |
| Top Declining Issuers | If a single issuer is driving the spike (often the case during a Visa / Mastercard rule update), this card identifies it. |
| Auth Rate | The mirror image for context. Auth-rate drop should match decline-rate spike for the card to fire. |
| Shopify / BC / Adobe Checkout Completion | The commerce sibling input. Without it, this card cannot compute. |
Reconciling against the vendor’s own dashboard
Where to look in Stripe Dashboard: Stripe Dashboard does not have a direct counterpart for this card. Stripe doesn’t model “lost revenue from a decline-rate spike” because Stripe doesn’t have visibility into the merchant’s commerce-side AOV or checkout-attempts-per-minute. This card is a Vortex IQ synthesis combining Stripe and the commerce sibling. The closest Stripe-native screens for cross-checking the inputs:- Payments → Realtime for the live decline rate.
- Reports → Decline analysis report for the historical baseline.
- Disputes is not related; disputes happen weeks after auth, not during a live spike.
- Stripe Sigma “live” queries. Custom SQL on Sigma can produce a live decline-rate number but cannot multiply by commerce-sibling AOV; the projection requires the cross-channel data.
- Radar → Insights. Stripe-side fraud-rate movement, not lost revenue.
- Slack #incident-payments channels run by RevOps teams. Those typically display total declined volume, not the excess over baseline.
| Reason | Direction | Why |
|---|---|---|
| Baseline window | Ours uses a 30-day rolling baseline | A merchant whose decline rate has been climbing slowly for weeks will see a smaller projection than expected because the baseline has crept up with the rate. |
| Commerce-sibling sync lag | Projection lower than reality | If the commerce sibling’s checkout_attempts_per_min is stale by 5, 10 min, the multiplier is too low. The card warns when the commerce sibling is more than 15 min behind real-time. |
| AOV movement during the spike | Variable | The card uses 30-day AOV, not the spike-window AOV. If a flash sale temporarily lowers AOV, the projection is too high; if a premium-tier launch raises it, too low. |
| Spike detection threshold (≥ 1.5σ) | Slow declines invisible | A merchant whose decline rate creeps up by 0.3 pp / day for two weeks will see no $0 → spike transition; the baseline absorbs the drift. Watch Decline Rate directly for that case. |
| Refresh lag | Ours 5, 60 sec behind real-time | Live mode polls every minute; the latest minute is always slightly stale. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
stripe_revenue_at_risk_live ↔ shopify.checkout_completion_rate | Both move together during a real incident. Decline spike + completion drop = real lost revenue. Decline spike alone = customers retried with a different card or processor. | If completion holds steady while declines spike, the projection is overstated; the merchant is recovering through retries. |
stripe_revenue_at_risk_live ↔ paypal.pp_decline_rate | If PayPal decline rate also spikes, the cause is upstream (traffic source, fraud wave); if only Stripe spikes, the cause is Stripe-specific (Radar, gateway config). | A Stripe-only spike with PayPal holding suggests Radar or 3DS misconfiguration; investigate Stripe-side first. |
Known limitations / merchant FAQs
Reconciliation questions are answered in the Reconciling against the vendor’s own dashboard section above.**“Why is the card always at 0. Connect Shopify / BigCommerce / Adobe and the card becomes meaningful. The second most common cause is “everything is healthy”, which is the intended behaviour. “My decline rate is high but the card still says $0, why?” Because the rate is steady high, not spiking high. The card watches for movement above the 30-day baseline. A merchant running consistently at 11% decline rate has a baseline of 11%; no excess means no projection. Use Decline Rate to see the absolute level; this card only fires on movement. “Why does the dollar figure feel too high / too low?” Three calibration points:
- The card uses 30-day commerce AOV, not the AOV inside the spike. Flash sales inflate the projection (lower-AOV traffic, higher-AOV multiplier); premium launches deflate it.
- The projection assumes every excess decline is one lost customer. In reality some customers retry with a different card or switch to PayPal; those recover. The companion Recoverable Revenue card models the recovery share.
- Commerce checkout-attempts-per-min can spike on its own (a celebrity tweet, an email send, a paid-traffic burst). If the spike happens to overlap with a normal decline-rate band, the card can briefly read non-zero. The detector requires ≥5 consecutive minutes of excess to fire and reduce these false positives.
status = failed (not requires_action). So 3DS abandons don’t push the live projection. If 3DS is the cause of a spike, 3DS Friction Loss is the right card; that one does count abandons.
“Multi-currency, what currency is the projection in?”
The commerce sibling’s primary store currency. A merchant on a GBP Shopify store with GBP + EUR + USD checkouts sees the projection in GBP. The decline-rate input is currency-neutral; only the AOV multiplier carries currency, and Shopify reports AOV in the store’s primary currency.
“Why does the card freeze at the spike-end value instead of resetting?”
So the merchant has a record of how much the incident cost during a post-incident review. The card resets to $0 on the next baseline-holding minute, typically a few minutes after the spike clears. If you missed the value, Recoverable Revenue accumulates spike-end values across the rolling 30 days.
“Can I change the spike threshold (1.5σ for 5 minutes)?”
Not yet. The detector lives in the manifest and is tuned to balance false-positive rate (cards firing when nothing is wrong) against detection speed. If you’d like a custom threshold, raise a request, the threshold is a per-merchant override away.
“What happens during planned campaigns (Black Friday, flash sales)?”
Decline rate naturally spikes during high-traffic events because new-customer mix is higher. The 30-day rolling baseline catches up over a few days, but during the first 24 hours of an event the card can fire on what is essentially “normal for this campaign”. Filter mentally during the first day of any new-traffic event; by day 3 the baseline has absorbed it.