Revenue at Risk (live), PayPal

Metrics type: Key Metrics • Category: Payment Gateway

Live decline-driven revenue loss while the spike is active.

At a glance

Real-time dollar value of PayPal revenue being lost RIGHT NOW because the decline rate is elevated above its 1-hour baseline. Computed every refresh as (current_decline_rate − baseline_decline_rate) × current_attempt_value. Fires the moment a decline spike correlates with active checkout traffic. The PayPal-only twin of Stripe Revenue at Risk.


The formula	`(current_1h_decline_rate − preceding_1h_baseline_decline_rate) × SUM(amount of T00 attempts in current 1h)`. The dollar value of declines that would not have happened if the rate were still at baseline.
Event code filter	T00xx only (payment events). Decline spike measured on `status IN [D, F]`; baseline measured on the prior 1-hour window.
Transaction status filter	Numerator (declines): `D` + `F` only. Denominator (attempts): all T00 statuses for the current hour. Pending (`P`) attempts are in the denominator (they’re attempts) but not the decline numerator.
What “live” means	The card refreshes on each engine sync (typically every 5-15 minutes during business hours). It uses a rolling 1-hour window for “current” and the preceding 1-hour window as baseline. Spikes that started > 1 hour ago raise the baseline and dampen the signal; the card is designed to catch the onset of the spike, not its sustained shoulder.
Refunds (T11)	NOT counted. This card is about declines, not returns.
Disputes (T19)	NOT counted. This card is about declines, not chargebacks. See PP Revenue at Risk Forecast (decline-driven) for the post-decline recoverable view.
Currency	Multi-currency without FX. A live spike on a single-currency store is unambiguous; a multi-currency spike sums the at-risk values arithmetically without FX conversion. Most spikes are short and concentrated geographically (one ad campaign, one checkout-flow break) so they’re often single-currency in practice.
Pending status (P) handling	Pending attempts are in the denominator (they were attempts) but the live decline rate uses only resolved-as-declined (D + F). If a pending later resolves to D, the next refresh picks it up.
Seller Protection	Not a factor; this card is about declines at the payment stage, not post-success protection.
Page cap	10,000 transactions per call. Live windows are 1 hour so unlikely to hit cap unless your store is doing > 10k attempts/hour (rare even on Black Friday).
Time window	`RT` (real-time, rolling 1-hour current vs preceding 1-hour baseline).
Alert trigger	`> $0`. Any non-zero value is a live signal. The card is binary-by-design, when it lights up, you act.
Roles	owner, finance

Calculation

Calculated automatically from your PayPal 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-based fashion brand running a flash sale. PayPal is the secondary checkout option but carries the international + younger-demographic spike traffic. The current rolling hour is 14:00-15:00 UTC on 12 Apr 26. Preceding hour (13:00-14:00 UTC, baseline):

Metric	Value
T00 attempts	180
T00 successful (S)	168
T00 declined (D + F)	9
Baseline decline rate	9 ÷ 180 = 5.0%
Sum of attempt amounts	$14,400

Current hour (14:00-15:00 UTC, live):

Metric	Value
T00 attempts	240 (flash sale traffic spike)
T00 successful (S)	199
T00 declined (D + F)	33
Pending (P)	8
Current decline rate	33 ÷ 240 = 13.75%
Sum of attempt amounts	$19,200

PP Revenue at Risk (live)
  decline_delta = 13.75% − 5.0% = 8.75%
  current_attempt_value = $19,200
  at_risk = 8.75% × $19,200
          = $1,680

The card lights up at $1,680. Five things worth noticing:

The spike is 8.75 percentage points above baseline. A “normal-day” 5% decline rate jumped to 13.75% in the current hour. That’s a clear anomaly worth investigating in real time, not at the next end-of-day report.
What’s likely going on? Three usual suspects, in order: (a) a 3DS provider outage at one of the buyer’s banks (mass payer_authentication_required); (b) a PayPal Risk rule misfiring on the flash-sale traffic (mass denied_by_risk from a new pattern PayPal hasn’t seen before, e.g. high-cart-value + new-buyer combination); (c) a checkout flow change pushed minutes ago that broke a payment field (mass instrument_declined or network_error). Open PP Decline Event Codes for the live mix.
The 8 pending (P) rows are not yet counted. They’re attempts that PayPal is still reviewing or that are clearing eCheque. If they all resolve to S in the next hour, no harm done. If a meaningful share resolve to D, the next refresh will surface a higher Revenue at Risk because the current hour’s numerator grows.
Cross-platform correlation. PP XC Decline vs Funnel overlays this card on the commerce-platform checkout funnel. If the funnel’s “card payment” drop-off step jumped from 6% to 14% in the same hour, that’s confirmation the decline is hurting actual customers, not just bots / fraud attempts. If the funnel didn’t move but the decline rate spiked, the spike is probably from blocked fraud attempts, no real revenue at risk.
The card resets when baseline catches up. If the elevated 13.75% rate persists into the next hour, the next hour’s “baseline” becomes the elevated rate, and the spike signal fades. This card catches change, not steady state. Sustained elevation is tracked by PP Decline Rate.

