At a glance
Operational alert that fires when the PayPal decline rate jumps more than 2 standard deviations above the preceding 1-hour baseline. Built for the operations team, distinct from the executive PP Decline Rate gauge: this card is binary (firing or not), real-time, and explicitly statistical (handles both small-store noise and high-volume spikes). The trigger card behind PP Revenue at Risk (live).
| The formula | current_1h_decline_rate > baseline_mean + (2 × baseline_stddev). The baseline is computed over the preceding 1 hour (rolling, so noise gets smoothed). The 2σ threshold catches statistically meaningful jumps regardless of absolute level. |
| Event code filter | T00xx only (payment events). Same denominator as PP Decline Rate, only attempts (S + D + F + P + V + T) count. |
| Numerator (declines) | transaction_status IN [D, F]. PayPal-side denials, bank-side issuer declines on bridged card payments, network failures, 3DS abandons, all included equally. |
| What “spike” means here | Statistical, not absolute. A baseline of 4% with current rate 8% is a spike; a baseline of 12% with current rate 13% is not (it’s already volatile so 1 percentage point is within noise). The 2σ threshold normalises for the store’s own variability. |
| Pending status (P) handling | In denominator, not in spike numerator. If pending payments resolve to D in the next hour, that hour’s rate climbs and may trigger a spike alert then; the original pending hour does not. |
| Refunds (T11) and disputes (T19) | NOT counted. This card watches payment-stage declines only. |
| Currency | n/a (rate, currency-neutral). Multi-currency PayPal accounts get a single, valid spike alert across all currencies. |
| Seller Protection | Not a factor; declines never reach the protection-eligibility stage. |
| Why 2σ, not absolute threshold | A small store with 50 attempts/hour has higher natural variability than a large store with 500/hour. An absolute “alert at >8%” threshold would either over-fire on small stores (every quiet hour with 1 decline lights up) or miss genuine issues on large stores (a 1-point absolute jump is meaningful at scale). The σ-based approach adapts to each store’s own noise floor. |
| Page cap | 10,000 transactions per call. Live windows are 1 hour so unlikely to hit cap. |
| Time window | RT (real-time, refreshes every sync, typically every 5-15 minutes). |
| Alert trigger | > 2σ vs 1h baseline. The card’s headline state is binary: firing or quiet. |
| Roles | owner, finance, operations |
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 subscription beauty brand running PayPal Express alongside Stripe. The 24 hours leading up to 14:00 UTC on 12 Apr 26 give us the baseline distribution. Hourly decline-rate baseline (preceding 24 hours):| Hour | Decline rate |
|---|---|
| Hour-1 | 5.0% |
| Hour-2 | 4.6% |
| Hour-3 | 5.2% |
| Hour-4 | 4.8% |
| …up to Hour-24 | average 4.9%, stddev 0.7% |
| Metric | Value |
|---|---|
| T00 attempts | 240 |
| T00 declined (D + F) | 33 |
| Current decline rate | 13.75% |
- The spike is 12.6 standard deviations above baseline. That’s an extraordinarily strong signal, statistically near-impossible by chance. Something concrete changed: a Risk rule misfire, a 3DS provider outage, a checkout deploy break, or a coordinated card-testing attack. The card fires hard. The operator’s first move is opening PP Decline Event Codes for the dominant subject.
- Compare with absolute-threshold alerting. A simple “alert at >8%” trigger would have caught this too (13.75% >> 8%), but on a different store with baseline 7% and natural stddev 1.5%, the same logic would over-fire every other quiet hour. The 2σ framing adapts to each store automatically.
- What if the same 13.75% rate had appeared on a high-volatility store? A store with baseline mean 9% and stddev 3% has 2σ threshold = 15%. The 13.75% rate would NOT trigger the alert because it’s within that store’s normal noise. That’s correct: such a store is already in trouble, but this hour wasn’t unusual for them. They need PP Decline Rate (absolute level) not this card (anomaly detection).
- What does the operator do? The Vortex IQ playbook: (a) open PP Decline Event Codes, find the dominant
transaction_subject; (b) ifdenied_by_risk, log into PayPal Business → Risk Settings and check for recent rule changes; (c) ifpayer_authentication_required, the 3DS provider has an outage, suggest Apple Pay / Google Pay as workaround; (d) ifnetwork_errororinstrument_declinedmass, check your own checkout for a recent deploy; (e) ifdenied_by_riskclustered to one IP / email pattern, you’re under a card-testing attack, see PP Fraud Velocity. - The spike will self-cancel if it persists. Sustained elevation raises the next hour’s baseline; by hour-3 of a sustained issue the spike alert has gone quiet (the new “normal” is the elevated rate). That’s by design: this card is for change detection. Sustained issues need PP Decline Rate which compares to a 7-day baseline.
Sibling cards merchants should reference together
| Card | Why pair it with PP Decline Rate Spike Alert |
|---|---|
| PP Decline Rate | The absolute-level view. This card catches change; that one catches steady state. Both fire on a sustained problem after the first hour. |
| PP Revenue at Risk (live) | The dollar-weighted twin. Spike alert says “something’s wrong”; revenue-at-risk says “and this is how much it’s costing per hour”. |
| PP Decline Event Codes | First card to open when this fires. Tells you WHY declines spiked. |
| PP Fraud Velocity | If the spike is denied_by_risk driven, this card surfaces the attack signature (clustered IPs, email patterns). |
| PP Recoverable Declines | Of the spike, which dollars are recoverable via dunning vs hard-loss. |
| PP XC Decline vs Funnel | Cross-channel: confirms the spike is hitting real customers (funnel drops) not just blocked attempts. |
| PP Alert Fraud Velocity | The fraud-specific spike alert. Pair when the dominant subject is denied_by_risk. |
| PP Alert Dispute Velocity | Disputes-spike alert. A decline spike that follows a dispute spike usually points to PayPal Risk tightening rules in response. |
| Stripe Decline Rate Spike Alert | The Stripe twin. Simultaneous fire = upstream issue (3DS network, your checkout); PayPal-only fire = PayPal-side. |
Reconciling against the vendor’s own dashboard
Where to look in PayPal Business: PayPal Business does NOT offer a built-in σ-based decline-spike alert; this card is a Vortex IQ-derived signal. The closest PayPal-native screens for cross-checking:- Activity → All Transactions, filter Status = “Denied” + “Failed” for the last hour and previous hour, hand-compute the rate to verify our numbers.
- PayPal Business → Notifications for individual decline emails (per-transaction, not aggregate).
- PayPal Business → Risk Settings to see whether a Risk rule changed recently that might explain a
denied_by_riskspike. - PayPal Business → Reports → Activity download for the row-level CSV.
- “Live transactions” tile shows count but no rate calculation.
- The Risk dashboard’s “blocked transactions” counter does NOT distinguish baseline-vs-spike.
- “Real-time alerts” in PayPal Notifications is per-transaction, not aggregated.
| Reason | Direction of divergence | What to do |
|---|---|---|
| Baseline window length. We use the immediately preceding 1 hour. A user comparing against “yesterday at this time” would see different math. | Either direction | Use Vortex IQ’s framing for live response; use day-over-day comparisons for trending. |
| Sample size. With < 30 attempts in either window, the σ calculation is unstable. Small stores may see false-positive fires on individual unlucky declines. | Vortex IQ may over-fire on small stores | Layer with PP Revenue at Risk (live) which dollar-weights the signal; small-dollar fires are usually harmless. |
| Refresh lag. Card refreshes every 5-15 minutes; a spike that started 4 minutes ago may not yet be reflected. | Vortex IQ may be lagged | Wait one refresh cycle. |
| Pending-resolution timing. Pending payments resolving to D bump the rate retroactively. | Vortex IQ may shift between refreshes | Normal; pending is rarely > 5% of attempts. |
| Time zone. Hourly windows are UTC-anchored; PayPal Business uses your account timezone. The “current hour” boundary may differ. | Boundary effects | Compare by hour-of-day, not hour-name. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
pp_alert_decline_spike ↔ stripe.stripe_alert_decline_spike | Two independent processors. PayPal-only fire is most common; simultaneous fire is rare. | A simultaneous fire usually means upstream: 3DS network outage, your own checkout deploy, an ad-platform bot wave hitting both checkout paths. |
pp_alert_decline_spike + pp_alert_fraud_velocity together | Both firing simultaneously = card-testing attack (denied_by_risk dominant). | Decline spike alone, no fraud velocity = legitimate-customer issue (3DS, deploy break). |
pp_alert_decline_spike ↔ pp_xc_decline_vs_funnel | Should correlate when the spike is hitting real customers. | Decline spike WITHOUT funnel drop = blocked fraud, no real revenue at risk. Decline spike WITH funnel drop = real customers being blocked. |
/v1/reporting/transactions.
Known limitations / merchant FAQs
Why is the alert σ-based instead of an absolute % threshold? Because each store has different natural variability. A small store with 50 attempts/hour fluctuates 4-9% naturally; an absolute “alert at >8%” trigger over-fires every quiet hour. A high-volume store with 1,000 attempts/hour fluctuates 4.5-5.2%; the same trigger ignores meaningful 1-percentage-point deteriorations. The 2σ threshold normalises to each store’s own noise floor, alerts when something different is happening, regardless of absolute level. The alert fires every Monday at 02:00 UTC, why? Two common reasons: (1) eCheque batch clearance, banks process eCheque overnight Sunday and PayPal flips a chunk fromP to S or D in the early Monday hours, the morning hour’s “current” rate spikes; (2) an automated weekly drop email or recurring promo brings a sudden mostly-guest-checkout traffic burst. The first is structural and ignorable; the second is real and worth optimising. If the spike is recurring and the funnel doesn’t drop, suppress the alert window for that hour.
What’s the difference between this and PP Decline Rate?
Different jobs. PP Decline Rate is the absolute % gauge (alert fires at >8% sustained). This card is the anomaly detector (alert fires when the rate jumps statistically meaningfully vs the prior hour). On a sustained issue, this card fires once at the spike onset, then goes quiet as baseline catches up; PP Decline Rate fires when the elevated rate persists past the steady-state threshold. They complement each other.
Will this card miss a sustained slow-rise issue?
Yes, by design. A slowly-rising decline rate (each hour 0.2 percentage points worse than the last) never generates a 2σ jump because the baseline keeps catching up. Slow-rise issues need the absolute-level PP Decline Rate card. Operations teams run both.
Why is the baseline only 1 hour?
For responsiveness. A 24-hour or 7-day baseline would smooth out so much that hourly spikes get diluted. The 1-hour rolling baseline catches the moment something changed, which is what operations teams need. Trade-off: a sustained issue stops looking spiky after one hour. That’s why you pair this with the steady-state card.
Small stores get false positives, anything I can do?
Yes, two options: (1) suppress the alert below a minimum-attempts floor (e.g. only fire when current hour has ≥ 30 attempts), this requires a manifest tweak; (2) layer with PP Revenue at Risk (live) which dollar-weights the signal, a $20 at-risk signal on a small store usually means one unlucky decline, not a real issue. Most operational teams use the dollar-weighted view as the primary trigger and this card as a debug tool.
The card fires but the funnel didn’t drop, what’s happening?
Most likely you’re blocking real fraud and the spike isn’t real customer-loss, it’s blocked fraud-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 and PayPal Risk did its job. Cross-check with PP Fraud Velocity. No customer impact, no operational action beyond watching.
Stripe’s twin didn’t fire but PayPal’s did, why?
PayPal-only spikes are common because PayPal carries different traffic (younger, international, mobile, bank-funded) and is subject to PayPal Risk decisions Stripe never sees. PayPal-only fires usually point to: (1) a PayPal Risk rule change you can check in Risk Settings, (2) an eCheque clearance hiccup, or (3) a campaign disproportionately routed through PayPal Express. If both fire, the issue is upstream of either processor.
Does this card use the same baseline as PP Revenue at Risk (live)?
Yes, same 1-hour-preceding window. If both cards fire together (and they usually do), you have a high-confidence signal: statistical anomaly + dollar exposure. If the spike alert fires but at-risk is $0, the spike is in low-volume hours (overnight UTC) and probably not worth chasing.
Multi-currency PayPal account, does the alert work?
Yes, count-based. The σ calculation works on rate not value, so currency mix doesn’t affect the spike trigger. The dollar-weighted PP Revenue at Risk (live) shows the multi-currency exposure once the alert fires.