Skip to main content
Card class: Cross-Channel • Category: Payment Gateway
Total $ leaked through soft declines that alternate-funding-source prompts / dunning could recover next month.

​
At a glance

Dollar value of PayPal soft-decline revenue from the trailing 30 days that you could realistically recover next month with dunning, alternate-funding-source prompts, or simple checkout improvements. The “money on the table” view, isolating recoverable declines (insufficient_funds, payer_authentication_required, network_error) from hard declines (instrument_declined, expired_card, denied_by_risk).
The formulaSUM(transaction_amount.value) WHERE event_code STARTS T00 AND status IN [D, F] AND subject MATCHES (insufficient_funds OR payer_authentication_required OR payer_cannot_pay OR network_error). Dollar-weighted soft-decline value over the rolling 30-day window.
Soft-decline classificationRecoverable: insufficient_funds (retry next paycheque), payer_authentication_required (3DS abandon, recoverable via Apple Pay / simpler 3DS UX), payer_cannot_pay (PayPal balance insufficient, recoverable via dunning), network_error (transient, recoverable via retry). NOT recoverable: instrument_declined (card has a problem), expired_card (without card-update service), denied_by_risk (PayPal Risk said no, often correctly), restricted_country, account_hold.
Why this card mattersMost operators look at decline rate as a percentage. This card converts it to dollars and segments by recoverability. A merchant with 50k/monthinsoftdeclineshasarealrevenuelever;onewith50k/month in soft declines has a real revenue lever; one with 50k/month in hard declines has noise. Different actions follow.
Pending status (P) handlingNOT counted. Pending payments aren’t yet declines; they may yet succeed.
Refunds (T11)NOT counted. Refunds are completed customer returns; they were never declines.
Disputes (T19)NOT counted. Disputes are post-success customer escalations; this card is decline-stage only.
What “recovery” looks like in practiceIndustry benchmarks: dunning recovers 25-40% of insufficient_funds (multiple retries over 7-14 days hit a paycheque); Apple Pay / Google Pay alternatives recover 30-50% of 3DS abandons; smarter retry logic recovers 60-80% of network_error transients. So a 10ksoft−declinepooltypicallyyields10k soft-decline pool typically yields 3k-$5k recovered with disciplined operations.
CurrencyMulti-currency without FX. Dollar values are summed in their original currency. A multi-currency PayPal account gets a cleaned per-currency view (use PP Revenue by Currency for the per-currency split).
Seller ProtectionNot a factor; this card is decline-stage.
Page cap10,000 transactions per call. 30-day windows on stores doing > 10k transactions/month see truncation.
Time window30D (rolling 30 days, matches the dunning-cycle benchmark).
Alert trigger> $5k/month. Below 5ktherecoveryeffortisn′tworththeoperationaloverhead;above5k the recovery effort isn't worth the operational overhead; above 5k there’s enough recoverable dollars to fund a dunning project.
Rolesowner, finance, marketing

​
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. 30-day window: 14 Mar 26 to 12 Apr 26. PayPal carries the higher-risk traffic mix. Total T00 declined value over the window: $42,840 Breakdown by transaction_subject:
SubjectCountSum (USD)Recoverable?Why
insufficient_funds187$14,260YESCustomer’s PayPal balance / linked bank insufficient at time of attempt; usually recovers next paycheque
payer_authentication_required142$11,920YES3DS challenge abandoned; recoverable via Apple Pay / smoother 3DS UX
network_error38$3,180YESTransient gateway / network issues; usually recover on retry
instrument_declined218$8,640NOCard has a problem (fraud flag, account closed, expired); customer needs to fix
expired_card96$2,150NOWithout card-update service, requires customer to update PayPal funding source
denied_by_risk84$2,690NOPayPal Risk said no; usually correctly (real fraud or marginal cases)
PP XC Recoverable Revenue
  recoverable subset = insufficient_funds + payer_authentication_required + network_error
                     = $14,260 + $11,920 + $3,180
                     = $29,360 / 30 days

  hard-loss subset = instrument_declined + expired_card + denied_by_risk
                   = $8,640 + $2,150 + $2,690
                   = $13,480 / 30 days
