> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Revenue at Risk (live), PayPal > Live decline-driven revenue loss while the spike is active. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type) > 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](/nerve-centre/stripe/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)](/nerve-centre/kpi-cards/paypal/recoverable-revenue) 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 | ```text theme={null} 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: 1. **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. 2. **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](/nerve-centre/kpi-cards/paypal/top-decline-event-codes) for the live mix. 3. **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. 4. **Cross-platform correlation.** [PP XC Decline vs Funnel](/nerve-centre/kpi-cards/paypal/decline-spike-vs-checkout-funnel-drop) 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. 5. **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](/nerve-centre/kpi-cards/paypal/decline-failure-rate). The right operator response: open [PP Decline Event Codes](/nerve-centre/kpi-cards/paypal/top-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](/nerve-centre/kpi-cards/paypal/decline-failure-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](/nerve-centre/kpi-cards/paypal/top-decline-event-codes) | The first card to open when this lights up. Tells you WHY declines spiked. | | [PP Recoverable Declines](/nerve-centre/kpi-cards/paypal/recoverable-declines) | Of the at-risk dollars, which ones are recoverable (soft declines) vs hard-loss (instrument\_declined, expired\_card)? | | [PP Alert Decline Spike](/nerve-centre/kpi-cards/paypal/decline-rate-spike-alert) | The alert-list view. Multiple stores running PayPal can see all live spikes in one place. | | [PP XC Decline vs Funnel](/nerve-centre/kpi-cards/paypal/decline-spike-vs-checkout-funnel-drop) | Cross-platform: confirms whether the decline spike is hitting real customers (funnel drops) or just blocked attempts. | | [PP XC Recoverable Revenue](/nerve-centre/kpi-cards/paypal/recoverable-revenue) | The 30-day forecast version of this card. Use this card for "now"; that one for "month over month". | | [PP Fraud Velocity](/nerve-centre/kpi-cards/paypal/fraud-velocity) | Pair when the spike is `denied_by_risk` driven, are we seeing a fraud attack? | | [Stripe Revenue at Risk](/nerve-centre/stripe/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](https://www.paypal.com/businessmanage/activities), filter Status = "Denied" + "Failed" for the last hour. * [PayPal Business → Reports → Activity download](https://business.paypal.com/merchantdata/reportHome), pull a 1-hour CSV to verify the decline event codes. * [PayPal Business → Notifications](https://www.paypal.com/businessprofile/settings/notifications) for individual decline emails (per-transaction alerts). * [PayPal Business → Risk Settings](https://www.paypal.com/businessprofile/settings/risk), 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](/nerve-centre/kpi-cards/paypal/decline-failure-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`](/nerve-centre/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`](/nerve-centre/kpi-cards/paypal/decline-spike-vs-checkout-funnel-drop) | 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](/nerve-centre/kpi-cards/paypal/decline-rate-spike-alert). ***
Documentation cross-reference (for agencies running multiple platforms) The Stripe twin is [`stripe.stripe_revenue_at_risk`](/nerve-centre/stripe/stripe_revenue_at_risk). Same shape (live decline-spike vs baseline, dollar-weighted), different processor. Multi-processor merchants run both side-by-side on operations dashboards.
## 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](/nerve-centre/kpi-cards/paypal/decline-failure-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](/nerve-centre/kpi-cards/paypal/top-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](/nerve-centre/kpi-cards/paypal/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](/nerve-centre/kpi-cards/paypal/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](/nerve-centre/kpi-cards/paypal/decline-failure-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](/nerve-centre/kpi-cards/paypal/dispute-value), [PP Dispute Rate](/nerve-centre/kpi-cards/paypal/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.