> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Transaction Success Rate, PayPal > Transaction Success Rate for PayPal stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type) ## 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](/nerve-centre/kpi-cards/paypal/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](/nerve-centre/kpi-cards/paypal/refund-rate), not here. | | **Disputes** | Not a factor. A disputed payment was still successful at capture; disputes count on [PP Dispute Rate](/nerve-centre/kpi-cards/paypal/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 | ```text theme={null} PP Success Rate numerator = 1,140 (status = S) denominator = 1,140 + 78 + 14 + 22 + 2 + 4 = 1,260 (all T00 attempts) = 1,140 ÷ 1,260 × 100 = 90.5% ``` Three things worth noticing: 1. **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](/nerve-centre/kpi-cards/paypal/on-hold-pending-rate) for context before reacting. 2. **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_risk` in `transaction_subject`) with issuer-side declines on PayPal-bridged card payments (typically `instrument_declined`, `insufficient_funds`, `payer_authentication_required`). Open [PP Decline Event Codes](/nerve-centre/kpi-cards/paypal/top-decline-event-codes) to see which dominates; PayPal-side denials are tunable via the merchant's PayPal Risk settings, issuer-side aren't. 3. **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. If next week 5 of those eCheque payments came back as D instead of S, the rate would drop to about 90.1% and stay there. That's the case where the alert reflects a real signal worth investigating. ## Sibling cards merchants should reference together | Card | Why pair it with PP Success Rate | | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | [PP Decline Rate](/nerve-centre/kpi-cards/paypal/decline-failure-rate) | The arithmetic complement. Success + decline + pending + voided + in-transit = 100%. If success drops, decline usually rose; check there first. | | [PP Pending Rate](/nerve-centre/kpi-cards/paypal/on-hold-pending-rate) | Pending payments drag this card down. High pending = suppressed apparent success rate; resolve over time. | | [PP Decline Event Codes](/nerve-centre/kpi-cards/paypal/top-decline-event-codes) | The "why" behind the decline component. Bank-side vs PayPal-side, recoverable vs hard. | | [PP Recoverable Declines](/nerve-centre/kpi-cards/paypal/recoverable-declines) | Of the declines, which ones could you recover via dunning or alternate-funding-source prompts? | | [PP Retry Success Rate](/nerve-centre/kpi-cards/paypal/decline-retry-success-rate) | Of customers who declined and retried, how many made it through? | | [PP Payment Health Score](/nerve-centre/kpi-cards/paypal/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](/nerve-centre/kpi-cards/paypal/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)](/nerve-centre/stripe/stripe_success_rate) | 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](https://www.paypal.com/businessmanage/activities), filter to "Payments received" and check the status breakdown count for the same date range. * [Reports → Activity download](https://business.paypal.com/merchantdata/reportHome), CSV export, count rows where Status = "Completed" against the total payment-attempt rows. * [Resolution Center → Cases](https://www.paypal.com/disputes) for context on what's flowing through after capture (not the success rate itself). Other views that look like this but aren't: * "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. **Why our number may legitimately differ from PayPal Business:** | 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. | **Cross-connector reconciliation:** | Comparison | Expected relationship | When divergence is legitimate | | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `pp_success_rate` ↔ [`stripe.stripe_success_rate`](/nerve-centre/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](/nerve-centre/kpi-cards/paypal/decline-spike-vs-checkout-funnel-drop) to overlay decline spikes on funnel drops. | End-to-end: PP Success Rate is one of four components of [PP Payment Health Score](/nerve-centre/kpi-cards/paypal/payment-health-score). The others are decline rate (×5 amplifier), dispute rate (×50 amplifier), and seller-protection coverage. When the composite drops, success rate is the first place to look (largest contributor for small movements). ***
Documentation cross-reference (for agencies running multiple platforms) The Stripe twin is [`stripe.stripe_success_rate`](/nerve-centre/stripe/stripe_success_rate). Same definition shape (successful charges ÷ total attempts), different processor. Cross-platform CFOs running both should expect PayPal to sit 2-5 points lower than Stripe; that's structural, not a defect.
## 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's `D` (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](/nerve-centre/kpi-cards/paypal/top-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](/nerve-centre/kpi-cards/paypal/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](/nerve-centre/kpi-cards/paypal/dispute-rate). *** ### Tracked live in Vortex IQ Nerve Centre *Transaction Success Rate* is one of hundreds of KPI pulses Vortex IQ tracks across PayPal and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.