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 |
| 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 |
- 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 (massdenied_by_riskfrom 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 (massinstrument_declinedornetwork_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-channel 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.
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-channel: 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_riskspike.
- “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.
| 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. |
| 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). |
Known limitations / merchant FAQs
**Why does this card show 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: ifdenied_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).