Live decline-driven revenue loss while the spike is active.
At a glance
Live, real-time estimate of revenue being lost right now due to an in-progress decline-rate spike. Not a 30-day rear-view mirror; an active, minute-by-minute “money is leaking out the bottom of the bucket while you read this” number. Fires whenever the current decline rate exceeds the rolling 30D baseline by a threshold and the commerce platform shows checkout traffic in the same window. The single most board-pack-friendly card during a payment incident.
| The formula | (current_decline_rate − baseline_decline_rate) × commerce_sibling.checkout_attempts_per_min × avg_order_value × elapsed_minutes_since_spike_started. Cross-channel derived from CyberSource decline data joined to the connected commerce platform’s live checkout pulse. |
| Numerator components | (1) Excess decline rate, current 15-minute rolling decline rate minus 30-day baseline. (2) Live checkout attempts per minute, from the connected commerce platform’s live checkout-funnel pulse. (3) AOV, 30-day rolling average. (4) Spike duration, time since the alert fired (or since decline rate crossed the +2σ threshold). |
| What “live” means | Updates every 60 seconds. Reads /tss/v2/searches for the most recent 15 minutes and queries the commerce-platform’s live checkout-funnel KPI. Goes back to $0 when the spike resolves (decline rate returns within +1σ of baseline). |
| What it doesn’t count | Disputes, refunds, and post-incident recoverable revenue. This card is forward-looking only: “right now, while I’m watching, this amount of revenue is at risk.” For the post-incident post-mortem use Recoverable Revenue (decline-driven). |
| Required connectors | CyberSource (this connector) AND a commerce-platform connector (Shopify, BigCommerce, or Adobe Commerce). The card grays out if no commerce sibling is connected because the formula needs checkout_attempts_per_min from the storefront. |
| Currency | Single currency at sync time. For multi-currency global merchants, the engine sums per-currency at fixed FX (current period rate) for a single dashboard number, with the per-currency breakdown on hover. |
| Refunds / disputes | Excluded. This is decline-driven revenue at risk, not retroactive write-downs. |
| Failed / declined payments | Counted (these ARE the at-risk revenue). |
| Time window | RT (real-time, 60-second refresh cycle during an active spike). |
| Alert trigger | > $0. The card only shows a non-zero number while a spike is active; any non-zero value is by definition an active incident. |
| Roles | owner, finance, operations, on-call |
Calculation
Calculated automatically from your CyberSource 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 North American electronics retailer running CyberSource for ecommerce + Adobe Commerce for the storefront. On the morning of 09 Apr 26 at 09:42 UTC, Vortex IQ Nerve Centre firescs_alert_decline_spike (decline rate jumped >2σ over the 1h baseline). The on-call payments lead opens the Decline Spike vs Checkout Funnel Drop card and confirms the storefront is also showing ~6% drop in checkout completion. This card lights up.
State at 10:15 UTC (33 minutes into the spike):
| Component | Value | Source |
|---|---|---|
| Current 15-min decline rate | 11.4% | /tss/v2/searches (last 15 min) |
| 30-day baseline decline rate | 5.1% | /tss/v2/searches (rolling 30D) |
| Excess decline rate | 6.3pp | (computed) |
| Live checkout attempts / min | 84 | Adobe Commerce checkout-funnel pulse |
| 30-day avg order value | $147 | (rolling) |
| Elapsed minutes since spike start | 33 | (timer started 09:42 UTC) |
- The number grows linearly while the spike persists. Every minute adds ~X every minute” for the incident commander or CFO call.
- Checkout attempts per minute matters as much as decline rate. The same 6.3pp excess decline rate during a midnight-quiet window (10 attempts/min) is only ~778/min. The card incorporates this naturally so the dollar number always reflects the actual revenue exposure.
- The card goes back to $0 when decline rate returns to baseline. This is intentional and important: the card is forward-looking. After the spike resolves, the post-mortem uses Recoverable Revenue (decline-driven) to estimate what could be won back via dunning / retry.
- Root cause investigation runs in parallel. While this card is counting, the operator should be checking Top Decline Reasons (which bucket spiked?), Top Declining Issuers (single-issuer outage?), Decision Manager Score Mix (recent rule pack deploy?). For this incident the root cause was a Decision Manager rule pack deployed at 09:35 UTC that over-weighted AVS-mismatch on non-US issuers; rolled back at 10:38 UTC and the spike resolved within 4 minutes.
- Total incident loss came in at ~$54,000. The spike ran from 09:42 to 10:42 UTC (60 minutes), with the final minutes at lower burn rate as decline rate began returning to baseline. This becomes the line-item on the incident post-mortem and the case for tighter DM rule-pack deployment review going forward.
Sibling cards merchants should reference together
| Card | Why pair it with Revenue at Risk (live) |
|---|---|
| Decline Spike vs Checkout Funnel Drop | The cross-channel companion. This card is the dollar number; that card is the dual-axis chart showing the decline + funnel correlation. |
| Decline Rate Spike Alert | The alert that triggers this card to light up. |
| Top Decline Reasons | The first card to open during an active incident: which reason spiked? |
| Top Declining Issuers | Single-issuer-outage diagnostic. |
| Decision Manager Score Mix | Was a recent fraud rule pack the cause? |
| Recoverable Revenue (decline-driven) | The post-incident view: of the revenue lost during the spike, how much could be won back via dunning / retry? |
| Decline Rate | The base metric this card watches. |
| Payment Health Score | The composite that drops sharply during an active spike. |
Adobe Commerce / BigCommerce / Shopify checkout_funnel | The live checkout-attempts pulse that feeds the formula. |
Reconciling against the vendor’s own dashboard
Where to look in CyberSource Business Center (EBC2): This card has no direct EBC2 counterpart, it’s a Vortex IQ-derived cross-channel signal that joins CS decline data to commerce-platform live checkout data. The closest EBC2 view is Transactions → Search filtered to last 15 minutes; from there the operator can see decline-rate-now but not the dollar projection. For the active-incident workflow:- EBC2 → Transactions → Search, confirm the spike is real-time on CS side.
- EBC2 → Decisions → Decision Manager → Performance, was a rule pack recently deployed?
- [Adobe Commerce / Shopify / BigCommerce checkout-funnel dashboards], confirm the storefront is also seeing checkout drop.
| Reason | Direction | What to do |
|---|---|---|
| 15-minute rolling window. We compute current decline rate over the most recent 15 minutes. Smaller windows are noisy; larger windows lag the spike. | The number can jump as the spike crosses the 15-min boundary. | Treat as live indicator, not a forensic figure. The post-incident Recoverable Revenue card uses tighter window logic. |
| AOV is rolling 30D. If the spike happens during a sale event with abnormal AOV, our projection may understate / overstate. | Either direction. | Use the post-incident card with actual transaction-level AOV for the exact loss number. |
| Multi-currency FX. We use current-period FX rates to sum into the dashboard’s display currency. | Tiny drift versus end-of-period FX. | n/a for incident response. |
| Commerce sibling refresh. The checkout-attempts-per-min KPI is itself refreshed on a 60-second cycle. | Small lag possible during very fast-moving spikes. | Both connectors must be live for accurate output; the card grays if either is offline. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
cs_revenue_at_risk_live ↔ commerce platform’s own funnel-drop alert | They co-fire within 60 seconds of each other during a real CS-driven incident. | If commerce funnel drops without this card lighting up, the cause is storefront-side (page broken, JS error) not payment-side. |
cs_revenue_at_risk_live ↔ post-incident cs_xc_recoverable_revenue | The latter is typically a smaller number (some of the at-risk revenue is winnable back via dunning / retry; not all). | If recoverable >> at-risk, the formula calibration needs review. |
cs_revenue_at_risk_live ↔ cs_payment_health_score | The composite always drops while this card is non-zero. | n/a (causal relationship). |
Known limitations / merchant FAQs
**Why does this card show 0 in steady state and only fires during real incidents. If the operator wants a steady-state lost-revenue figure, see Recoverable Declines (soft). What’s the difference between this card and Recoverable Revenue? Time horizon. This card is forward-looking, real-time: “right now, while I’m watching, X dollars are leaking out per minute.” Recoverable Revenue is backward-looking, monthly: “of the soft declines we accumulated last month, how much could we win back via dunning / retry next month?” The two are complementary, not redundant. My commerce platform isn’t connected, why is this card grayed out? The formula needs the commerce platform’s livecheckout_attempts_per_minute to compute. Without it, “decline rate spike” is incomplete information (the same +5pp spike during 10 attempts/min is trivially small revenue; during 100 attempts/min it’s catastrophic). Connect Adobe Commerce, BigCommerce, or Shopify to the same Vortex IQ workspace and the card lights up.
The card fired but my commerce platform shows no funnel drop. What does that mean?
Usually one of three things: (1) the decline spike is happening on retry / recurring traffic that doesn’t go through the storefront checkout funnel (B2B corporate billing, subscription auto-bill); (2) the customer is rebounding to alternate tender (Apple Pay, PayPal) successfully, so the storefront completes despite CS declines; (3) the spike is on a small subset of cards (e.g. one issuer) that only affects ~3% of attempts. Drill into Decline Spike vs Checkout Funnel Drop to see the dual-axis view.
Can I trust this number for my incident post-mortem?
For real-time incident response, yes, it’s the right size-of-problem signal at the time. For the formal post-mortem with finance attached, use Recoverable Revenue (decline-driven) which uses transaction-level decline data after the incident closes. The two should agree within 10, 20% on a typical incident.
What’s a good “burn rate” threshold for incident escalation?
Depends on the merchant’s scale. For a Fortune-500 enterprise, 5,000/min sustained is incident-commander territory. For a mid-market merchant, those thresholds scale down 5, 10x. The card displays the burn rate alongside the running total so the operator can decide.
Does this card fire on planned maintenance or known issuer outages?
It fires on the underlying decline-rate spike regardless of cause. If ops knows that, e.g., Capital One has a known outage announced via Visa OPS Bulletin, the operator should still investigate (sometimes the announced outage is a small subset of the actual issue). Vortex IQ doesn’t have a “suppress alert during planned issuer outage” feature today; it could be added but most enterprise merchants prefer to see the alert and confirm cause manually.
My multi-currency global merchant, what currency does this card display?
The dashboard’s display currency at sync-time FX. The per-currency breakdown is on hover. For the most accurate per-currency view during an active incident, also keep Revenue by Currency open in a sibling tab.
Can I get historical data on this card?
The historical record of every time this card has fired (with start time, end time, peak burn rate, total at-risk dollars) lives in the Vortex IQ incident-history view. The card itself only displays the live state; the history shows up alongside the alert log.