At a glance
Percentage of PayPal payment attempts that were denied or failed. Counts bothD(denied, includes PayPal-side AND bank-side declines) andF(failed, network errors / 3DS abandon) on T00xx payment events. The 25%-weight component of PP Payment Health Score, amplified ×5 in the composite so small movements feel large.
| The formula | COUNT(status IN [D, F] AND event_code STARTS T00) ÷ COUNT(event_code STARTS T00) × 100. Decline-or-fail count ÷ total payment attempts. |
| Event code filter | T00xx only (payment events). T11 (refunds), T19 (disputes), T03 (payouts) are not payment attempts and are excluded from both numerator and denominator. |
| Numerator (declines) | transaction_status IN [D, F]. D = denied (PayPal said no, OR the issuing bank said no on a card payment routed through PayPal). F = failed (network error, gateway timeout, 3DS challenge abandoned by buyer). The two are summed. |
| Denominator (attempts) | All T00 rows regardless of status. Same denominator as PP Success Rate, so the two cards’ numerators (S vs D+F) live in the same population. |
| What “denial” includes (PayPal-specific) | PayPal’s D is a catch-all that bundles: (1) PayPal’s own risk-model rejections (often denied_by_risk in transaction_subject); (2) issuer-side declines on PayPal-bridged card payments (instrument_declined, insufficient_funds, payer_authentication_required, expired card); (3) PayPal Seller policy rejections (restricted item, prohibited country). Stripe’s twin separates these; PayPal does not in the public reporting feed. |
| Pending status (P) handling | NOT counted as decline. Pending is transitional, not failure. If a pending later resolves to D, it counts then; if it resolves to S, it never counts here. |
| Voided / in-transit (V, T) | NOT counted as decline. V is buyer-cancelled within auth window; T is authorised-not-yet-captured. Neither is a failure. |
| Currency | n/a (rate, currency-neutral). Multi-currency PayPal accounts get a single, valid decline rate. |
| Refunds | Not a factor. A refund is a successful payment returned, not a decline. |
| Disputes | Not a factor. A dispute is a post-success customer escalation, not a decline at the payment stage. |
| Seller Protection | Not a factor. Coverage is about chargeback insulation; declines never reached the capture stage. |
| Page cap | 10,000 transactions per /v1/reporting/transactions call; 31-day window cap per call. |
| Time window | T/7D vsP (default 7D vs prior 7D, real-time on the headline tile). |
| Alert trigger | > 8%, sentiment key decline_rate. PayPal benchmarks 4-7% decline for healthy merchants; > 8% triggers a finance-team ping. The PP Payment Health composite uses a ×5 amplifier on this rate, so a 2-point swing here moves the composite 10 points. |
| 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 supplements brand. PayPal carries the international + younger-shopper mix; Stripe handles the desktop-card-on-file majority. The 7-day window covers 06 Apr 26 to 12 Apr 26. T00 (payment) row breakdown by status:| transaction_status | Count | What happened |
|---|---|---|
| S (success) | 1,140 | Captured cleanly |
| D (denied) | 78 | Mix of PayPal-side and bank-side declines |
| F (failed) | 14 | Network errors, 3DS abandons |
| P (pending) | 22 | eCheque + risk holds (not counted here) |
| V (reversed) | 2 | Buyer-cancelled (not counted) |
| T (in-transit) | 4 | Auth-only, not yet captured (not counted) |
| Total T00 attempts | 1,260 |
transaction_subject on the 92 D+F rows:
| Subject pattern | Count | Class | Recoverable? |
|---|---|---|---|
instrument_declined | 31 | Bank-side, hard | No, customer’s card has a problem |
insufficient_funds | 18 | Bank-side, soft | Yes, retry tomorrow / dunning |
payer_authentication_required | 14 | 3DS abandon | Yes, simplify checkout / Apple Pay |
denied_by_risk | 12 | PayPal-side risk model | Maybe, tunable in PayPal Risk settings |
expired_card | 9 | Bank-side, hard | Yes if you have card-update-service |
network_error / gateway timeout | 8 | Failure (F) | Retry usually succeeds |
- 7.3% is below the 8% alert but on the upper edge of healthy. No ping fires, but a smart operator notices the upward drift. If next week brings it to 8.2%, the alert fires AND the PP Payment Health Score drops 5 points (×5 amplifier on the +1 percentage point change).
- About 49 of the 92 declines (53%) are in PayPal’s PP Recoverable Declines bucket. Insufficient funds, 3DS abandon, and expired card are all addressable through dunning or checkout simplification. That’s $3,800 in soft-decline revenue worth chasing.
- The 12
denied_by_riskrows are PayPal-side, not bank-side. They’re tunable in the PayPal Business → Account Settings → Risk controls. If risk settings are too aggressive, legitimate customers are being rejected; if too loose, fraud chargebacks rise. The PayPal Risk team is the lever here, not your acquiring bank. - The 14
payer_authentication_requiredrows are 3DS abandons. The customer hit the 3DS challenge from their bank (verifying ownership of the card) and gave up before completing it. This is an experience problem, not a payment problem; lowering 3DS friction (lower-friction 3DS2 challenges, biometric prompts on mobile, an Apple Pay alternative) recovers a chunk. - Stripe comparison. If the same merchant’s Stripe decline rate is sitting at 4.5%, the 2.8-point gap is normal because PayPal bridges more bank-funded card payments and carries more international traffic. If the gap is > 4 points, look for a regional cluster or a too-aggressive PayPal Risk setting.
Sibling cards merchants should reference together
| Card | Why pair it with PP Decline Rate |
|---|---|
| PP Success Rate | The other side of the same denominator. Success + decline + pending + voided + in-transit = 100%. |
| PP Decline Event Codes | The “why” behind this rate. Bank-side (instrument_declined, insufficient_funds) vs PayPal-side (denied_by_risk) splits. |
| PP Recoverable Declines | The dollar-weighted view of soft declines. Insufficient funds, 3DS abandon, expired card. The dunning target list. |
| PP Retry Success Rate | Of customers who declined and retried within an hour, how many got through? Heuristic but useful. |
| PP Decline Rate by Card Country | Geographic decompose. Some countries decline 2-3x the global average. |
| PP Card Brand Performance | Per-brand success / decline rate. Discover and Amex tend to decline more than Visa / Mastercard on PayPal. |
| PP Payment Health Score | This card is the 25%-weight component, amplified ×5. Most of the score’s day-to-day movement comes from here. |
| PP XC Decline vs Funnel | Cross-channel: overlay decline spikes against checkout-funnel drops. A correlated drop confirms the decline is hurting revenue, not just churn. |
| Stripe Decline Rate (twin) | The Stripe twin. PayPal typically 2-4 points higher than Stripe for the same merchant. |
Reconciling against the vendor’s own dashboard
Where to look in PayPal Business: PayPal Business does not surface a “decline rate” tile, but you can derive it:- Activity → All Transactions, filter by Status → “Denied” + “Failed” for the same date range; count rows.
- Reports → Activity download for a CSV, count Status = “Denied” + “Failed” rows against total payment-attempt rows.
- Account Settings → Account Settings → Notifications for individual decline emails (per-transaction, not aggregate).
- “Sales transactions” report counts only Completed (S); it doesn’t expose the decline base rate.
- “Risk dashboard” (in PayPal Business → Reports → Risk) shows fraud-flagged declines specifically, not the full decline rate.
- “Failure reason summary” (varies by region) groups F failures only, not D denials.
| Reason | Direction of divergence | What to do |
|---|---|---|
| Page cap (10,000 transactions per call). High-volume merchants doing > 10k attempts in a 31-day page truncate the denominator. | Either direction depending on which slice gets cut | Use shorter windows; the 7D headline rarely caps. |
| Time zone. PayPal Business uses your account-configured timezone; Vortex IQ uses UTC. | Boundary-day drift | Compare equal date ranges accounting for tz offset. |
D/F bucketing. Some niche transaction_subject values straddle the line between D and F (e.g. payment-method-temporarily-unavailable). PayPal Business may classify them differently to our engine. | Tiny drift (< 0.3 percentage points) | Compare equal short windows. |
| Pending refresh lag. Pending transactions that resolve to D are reflected on the next sync; PayPal Business reflects state-at-now. | Vortex IQ may be lower for the most recent 24-72 hours | Wait for next refresh. |
| Event-code interpretation drift. Some older T00 sub-codes have been re-classified by PayPal over the years. Most engines, including ours, treat any T00 prefix uniformly; PayPal Business has finer granularity. | Tiny drift on long historical windows | Use shorter, recent windows for reconciliation. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
pp_decline_rate ↔ stripe.stripe_decline_rate | PayPal typically 2-4 percentage points higher than Stripe. | Traffic-mix difference: PayPal carries more international, mobile, younger demographic, and bank-funded buyers, all of whom decline more often. A larger gap (> 5 points) suggests a tunable PayPal Risk setting. |
pp_decline_rate ↔ commerce platform “checkout abandon rate” | Not directly comparable; checkout abandon spans multiple stages. | Use PP XC Decline vs Funnel to overlay them on the same time axis. |
pp_decline_rate ↔ paypal.pp_payment_health_score | Composite component (×5 amplifier on this rate). | Internal identity, must move together. If composite drops without decline rate moving, it’s success rate or dispute rate. |
Known limitations / merchant FAQs
Why is my PayPal decline rate higher than my Stripe decline rate? Three structural reasons, all expected: (1) PayPal carries more international, mobile, and younger-demographic traffic, all of which decline more often; (2) PayPal’sD bucket bundles bank-side issuer declines on PayPal-bridged card payments alongside PayPal-side risk-model rejections, so it captures a wider net; (3) PayPal Risk (the merchant’s own configurable risk model) adds a layer of rejections that Stripe’s Radar does differently. A 2-4 point PayPal-higher gap is normal; > 5 points is worth investigating.
What does “denied” really mean for PayPal?
D is a catch-all that includes (a) PayPal’s own risk-model rejection (you can see these as denied_by_risk in transaction_subject and tune them in PayPal Business → Risk settings), (b) the issuing bank rejecting the card on a PayPal-bridged card payment (instrument_declined, insufficient_funds, expired_card), and (c) PayPal Seller policy violations (restricted item, prohibited country, account flag). For the breakdown see PP Decline Event Codes. From the merchant POV the customer didn’t pay either way.
Are 3DS abandonments counted as declines?
Yes, as F (failed). The customer was challenged by their bank to confirm card ownership and abandoned before completing. They count toward decline rate. Stripe surfaces these separately as requires_action_abandoned; PayPal bundles them into F. To reduce 3DS abandons, offer Apple Pay / Google Pay as alternatives (no 3DS step on first-party wallets).
Are pending payments that fail later double-counted?
No. A payment lives in one status at a time. While P it’s neither success nor decline; when it transitions to D or F it counts as decline from that moment on the next refresh. The denominator stays the same (the original T00 attempt was one row).
My PayPal Risk settings, can I tune them to lower decline rate?
Yes for the PayPal-side decisions, no for the bank-side. PayPal Business → Account Settings → Risk Controls lets you loosen filters (lower fraud thresholds, expanded country list, lifted velocity caps). Loosening reduces declines but raises chargeback risk; tightening does the inverse. Check PP Dispute Rate and PP Fraud Velocity before and after any change. Bank-side declines (issuer rejections on cards) you cannot tune; you can only route them through smarter retry logic.
Why did decline rate spike at 11pm UTC?
Time of day matters. Late-night UTC corresponds to morning hours in Asia + Australia, where bank-funded buyers (high decline) dominate. The spike usually fades by US business hours when card-on-file Stripe-style flow takes over. If a merchant runs an Asia-Pacific-targeted ad campaign during those hours expect a noticeable bump. Use PP Decline Rate by Card Country to confirm.
Should I retry declined payments automatically?
Soft declines (insufficient_funds, payer_authentication_required) often succeed on retry within 24-48 hours. PayPal does not auto-retry; if you have dunning logic or a retry-with-different-funding-source flow it pays off here. Hard declines (instrument_declined, expired_card, denied_by_risk) won’t recover without customer action. PP Recoverable Declines splits the two.
Is “F” failed counted the same as “D” denied?
Yes, both go into the numerator. Operationally they’re different (F is usually transient, recoverable on retry; D is usually a hard rejection) but for the headline rate they count equally. Drill into the event codes to separate them.
My multi-currency PayPal account, does this rate work?
Yes, count-based ratios are currency-neutral. A multi-currency account gets one valid decline rate that mixes USD + EUR + GBP attempts arithmetically.