The right operator response: open PP Decline Event Codes, identify the dominant subject, and act. If denied_by_risk dominates, log into PayPal Business → Risk Controls and check for a recent rule change. If payer_authentication_required dominates, the 3DS provider is having an outage; offer Apple Pay / Google Pay as a workaround. If network_error dominates, check your own checkout for a recent deploy.

Sibling cards merchants should reference together

Card	Why pair it with PP Revenue at Risk (live)
PP Decline Rate	The headline rate. This card is the dollar-weighted, real-time, vs-baseline view; PP Decline Rate is the rolling rate.
PP Decline Event Codes	The first card to open when this lights up. Tells you WHY declines spiked.
PP Recoverable Declines	Of the at-risk dollars, which ones are recoverable (soft declines) vs hard-loss (instrument_declined, expired_card)?
PP Alert Decline Spike	The alert-list view. Multiple stores running PayPal can see all live spikes in one place.
PP XC Decline vs Funnel	Cross-platform: confirms whether the decline spike is hitting real customers (funnel drops) or just blocked attempts.
PP XC Recoverable Revenue	The 30-day forecast version of this card. Use this card for “now”; that one for “month over month”.
PP Fraud Velocity	Pair when the spike is `denied_by_risk` driven, are we seeing a fraud attack?
Stripe Revenue at Risk	The Stripe twin. If both fire simultaneously, the issue is upstream (3DS network outage, your own checkout deploy) not processor-specific.

Reconciling against the vendor’s own dashboard

Where to look in PayPal Business: PayPal Business has no equivalent live “revenue at risk” tile, this is a Vortex IQ-derived signal. The closest PayPal-native views to cross-check the underlying decline data:

Activity → All Transactions, filter Status = “Denied” + “Failed” for the last hour.
PayPal Business → Reports → Activity download, pull a 1-hour CSV to verify the decline event codes.
PayPal Business → Notifications for individual decline emails (per-transaction alerts).
PayPal Business → Risk Settings, check whether a rule change was applied recently that explains a denied_by_risk spike.

Other views that look like this but aren’t:

“Live transactions” tile shows count not value at risk.
The Risk dashboard’s “blocked transactions” counts ALL fraud-flagged events including the ones that would have declined anyway, not just the spike-attributable ones.
“Real-time alerts” in PayPal Notifications is per-transaction, not aggregated to a dollar figure.

Why our number may legitimately differ from a hand-calculation:

Reason	Direction of divergence	What to do
Refresh lag. Card refreshes every 5-15 minutes; spike onset can outrun the refresh.	Vortex IQ may be lower in the first 5 minutes of a spike	Wait one refresh cycle.
Baseline window length. We use the immediately preceding 1 hour as baseline. If the preceding hour was itself elevated (sustained issue), the delta looks small even though the rate is high.	Vortex IQ may understate for sustained spikes	Use PP Decline Rate (rolling absolute) for sustained-state monitoring.
Pending-resolution timing. Pending payments that resolve to D after the card refreshes appear in the next refresh, not the current one.	Vortex IQ may be lower when many pending resolve unfavourably	Wait for next refresh; pending is rarely > 5% of attempts.
Multi-currency arithmetic. Multi-currency stores sum at-risk values across currencies without FX.	Headline number is not directly comparable across currencies	Use single-currency stores for a clean signal; mixed-currency spikes are still useful directionally.
Time zone. Card uses UTC for the rolling hour; PayPal Business uses your account timezone. The “current hour” boundary may differ.	Boundary effects	Compare hour-of-day, not hour-name.

Cross-connector reconciliation:

Comparison	Expected relationship	When divergence is legitimate
`pp_revenue_at_risk_live` ↔ `stripe.stripe_revenue_at_risk`	Both can fire independently; usually they do. A simultaneous fire is unusual and means upstream (3DS provider outage, your own checkout deploy, ad-platform sending a sudden bot wave).	A PayPal-only fire usually means PayPal-side (Risk rule change, eCheque clearing problem) or PayPal-traffic-specific (international ad campaign).
`pp_revenue_at_risk_live` + Stripe twin	Sum across processors gives total live exposure	Useful for multi-processor merchants on Black Friday or similar high-traffic hours.
`pp_revenue_at_risk_live` ↔ `pp_xc_decline_vs_funnel`	Should correlate. If decline spike + funnel drop fire together, the at-risk number is real customer loss.	If decline spike fires without funnel drop, the spike is blocking fraud (no real revenue at risk).

