Skip to main content
Metrics type: Key Metrics • Category: Payment Gateway
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 Xrightnow"number.ReadsX right now" number. Reads 0 when nothing is wrong, climbs as soon as a decline-rate spike begins.

​
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 as highest_risk_level. Decline rate climbed from a steady 5.2% baseline to 11.8% over the next 18 minutes.
What the card displayed:
Three things to read from this:
  1. The number is a projection, not a sum. No 2,022ofchargesactuallyhad‘amount=2,022 of charges actually had `amount = 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.
  2. 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_min or aov and shows 0witha"needscommerceconnector"badge.Thisisthesinglebiggestreasonmerchantssee"always0 with a "needs commerce connector" badge. This is the single biggest reason merchants see "always 0”, check the commerce-connector status first.
  3. The card freezes when the spike clears. The 2,022figurestaysvisibleforthemerchant′sincident−reviewsession,thenresetsto2,022 figure stays visible for the merchant's incident-review session, then resets to 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

​
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: A few other views can look like this card but aren’t:
  • 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-platform 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.
Why our number may legitimately differ from the inputs: Cross-connector reconciliation: This card is a cross-connector card by construction. The commerce-sibling reconciliation is built in: The card’s whole reason to exist is the cross-platform view. If you only ever look at Stripe-only metrics, you cannot distinguish “$2k of revenue is leaking right now” from “decline rate moved a bit but customers retried fine”.

​
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?"∗∗Themostcommoncauseisnocommercesiblingconnected.Theprojectionis‘excessdeclinerate×commerceattemptspermin×commerceaov×elapsedmin‘,andwithoutacommerceconnectorthemultiplierisunknownsothecarddefaultsto0?"** The most common cause is no commerce sibling connected. The projection is `excess_decline_rate × commerce_attempts_per_min × commerce_aov × elapsed_min`, and without a commerce connector the multiplier is unknown so the card defaults to 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:
  1. 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.
  2. 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.
  3. 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.
“Are 3DS-failed charges in the projection?” Indirectly. The card uses Stripe’s decline rate, which by our definition only counts 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.

​
Tracked live in Vortex IQ Nerve Centre

Revenue at Risk (live) 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 or book a demo to see this metric running on your own data.