At a glance
Percentage of PayPal payment attempts that succeeded. Counts only payment events (T00xx), and counts only transaction_status = S as success. The 35%-weight component of PP Payment Health Score. PayPal twin of Stripe’s success rate, but typically a few points lower because PayPal carries more high-risk traffic.
| The formula | COUNT(status='S' AND event_code STARTS T00) ÷ COUNT(event_code STARTS T00) × 100. Successes ÷ all attempted payments. |
| Event code filter | T00xx only (payment events). T11 (refunds), T19 (disputes), T03 (payouts), T17 (adjustments) are not payment attempts and are excluded from both numerator and denominator. |
| Numerator (successes) | transaction_status = S. PayPal’s success state, money has been authorised AND captured. |
| Denominator (attempts) | All T00 rows regardless of status, S + D + F + P + V + T. Pending payments (eCheque clearing, SEPA, hold-for-review) are counted in the denominator from the moment they’re attempted, even though they may flip status later. |
| Pending status (P) handling | Counted in denominator only. P is treated as “attempted but not yet resolved”, which slightly drags this card’s headline lower for stores with heavy eCheque / SEPA volume. When P resolves to S, the next refresh shows the correct higher rate; if it resolves to D, the rate stays low but is now “true”. |
| What this card excludes | Refunds (T11) are not failures, they’re customer-initiated returns of successful payments. Disputes (T19) are not failures either, they’re post-success customer escalations. Both have their own cards. |
| Currency | n/a (rate, currency-neutral). A multi-currency PayPal account gets a single, valid success rate. |
| Refunds | Not a factor. A refunded payment was still a successful payment at the moment of capture; refunds count on PP Refund Rate, not here. |
| Disputes | Not a factor. A disputed payment was still successful at capture; disputes count on PP Dispute Rate. |
| Seller Protection | Not a factor. Coverage is about chargeback insulation on already-successful payments; it doesn’t change whether a payment succeeded. |
| Page cap | 10,000 transactions per /v1/reporting/transactions call; 31-day window cap per call. High-volume merchants may see the rate drift slightly on heavy days where pagination caps. |
| Time window | T/7D vsP (default 7D vs prior 7D, real-time on the headline tile). |
| Alert trigger | < 92%, sentiment key decline_rate (inverse). PayPal benchmarks 92-96% success for healthy merchants, lower than Stripe (94-97%) because of the higher-risk traffic mix. |
| 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 consumer-electronics brand running PayPal as the secondary checkout option (Stripe is primary, ~75% of revenue). PayPal carries the international + younger-demographic mix. The 7-day window covers 06 Apr 26 to 12 Apr 26. T00 (payment) rows in the window:| transaction_status | Count | What happened |
|---|---|---|
| S (success) | 1,140 | Payment authorised and captured cleanly |
| D (denied) | 78 | Issuer-side decline (insufficient funds, fraud rule, expired card) OR PayPal-side denial (risk model) |
| F (failed) | 14 | Network error, gateway timeout, 3DS abandoned by buyer |
| P (pending) | 22 | 14 eCheque clearing (~3 business days) + 8 risk-review holds |
| V (reversed) | 2 | Buyer-cancelled within auth window |
| T (in-transit) | 4 | Authorised but not yet captured |
- 90.5% is below the 92% alert threshold. A finance-team ping fires. The biggest contributors are the 78 denials (6.2% of attempts) and the 22 pending (1.7%). If the 22 pending all resolve to S over the next 3 days, the rate retroactively climbs to about 92.2% (1,162 ÷ 1,260) and the alert resolves itself. Watch PP Pending Rate for context before reacting.
- PayPal’s “denied” includes both PayPal-side and bank-side declines. The 78 D rows mix PayPal’s own risk-model rejections (typically labelled
denied_by_riskintransaction_subject) with issuer-side declines on PayPal-bridged card payments (typicallyinstrument_declined,insufficient_funds,payer_authentication_required). Open PP Decline Event Codes to see which dominates; PayPal-side denials are tunable via the merchant’s PayPal Risk settings, issuer-side aren’t. - Compare against Stripe. If the same merchant’s Stripe success rate is sitting at 96%, the 5.5-point gap is normal because PayPal carries the higher-risk slice. If the gap is larger than ~7 points, look at the traffic mix: a recent international-targeted ad campaign or a Black Friday flash sale drives more guest checkouts through PayPal, which pulls success down without the merchant doing anything wrong.
Sibling cards merchants should reference together
| Card | Why pair it with PP Success Rate |
|---|---|
| PP Decline Rate | The arithmetic complement. Success + decline + pending + voided + in-transit = 100%. If success drops, decline usually rose; check there first. |
| PP Pending Rate | Pending payments drag this card down. High pending = suppressed apparent success rate; resolve over time. |
| PP Decline Event Codes | The “why” behind the decline component. Bank-side vs PayPal-side, recoverable vs hard. |
| PP Recoverable Declines | Of the declines, which ones could you recover via dunning or alternate-funding-source prompts? |
| PP Retry Success Rate | Of customers who declined and retried, how many made it through? |
| PP Payment Health Score | This card is the 35%-weight component. The composite gives the CFO single-number; this gives the operator the lever. |
| PP Decline Rate by Card Country | Geographic decompose. Some countries decline 2-3x the global average and are tunable via PayPal Risk settings. |
| Stripe Success Rate (twin) | The Stripe twin. Cross-platform CFOs run both side-by-side; PayPal typically 2-5 points lower. |
Reconciling against the vendor’s own dashboard
Where to look in PayPal Business: PayPal Business does not surface a single “success rate” tile, but you can derive it from these screens:- Activity → All Transactions, filter to “Payments received” and check the status breakdown count for the same date range.
- Reports → Activity download, CSV export, count rows where Status = “Completed” against the total payment-attempt rows.
- Resolution Center → Cases for context on what’s flowing through after capture (not the success rate itself).
- “Approved transactions” on PayPal’s PYMNTS / RisQ partner dashboards uses a different denominator (excludes pending entirely).
- The merchant Center “Sales summary” tile shows count of completed payments only, no denominator, no rate.
- “Account approval rate” on PayPal Business → Reports is the seller-onboarding approval rate, not transaction success.
| Reason | Direction of divergence | What to do |
|---|---|---|
| Page cap (10,000 transactions per call). High-volume merchants doing > 10k attempts in a single 31-day window will see truncated denominators. | Either direction depending on the truncated mix | Use shorter windows; the 7D headline rarely caps. |
| Time zone. PayPal Business uses your account-configured timezone; Vortex IQ uses UTC. Boundary-day transactions shift between days. | Boundary-day drift | Compare equal date ranges accounting for tz offset, or use 7D / 30D where the drift averages out. |
| Pending refresh lag. eCheque / SEPA / hold-for-review transactions stay in P for days. PayPal Business reflects state-at-now; Vortex IQ reflects state-at-last-sync. | Vortex IQ may be lower for the most recent 24-72 hours | Wait for next refresh. |
| Event-code interpretation drift. Older T00 sub-codes have evolved over time. Most engines treat any T00 prefix as “payment attempt”; PayPal Business has finer granularity (some niche sub-codes are excluded from their internal “success rate” calculation). | Tiny drift on long historical windows | Compare equal short windows; differences usually < 0.5 percentage points. |
| Seller-protection eligibility refresh. Doesn’t affect success rate directly but PayPal sometimes retroactively re-classifies a transaction (e.g. flagging it as “review” after the fact). | Rare, < 0.1% | No action needed. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
pp_success_rate ↔ stripe.stripe_success_rate | PayPal typically 2-5 percentage points lower than Stripe for the same merchant. | PayPal’s traffic mix carries more international + younger-demographic + bank-funded payers, all of whom decline more often. A larger gap (> 7 points) suggests a PayPal Risk setting issue or a regional-decline cluster, not a benchmark problem. |
pp_success_rate ↔ commerce platform “checkout completion rate” | No direct equality, success rate is a payment-stage filter, completion rate spans cart → confirmation. | Use PP XC Decline vs Funnel to overlay decline spikes on funnel drops. |
Known limitations / merchant FAQs
Why is my PayPal success rate lower than my Stripe success rate? PayPal carries more high-risk traffic than Stripe. Buyers without credit cards (younger US demographics, international guests in regions where PayPal is dominant, customers using PayPal’s “guest checkout” rather than logging in) skew higher decline. A 2-5 percentage-point gap between PayPal and Stripe is normal and expected; a 7+ point gap suggests a tunable issue (PayPal Risk settings too aggressive, a regional decline cluster, or a bad-traffic ad campaign). What does “denied” mean for PayPal? Is that a card decline? PayPal’sD (denied) is a catch-all that includes both PayPal-side denials AND bank-side issuer declines for card payments routed through PayPal. PayPal acts as an intermediary; from the merchant view the distinction is usually irrelevant (the customer didn’t pay). For the breakdown see PP Decline Event Codes, transaction_subject carries the underlying reason.
Are eCheque payments counted as “successful” while they’re clearing?
No. eCheque sits in P (pending) for ~3-5 business days while it clears the buyer’s bank. It counts in the denominator (it was an attempt) but not the numerator (not yet successful). When it flips to S it starts contributing to the numerator and the rate retroactively rises. Stores with heavy eCheque mix should expect this card to look depressed for a few days after weekends and holidays.
How is this different from PP Decline Rate?
They’re not exact arithmetic complements because of pending. Success + decline ≠ 100% when there are P / V / T rows in the denominator. Success rate counts only S; decline rate counts only D + F. A store with 90% success and 7% decline has 3% sitting in pending / voided / in-transit.
Why is the alert at 92%, not 95%?
PayPal’s healthy benchmark is 92-96%, lower than Stripe’s 94-97% because of traffic mix. The 92% alert ensures we’re flagging stores that are below their own peer band. Above 92% the rate is acceptable; above 95% is excellent for PayPal.
A risk hold added 8 transactions to “pending” overnight, my success rate dropped, what do I do?
Wait. Risk holds typically resolve in 24-48 hours after PayPal completes its review. If they all resolve to S, the rate snaps back. If a meaningful share resolve to D, it’s worth investigating: a single bad-actor IP attempting many high-value orders, or a sudden rule change in PayPal Risk. Open PP Fraud Velocity for the bad-actor view.
Does PayPal “Late capture” or “Authorisation hold” count?
Late captures are flagged T (in-transit, authorised but not yet captured). They count in the denominator but not the numerator until they’re captured. Most merchants capture within minutes, so this rarely moves the rate. Stores using delayed capture for fraud-review flows will see a small persistent drag here; that’s expected.
My multi-currency PayPal account, does this rate work for me?
Yes. Success rate is a count-based ratio, currency-neutral. Multi-currency PayPal accounts get a single, valid success rate that mixes USD + EUR + GBP attempts arithmetically.
The Visa/Mastercard 1% cap is for disputes, not declines, right?
Correct. Decline rate has no PayPal-imposed cap; if your decline rate spikes you’re losing revenue but you’re not in violation of any threshold. Dispute rate is the one with the regulatory ceiling, see PP Dispute Rate.