This card is a Vortex IQ-derived signal, not a PayPal-native metric. The closest PayPal-side comparable is the Risk dashboard, which captures fraud-blocked events rather than this card’s “spike vs baseline” framing. For end-to-end live monitoring use this card alongside PP Alert Decline Spike.

Known limitations / merchant FAQs

**Why does this card show

0 most of the time?** By design. The card only lights up when the *current* 1-hour decline rate is above the *preceding* 1-hour baseline. Most hours don't have spikes; the card sits at

0. When it fires, it’s a real signal worth acting on. The $0 baseline is a feature, not a bug; we don’t want operators desensitised by always-on noise. What’s a “decline spike” vs a steady-state decline problem? A spike is the rate jumping in one hour. Steady-state is the rate staying elevated across hours. This card catches spikes; PP Decline Rate catches steady-state. The distinction matters because the response is different: a spike usually points to an acute issue (Risk rule change, deploy break, 3DS provider outage) you can fix in minutes; steady-state points to a structural issue (traffic-mix shift, regional decline cluster) you fix over weeks. The card lit up at $1,200 but the funnel didn’t drop, what’s happening? Most likely you’re blocking real fraud and the at-risk number isn’t real revenue loss, just blocked attempts. Open PP Decline Event Codes: if denied_by_risk dominates and the email/IP cluster looks suspicious (multiple failed attempts from same IP), it’s a card-testing attack. PayPal Risk did its job. Cross-check with PP Fraud Velocity. No action needed beyond watching the velocity. The card fires every Monday morning, why? Two common reasons: (1) eCheque batch clearance, banks process eCheque overnight Sunday and PayPal flips a chunk from P to S or D in the early Monday hours, the morning hour’s “current” rate looks artificially elevated against Sunday-overnight baseline; (2) a recurring promo or weekly drop email blast brings traffic that includes more guest checkouts (higher decline). The first is structural and ignorable; the second is real and worth optimising checkout for. Should I retry every declined payment from a live spike? Soft declines (insufficient_funds, payer_authentication_required, network_error) recover well on retry. Hard declines (denied_by_risk, instrument_declined, expired_card) won’t. PP Recoverable Declines splits the two. For live spikes, the more urgent move is fixing the root cause (the next 100 customers are about to hit the same wall) rather than retrying the past 50. Why is the baseline only 1 hour, not 24 or 7 days? Because the goal is to detect change, not absolute level. A 1-hour rolling baseline catches the moment a spike begins; longer baselines lag too much for live response. The trade-off is that sustained issues (an all-day Risk-rule problem) become invisible to this card after the first hour, the baseline catches up. That’s why we pair it with PP Decline Rate for sustained-state monitoring. My multi-currency PayPal account, the live signal looks weird? Yes, multi-currency live signals sum at-risk values across currencies without FX. A spike on European traffic will show € revenue at risk added to USD baseline, which is arithmetically off. Use single-currency stores for clean live signals; for multi-currency stores, treat the directional movement as the signal even if the headline dollar figure is fuzzy. Are PayPal disputes counted in “revenue at risk”? No. This card is decline-only (T00 status D + F). Disputes (T19) are post-success customer escalations and have their own tracking (PP Dispute Value, PP Dispute Rate). The decline-driven and dispute-driven views are intentionally separated; their root causes are completely different. The card lit up but Stripe’s twin is silent, who’s right? Both, usually. PayPal-only spikes are the common case because PayPal carries different traffic (younger, international, mobile, bank-funded) and is subject to PayPal Risk decisions Stripe doesn’t see. PayPal-only spikes typically point to: (1) a PayPal Risk rule change, (2) a eCheque clearance hiccup, or (3) a campaign sending traffic disproportionately to PayPal Express. If both fire, the issue is upstream (3DS network outage, your own checkout deploy, an ad-platform bot wave).

Tracked live in Vortex IQ Nerve Centre

Revenue at Risk (live) is one of hundreds of KPI pulses Vortex IQ tracks across PayPal 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.

Get Started

The AI OS

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre

​At a glance

​Calculation

​Worked example

​Sibling cards merchants should reference together

​Reconciling against the vendor’s own dashboard

​Known limitations / merchant FAQs

​Tracked live in Vortex IQ Nerve Centre

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre