Skip to main content
Metrics type: Cross-Platform Metrics • 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).

​
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:
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

​
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: Cross-connector reconciliation: 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.