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.
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_subject on the 92 D+F rows:
Five things worth noticing:
- 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
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.
Cross-connector reconciliation:
End-to-end: this card and PP Success Rate share a denominator. Watch them together; small denominator shifts (a slow day, a spike of pending) move both rates without anything actually changing in customer behaviour.
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.