Total $ leaked through soft declines that retry / dunning could recover next month.
At a glance
Estimated dollar value of soft-decline revenue that retry / dunning / token-refresh could recover in the next period. The CFO-facing card that converts “we have a 5% decline rate” into “$X is on the table next month if we ship the right ops improvements”. Cross-channel: combines CS soft-decline value with the connected commerce platform’s repurchase rate and an estimated retry-success rate to project recoverable monthly revenue.
| The formula | soft_decline_value × commerce_sibling.avg_repurchase_rate × estimated_retry_success_rate. The three factors compound: how much was soft-declined, how often this customer cohort would normally come back, and how much of that retry-able revenue actually recovers. |
| Soft decline definition | Decline reasons recoverable via merchant action: do_not_honor (203), insufficient_funds (204), expired_card, AVS-mismatch (when not driven by fraud), processing_error. Hard declines (stolen_card, lost_card, pickup_card) are excluded. |
| Soft decline value | Sum of totalAmount for DECLINED transactions where reasonCode is in the soft-decline taxonomy, in the most recent 30D window. Reads from /tss/v2/searches. |
avg_repurchase_rate from commerce sibling | The connected commerce platform’s 30D average for “of customers who failed to complete a purchase, what percentage attempted again within 30 days?” Typical e-commerce: 35-55%; subscription / B2B: 65-85%. |
estimated_retry_success_rate | Reason-code-weighted: expired_card retries via Account Updater succeed 75-85%; insufficient_funds retries on payday-aligned schedule succeed 25-35%; do_not_honor retries via dunning succeed 10-15%; AVS-mismatch retries with re-prompted billing data succeed 40-60%. Blended typical recovery: 18-28%. |
| Required connectors | CyberSource AND a commerce-platform connector for avg_repurchase_rate. The card grays out without a commerce sibling. |
| What it doesn’t count | (1) Hard declines (uncountable). (2) Customers who churned to a competitor (the commerce-side repurchase rate naturally captures this, if the customer never came back, repurchase rate is 0 for them and recoverable value is 0). (3) Disputes and refunds (different revenue-loss bucket). |
| Currency | Single currency at sync time. For multi-currency global merchants, the engine sums per-currency at fixed FX (current period rate) for a single dashboard number, with the per-currency breakdown on hover. |
| Time window | 30D. The card projects “next 30D recoverable” based on the most recent 30D soft-decline volume. |
| Refresh cadence | Daily (this is a trend card, not a real-time pulse). |
| Alert trigger | > $5,000/month. The threshold is intentionally low; even at 50k-$500k/month. |
| Roles | owner, finance, marketing |
Calculation
Calculated automatically from your CyberSource 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 enterprise online retailer running CyberSource for ecommerce + Adobe Commerce for the storefront. The 30-day window covers 14 Mar 26 to 12 Apr 26. Roughly 1.59M transaction attempts, 86,400 declines totalling 88 AOV. The decline-reason breakdown (filtered to soft declines only):| Reason | Count | Declined value | Retry success rate (estimated) | Recoverable value |
|---|---|---|---|---|
do_not_honor (203) | 35,400 | $3.11M | 12% (dunning) | $373k |
insufficient_funds (204) | 23,300 | $2.05M | 30% (payday-aligned retry) | $615k |
| AVS mismatch (recoverable subset) | 8,400 | $0.74M | 50% (re-prompt) | $370k |
expired_card | 7,800 | $0.69M | 80% (Account Updater) | $552k |
| Other soft (CVV-format, processing_error) | 2,100 | $0.18M | 25% | $45k |
| Total soft declines | 77,000 | $6.77M | (blended) | $1,955k recoverable IF retried |
- **820k against $140M monthly processing volume = 0.59%, on the lower end (suggesting their current dunning / retry / Account Updater coverage is decent but improvable).
expired_cardis the easiest win. Account Updater (Visa Account Updater, Mastercard ABU) automatically refreshes stored cards when reissued. Enrolment is a one-time setup; recovery rate runs 75-85%. For this merchant the recoverable onexpired_cardalone is 232k/period with no customer-side touchpoint required. This is “money on the table” the merchant can collect by enabling a service.insufficient_fundsis the next-highest-leverage. Payday-aligned retry schedules (typical: +5 days, +10 days, +15 days, with messaging adjusted for SSI / pension cohorts who pay mid-month) recover ~30% of insufficient-funds declines. The merchant’s current retry logic likely retries immediately + 24h after, which is suboptimal for this reason code. Re-tuning the retry schedule alone could recover 258k/period.do_not_honoris the largest bucket but lowest recovery. Issuer-side declines without explanation; recovery via dunning campaigns (“please update your payment method”) runs ~12%. This contributes the least-per-dollar to recoverable revenue but is still meaningful at scale (157k/period).- Cross-channel join is what makes this card honest. Without the commerce-side repurchase rate, the merchant might assume 100% of soft-declined customers would come back if asked, they wouldn’t. The 0.42 multiplier captures the real-world fact that 58% of customers who fail to complete a purchase don’t return; recoverable revenue is calculated against the 42% who do. This is the intellectual honesty that makes the number CFO-grade.
Sibling cards merchants should reference together
| Card | Why pair it with Recoverable Revenue |
|---|---|
| Recoverable Declines (soft) | The soft-decline value side of the formula. |
| Top Decline Reasons | Reason-code breakdown showing which buckets to attack. |
| Top Declining Issuers | Issuer-specific recovery tactics. |
| Decline Retry Success Rate | The retry-success-rate factor in the formula. |
| Dunning Recovery Rate | The dunning-side recovery measurement. |
| Stored-Token Health | Token-refresh recovery on expired_card declines. |
| Revenue at Risk (live) | The forward-looking real-time companion. |
| Decline Spike vs Checkout Funnel Drop | The diagnostic chart for active-incident revenue loss. |
| Adobe Commerce / Shopify / BigCommerce repurchase-rate | The commerce-side factor in the formula. |
Reconciling against the vendor’s own dashboard
Where to look in CyberSource Business Center (EBC2): This card has no direct EBC2 counterpart, it’s a Vortex IQ derived figure that joins CS soft-decline data to the connected commerce platform’s repurchase rate. Operators investigating the underlying CS data should reference:- EBC2 → Reports → Conversion Detail Report, the daily transaction-level dump with reason codes. Sum
totalAmountfiltered to soft-decline reason codes for the soft-decline value side of the formula. - EBC2 → Reports → Decline Reason Report, reason-coded summary if enabled.
- The commerce-platform’s analytics for the repurchase-rate factor (Adobe Analytics, Shopify Analytics, BigCommerce Analytics).
| Reason | Direction | What to do |
|---|---|---|
| Retry-success-rate estimates. Our blended retry-success-rate is calibrated against industry data; merchants with mature dunning infrastructure may exceed it, weak ops may underperform. | Either direction. | Override the manifest estimated_retry_success_rate constants with the merchant’s actual historical recovery data for a calibrated view. |
avg_repurchase_rate window. We use the commerce-side 30D repurchase rate. If the merchant’s repurchase pattern is highly seasonal (holiday spike, Q1 slump), the projection lags. | Either direction. | Lengthen the repurchase window in the manifest if seasonal. |
| Reporting API extraction lag. Reporting v3 overnight batch on the soft-decline value side. | Vortex IQ may lag EBC2 2-6 hours on most-recent day. | Negligible at 30D window. |
| Multi-currency. We sum per-currency at sync-time FX. Bank-side recovery may be against fixed-FX-at-recovery-time. | Tiny drift. | Use per-currency view for finance-grade reporting. |
| Comparison | Expected relationship | When divergence is legitimate |
|---|---|---|
cs_xc_recoverable_revenue ↔ cs_recoverable_declines | The latter is the soft-decline value (factor 1 in the formula); this card layers on the repurchase × retry-success multipliers. Recoverable revenue should be 8-20% of recoverable-declines value (because not every customer comes back and not every retry succeeds). | A ratio outside 8-20% suggests calibration drift in retry-success-rate constants. |
cs_xc_recoverable_revenue ↔ cs_revenue_at_risk_live | The live card is forward-looking for active incidents; this card is post-incident projection. They size differently (live can fire briefly with 500k+ steady-state). | n/a (different time horizons). |
cs_xc_recoverable_revenue ↔ commerce platform’s “abandoned cart recovery revenue” | Different definitions (commerce side is post-cart, our side is post-decline) but should correlate within ±30%. | A larger gap suggests one source is double-counting. |
Known limitations / merchant FAQs
How accurate is the projection? For mature merchants, typically within ±20% of actual recovery the following month. The accuracy depends most on (a) calibration of retry-success-rate constants for the merchant’s specific issuer mix, and (b) seasonality in the repurchase rate. Override the manifest defaults with merchant-specific historical data for calibrated accuracy. Why include only soft declines? Hard declines (stolen_card, lost_card, pickup_card) are uncountable. Retrying them violates Visa / Mastercard rules and can trigger merchant-side enforcement. The card explicitly excludes them from the recoverable-value calculation.
My commerce platform isn’t connected, why is this card grayed out?
The formula needs the commerce-side repurchase rate. Without it, the calculation would assume 100% of customers come back, which is unrealistic and overstates recoverable revenue. Connect Adobe Commerce, BigCommerce, or Shopify to the same Vortex IQ workspace and the card lights up.
The card shows $820k recoverable but my finance team doesn’t trust it. How do I validate?
Run a quarter of the listed actions (Account Updater enrolment, payday-aligned retry, dunning campaign refresh) and measure actual recovered revenue against the projection. Most enterprises find the card lands within 15-25% of actual recovery; treat it as a directional figure for prioritisation, not a precise forecast for accounting.
Why does Account Updater have the highest recovery rate?
Because the underlying problem (expired_card) is mechanically resolvable without customer intervention. The card networks (Visa, Mastercard) maintain a service that automatically refreshes stored credentials when an issuer reissues a card. Enrolment is a one-time merchant setup; the recovery happens silently in the background. Compare to do_not_honor where there’s no mechanical fix, the issuer’s risk model has flagged the transaction and only changing the customer’s behaviour or relationship recovers the value.
Should I expect the recoverable number to grow as I scale?
Yes, linearly with processing volume. Soft-decline value scales with attempts; if processing volume grows 30% YoY, expect this card to grow ~30% YoY too. If the merchant ships ops improvements, the rate of growth slows or reverses (the merchant is now recovering more of the absorbed soft declines, leaving less in the “still recoverable” bucket).
Are 3DS-abandoned transactions counted as recoverable revenue?
No, this card is decline-driven. 3DS-abandoned transactions never authorised so don’t appear in the soft-decline taxonomy. The 3DS-side recoverable revenue lives in 3DS Friction Revenue Loss.
Does dunning recovery work for B2B / corporate cards?
Yes, often better than B2C. B2B / corporate cardholders typically have explicit billing contacts who respond to dunning emails reliably (vs B2C consumers who may ignore them). The recovery rate on B2B do_not_honor and insufficient_funds declines runs 30-45% via direct billing-contact email, vs 10-15% B2C.
My multi-currency global merchant, how does this work?
The card sums recoverable value per-currency at sync-time FX, then aggregates to the dashboard’s display currency for the headline number. The drilldown can show per-currency for finance teams reconciling against bank deposits.
Can I use this card for budgeting / quota-setting?
Yes, with caveats. The number is directional; treat as “if we ship the listed ops improvements, expect $X recovery”. For formal budgeting, use the historical recovery achieved (not the projection) and add growth assumptions. Most enterprise finance teams use this card for prioritising ops initiatives rather than for hard quota commitment.