The card lights up at $29,360. Six things worth noticing:
  1. 29,360/monthisameaningfulrevenuelever,wellabovethe29,360/month is a meaningful revenue lever, well above the 5k alert. At industry-standard recovery rates (25-40% of soft declines), this merchant could realistically capture 7,000−7,000-11,500 of additional monthly revenue with disciplined dunning + checkout improvements. That’s a six-figure annual lift.
  2. **insufficient_funds is the largest soft-decline bucket (14,260).∗∗Thisisthetextbookdunningtarget.Setupa3−attemptretryschedule(T+1day,T+3days,T+7days).Industrybenchmarks:30−4014,260).** This is the textbook dunning target. Set up a 3-attempt retry schedule (T+1 day, T+3 days, T+7 days). Industry benchmarks: 30-40% of these recover within 14 days. Expected recovery: 4,000-$5,700/month.
  3. **payer_authentication_required is 11,920.∗∗ThisisaUXproblem.Thecustomerhitthe3DSchallengefromtheirbankandgaveupbeforecompleting.Twolevers:(a)offerApplePay/GooglePayasalternatives(no3DSrequiredforfirst−timewallet−fundedtransactions);(b)workwithPayPalonsmoother3DS2challenges(biometricpromptsonmobilebeatOTP−by−SMS).Expectedrecovery:30−5011,920.** This is a UX problem. The customer hit the 3DS challenge from their bank and gave up before completing. Two levers: (a) offer Apple Pay / Google Pay as alternatives (no 3DS required for first-time wallet-funded transactions); (b) work with PayPal on smoother 3DS2 challenges (biometric prompts on mobile beat OTP-by-SMS). Expected recovery: 30-50% with proper UX, 3,500-$6,000/month.
  4. **network_error is 3,180.∗∗Easymoney.Retrylogicontransienterrorsrecovers60−803,180.** Easy money. Retry logic on transient errors recovers 60-80% with no customer-facing change. Expected recovery: 2,000-$2,500/month, mostly automatic.
  5. The hard-loss subset ($13,480) is NOT in this card’s headline. Those declines are real customer-side problems (card has issue, PayPal Risk caught fraud) and aren’t recoverable through dunning or UX changes. Pretending they’re recoverable would mis-target the operations team.
  6. The recovery isn’t immediate, it’s “next month-ish”. This card is a forecast of what could be recovered with sustained effort over the next 30-60 days. It’s not the live revenue-at-risk view (that’s PP Revenue at Risk (live)). Treat it as a strategic budget input: how much should I invest in dunning ops next quarter?
If next month’s recoverable pool grows to 40k,themerchantmightjustifyadedicateddunningspecialistorthird−partyrecoverytool(Stunning,ChurnBuster,etc.,thoughmostaresubscription−billing−focused).Ifitshrinksbelow40k, the merchant might justify a dedicated dunning specialist or third-party recovery tool (Stunning, Churn Buster, etc., though most are subscription-billing-focused). If it shrinks below 5k, dunning effort isn’t worth the overhead.

​
Sibling cards merchants should reference together

CardWhy pair it with PP XC Recoverable Revenue
PP Recoverable DeclinesThe connector-only count view. This card is the cross-channel dollar-weighted forecast.
PP Decline Event CodesDrill into WHY declines are happening. Soft vs hard split is here.
PP Retry Success RateValidates the recovery assumption. If retry success is high, the recoverable pool is real; if low, your retry logic isn’t working.
PP Revenue at Risk (live)The “now” view of decline-driven loss. This card is the “next 30 days” forecast.
PP Decline RateThe rate view. Pair to see whether the pool is growing because rates are rising or because volume is rising.
PP Dunning Recovery RateSubscription-focused (gated on has_recurring_charges). Validates dunning effectiveness for recurring stores.
PP XC Decline vs FunnelThe “is this real customer loss?” filter. If declines aren’t hitting real customers, recovery effort has nothing to recover.
Stripe Recoverable Revenue (twin)Stripe-side equivalent. Multi-processor merchants combine both for total recovery budget.

​
Reconciling against the vendor’s own dashboard

Where to look in PayPal Business: PayPal Business does NOT offer a native “recoverable revenue” calculation; this is a Vortex IQ-derived classification on top of PayPal’s decline data. The closest PayPal-side views for cross-checking: Other views that look like this but aren’t:
  • “Lost transactions” tile in PayPal Business is all declines, not the recoverable subset.
  • “Revenue forecasting” reports (where available) project successful revenue trends, not decline-driven recovery.
  • Some third-party dunning tools surface “recoverable revenue” but use proprietary classifications; their numbers won’t match ours unless they use the same subject taxonomy.
Why our number may legitimately differ from a hand-classification:
ReasonDirection of divergenceWhat to do
Subject classification taxonomy. PayPal’s transaction_subject field has many sub-values; we group some niche subjects into “soft” and “hard” buckets that PayPal documentation doesn’t formally split. Edge cases may be classified differently.Either directionCross-check by exporting the activity CSV and grouping by subject; the dominant categories should match.
Recovery rate assumption. The headline number is the recoverable pool, not the recovered amount. Industry-standard recovery rates (25-40% of soft declines) are heuristic; your actual recovery depends on your dunning sophistication.Forecast vs reality may differUse PP Retry Success Rate to calibrate against your actual recovery experience.
Page cap (10,000 transactions per call). 30-day windows on heavy-volume stores truncate.Vortex IQ may be lowerUse the warehouse-backed view (rolling out separately).
Time zone. PayPal Business uses your account-configured timezone; Vortex IQ uses UTC.Boundary-day effects on month-edge casesCompare equal date ranges.
Pending refresh lag. Pending payments resolving to D enter the recoverable pool only after the next refresh.Vortex IQ may be lower for the most recent 24-72 hoursWait for next refresh.
Cross-connector reconciliation:
ComparisonExpected relationshipWhen divergence is legitimate
pp_xc_recoverable_revenue ↔ stripe.stripe_xc_recoverable_revenueThe Stripe twin. Two independent processors with different soft-decline mixes. PayPal usually has more payer_authentication_required (3DS abandons on bank-funded card payments) than Stripe.A PayPal-only spike usually means a PayPal-specific 3DS issue. Combined view = total dunning addressable revenue.
pp_xc_recoverable_revenue ↔ pp_recoverable_declinesSame logic, this card is dollar-weighted, that one is count-weighted. Should move together.Divergence (one rising, the other flat) means high-value declines are increasing, focus on the largest individual cases.
pp_xc_recoverable_revenue ↔ pp_total_revenueRecoverable pool typically runs 5-15% of gross revenue.If recoverable pool > 20% of revenue, your decline rate is concerning AND your soft-decline mix is heavy, urgent dunning project worth funding.
This card is Vortex IQ-derived. PayPal does not publish a recoverable-revenue forecast; the soft vs hard classification is proprietary to Vortex IQ but maps directly onto PayPal’s transaction_subject taxonomy.

​
Known limitations / merchant FAQs

Is this number “guaranteed recoverable” or “potentially recoverable”? Potentially. The headline is the recoverable pool, the soft-decline value that disciplined operations could capture. Actual recovery depends on your dunning sophistication, retry timing, and customer-side circumstances. Industry benchmarks suggest 25-40% of insufficient_funds is recoverable; 30-50% of 3DS abandons; 60-80% of network errors. Use PP Retry Success Rate to calibrate against your actual experience. Why doesn’t denied_by_risk count as recoverable? Because PayPal Risk usually catches real fraud or marginal cases that should be declined. Recovering a denied_by_risk decline often means recovering revenue from a fraudster, which then becomes a chargeback in 30-60 days, costing you the order value PLUS a chargeback fee PLUS counting toward your 1.0% Visa cap. False positives exist (legitimate customers getting risk-flagged), but tuning PayPal Risk settings is the answer there, not retry / dunning. What’s the practical operations playbook to capture this revenue? Three projects in priority order:
  1. Insufficient_funds dunning ($14,260 in our worked example): set up a 3-attempt retry schedule (T+1, T+3, T+7 days). Use PayPal’s /v1/payments/payment endpoint to re-attempt; pair with email reminder sequence (“we tried again, your payment didn’t go through”). Expected lift: 30-40% of pool.
  2. 3DS abandon recovery ($11,920 in worked example): offer Apple Pay and Google Pay as wallet-funded alternatives at the PayPal-decline page. First-time wallet-funded transactions skip 3DS challenges. Expected lift: 30-50% of pool.
  3. Network error retry ($3,180 in worked example): automatic single-retry within 30 seconds on network_error responses. Almost zero customer-facing change. Expected lift: 60-80% of pool.
My subscription store, does this card account for failed renewal payments? Subscriptions are a separate flow. Failed renewal payments on PayPal Subscriptions show in PP Recurring Failure Rate and PP Dunning Recovery Rate. This card is one-shot payment failures only. For subscription stores, both are real revenue levers. **Why is the alert threshold 5k/month?∗∗Below5k/month?** Below 5k/month the operational overhead of dunning + retry infrastructure (engineering time, monitoring, customer-comms) outweighs the recovery value. Above $5k there’s enough at stake to justify a project. The threshold is a heuristic, scale up for high-margin businesses (subscription / luxury) where each recovered dollar is high LTV; scale down for low-margin volume businesses where recovery is gravy. Does this card account for hard-loss revenue I might still want to track? Not in the headline. Hard-loss declines (instrument_declined, expired_card, denied_by_risk) total $13,480/month in the worked example, real revenue gone, but not recoverable through normal operations. They’re tracked on PP Decline Rate as part of the overall decline pool. If you want to chase hard-loss recovery, the levers are: card-update services (reduces expired_card), checkout-experience review (reduces some instrument_declined drop-offs at the entry stage), and PayPal Risk tuning (reduces false-positive denied_by_risk). Does this card include refunds or disputes? No. Refunds (T11) are completed customer returns; disputes (T19) are post-success escalations. Both are out-of-scope, this card is decline-stage soft-decline forecast only. Multi-currency PayPal account, does the card work? Yes, but currencies are summed without FX. A multi-currency account sees something like “$15k + €4k + £2k” recoverable. Each currency’s dunning effort is best targeted in that currency’s market (US team for USD, EU team for EUR), so the unconverted view is actually operationally useful. Why isn’t expired_card recoverable, even with PayPal’s account-update service? PayPal does have a card-account-update programme (Visa Account Updater, Mastercard Automatic Billing Updater) that can refresh expired cards without customer action, but it’s only available to merchants who explicitly enable it and pay for it. Without that programme, expired_card requires the customer to log into PayPal and update their funding source, which is a customer-initiated recovery that doesn’t fit the “merchant operations recovery” framing of this card. If you have the account-update programme enabled, you can move expired_card from hard-loss to recoverable on this card via a manifest tweak. Stripe’s twin shows higher recoverable revenue than mine, am I underperforming? Or you have a healthier traffic mix. PayPal carries more 3DS-abandoning international shoppers and bank-funded buyers; Stripe carries more card-on-file desktop shoppers. Stripe’s card_declined bucket is often a different shape than PayPal’s instrument_declined. The two pools are not directly comparable; what matters is your store’s direction over time. Rising recoverable pool means declining customer experience or rising adverse-traffic mix.

​
Tracked live in Vortex IQ Nerve Centre

Recoverable Revenue (decline-driven) 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 or book a demo to see this metric running on your own data.