> ## 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. # Recoverable Revenue (decline-driven), PayPal > Total $ leaked through soft declines that alternate-funding-source prompts / dunning could recover next month. How to read it, why it matters, and how to a... **Metrics type:** [Cross-Platform Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Payment Gateway](/nerve-centre/connectors#connectors-by-type) > 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 formula** | `SUM(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 classification** | Recoverable: `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 matters** | Most operators look at decline rate as a percentage. This card converts it to dollars and segments by recoverability. A merchant with $50k/month in soft declines has a real revenue lever; one with $50k/month in hard declines has noise. Different actions follow. | | **Pending status (P) handling** | NOT 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 practice** | Industry 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 $10k soft-decline pool typically yields $3k-\$5k recovered with disciplined operations. | | **Currency** | **Multi-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](/nerve-centre/kpi-cards/paypal/revenue-by-currency) for the per-currency split). | | **Seller Protection** | Not a factor; this card is decline-stage. | | **Page cap** | 10,000 transactions per call. 30-day windows on stores doing > 10k transactions/month see truncation. | | **Time window** | `30D` (rolling 30 days, matches the dunning-cycle benchmark). | | **Alert trigger** | `> $5k/month`. Below $5k the recovery effort isn't worth the operational overhead; above $5k there's enough recoverable dollars to fund a dunning project. | | **Roles** | owner, 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`: | Subject | Count | Sum (USD) | Recoverable? | Why | | ------------------------------- | ----- | --------- | ------------ | -------------------------------------------------------------------------------------------------------- | | `insufficient_funds` | 187 | \$14,260 | YES | Customer's PayPal balance / linked bank insufficient at time of attempt; usually recovers next paycheque | | `payer_authentication_required` | 142 | \$11,920 | YES | 3DS challenge abandoned; recoverable via Apple Pay / smoother 3DS UX | | `network_error` | 38 | \$3,180 | YES | Transient gateway / network issues; usually recover on retry | | `instrument_declined` | 218 | \$8,640 | NO | Card has a problem (fraud flag, account closed, expired); customer needs to fix | | `expired_card` | 96 | \$2,150 | NO | Without card-update service, requires customer to update PayPal funding source | | `denied_by_risk` | 84 | \$2,690 | NO | PayPal Risk said no; usually correctly (real fraud or marginal cases) | ```text theme={null} 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/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-$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).** 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.** 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.** 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)](/nerve-centre/kpi-cards/paypal/revenue-at-risk)). 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, 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 | Card | Why pair it with PP XC Recoverable Revenue | | ----------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | [PP Recoverable Declines](/nerve-centre/kpi-cards/paypal/recoverable-declines) | The connector-only count view. This card is the cross-platform dollar-weighted forecast. | | [PP Decline Event Codes](/nerve-centre/kpi-cards/paypal/top-decline-event-codes) | Drill into WHY declines are happening. Soft vs hard split is here. | | [PP Retry Success Rate](/nerve-centre/kpi-cards/paypal/decline-retry-success-rate) | Validates 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)](/nerve-centre/kpi-cards/paypal/revenue-at-risk) | The "now" view of decline-driven loss. This card is the "next 30 days" forecast. | | [PP Decline Rate](/nerve-centre/kpi-cards/paypal/decline-failure-rate) | The rate view. Pair to see whether the pool is growing because rates are rising or because volume is rising. | | [PP Dunning Recovery Rate](/nerve-centre/kpi-cards/paypal/dunning-recovery-rate) | Subscription-focused (gated on `has_recurring_charges`). Validates dunning effectiveness for recurring stores. | | [PP XC Decline vs Funnel](/nerve-centre/kpi-cards/paypal/decline-spike-vs-checkout-funnel-drop) | The "is this real customer loss?" filter. If declines aren't hitting real customers, recovery effort has nothing to recover. | | [Stripe Recoverable Revenue (twin)](/nerve-centre/kpi-cards/stripe/recoverable-revenue) | 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: * [PayPal Business → Reports → Activity download](https://business.paypal.com/merchantdata/reportHome), CSV export of declined transactions over the same window. Filter by Status = "Denied" + "Failed", group by Subject for a hand-tally of soft vs hard categories. * [PayPal Business → Activity → All Transactions](https://www.paypal.com/businessmanage/activities), same filter, drill into individual rows to verify subject classification. * [PayPal Business → Notifications](https://www.paypal.com/businessprofile/settings/notifications) for individual decline emails (per-transaction). 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:** | Reason | Direction of divergence | What 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 direction | Cross-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 differ | Use [PP Retry Success Rate](/nerve-centre/kpi-cards/paypal/decline-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 **lower** | Use 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 cases | Compare 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 hours | Wait for next refresh. | **Cross-connector reconciliation:** | Comparison | Expected relationship | When divergence is legitimate | | -------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | `pp_xc_recoverable_revenue` ↔ [`stripe.stripe_xc_recoverable_revenue`](/nerve-centre/kpi-cards/stripe/recoverable-revenue) | The 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_declines`](/nerve-centre/kpi-cards/paypal/recoverable-declines) | Same 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_revenue`](/nerve-centre/kpi-cards/paypal/total-transaction-volume) | Recoverable 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. ***
Documentation cross-reference (for agencies running multiple platforms) The Stripe twin is [`stripe.stripe_xc_recoverable_revenue`](/nerve-centre/kpi-cards/stripe/recoverable-revenue). Same shape (dollar-weighted soft-decline pool over rolling 30 days), different processor. Multi-processor merchants combine both for total recovery budget; PayPal often shows higher 3DS-abandon dollars due to traffic mix.
## 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](/nerve-centre/kpi-cards/paypal/decline-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](/nerve-centre/kpi-cards/paypal/recurring-charge-failure-rate) and [PP Dunning Recovery Rate](/nerve-centre/kpi-cards/paypal/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?** 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](/nerve-centre/kpi-cards/paypal/decline-failure-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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.