In subscription payment stacks, involuntary churn from failed recurring payments accounts for 20-40% of total customer churn and costs subscription businesses approximately 9% of annual revenue on average. Intelligent retry systems that evaluate 20+ transaction parameters recover approximately a significant portion of those failures.

TL;DR

• Involuntary churn = 20–40% of subscription churn, costing businesses ~9% of annual revenue
• Recovery underperformance is a classification problem. Failures fall into three recoverable categories - hard declines (e.g. false positives from issuer fraud filters), soft declines (e.g. issuer/PSP/network mismatches), and insufficient funds (e.g. user spending, payroll behavior). Each needs a different retry strategy.
• Juspay Hyperswitch Revenue Recovery sits between the subscription platforms like Recurly, Chargebee, Stripe Billing and the PSP. It has 3 main aspects
• Predictor: An ML-based system that scores success probability over the billing cycle.
• Decider: An RL-based system that optimizes the retry schedule against retry budget.
• Core payment features: account updater, partial authorization recovery, multi-card retries, multiple PSP retries and payment method-based Invoice queuing.
• Setup is three dashboard steps, no code changes to the merchant's billing platform or PSP integration.

Why involuntary churn is harder to recover than it looks

Involuntary churn: Customer loss caused by payment failures rather than deliberate cancellation. Industry research places passive churn from failed payments at 20–40% of total subscription churn, with only 5% of subscribers who churn this way ever resubscribing.

Some failures are not recoverable at all like closed accounts, deliberately cancelled cards, accounts with no Account Updater coverage. These are out of scope for any retry layer; they exit the recovery pipeline immediately and are excluded from retry budget consumption.

The recoverable failures fall into three categories with meaningfully different root causes and retry strategies:

The challenge is the error signal beneath the failure. Card networks issue more than 100 distinct decline codes. Payment processors interpret and translate those codes differently across their systems. When issuers cannot properly categorize an error into a network code, they default to the catch-all "Do not honor" response - a code that gives the retry system no actionable information about whether the failure is a hard, soft, or insufficient-funds case.

The hard-decline category in particular is more recoverable than most merchants realize. A standard retry setup classifies fraud-flagged declines as non-retriable and never attempts recovery. An intelligent retry layer learns from historical data which fraud-flagged declines on similar issuer patterns turned out to be false positives, scores each new decline against that pattern, and triggers retries only on the high-probability false positives, leaving genuine hard declines untouched.

How Revenue Recovery is built: Predictor + Decider

Revenue Recovery: Juspay Hyperswitch's revenue recovery module for failed recurring payments. It listens to webhooks from both your payment processors like Stripe, Adyen, Worldpay and others and the subscription billing platforms like Recurly, Chargebee, and Stripe Billing. The revenue recovery module then classifies failures, predicts retry success probability, optimizes the retry schedule against the merchant's retry budget, executes retries across any connected PSP, and writes successful outcomes back to the billing platform before the dunning cycle advances.

Revenue Recovery sits between the merchant's subscription management layer and their payment connector layer. The architecture is configuration-agnostic on either side. It works with SaaS billing platforms (Recurly, Chargebee, Stripe Billing), open-source billing systems, or custom in-house billing implementations, and connects to any combination of PSPs, payment orchestrators, or custom payment solutions.

At its core, Revenue Recovery has two components Predictor and Decider that work in a feedback loop to determine when and how to retry each failed payment.

The Predictor (ML-based)

The Predictor is a machine learning model that predicts the likelihood of a payment succeeding at a given future time, based on 20+ transaction parameters. The parameters cluster into five mental groups:

• Customer behavior signals - historical spending behavior, position in the billing cycle, prior retry outcomes for this customer
• Issuer signals - issuer success rate patterns by time-of-day, day-of-month, and BIN; issuer-specific recovery curves after a decline
• Error signals - error-based success rate patterns: which decline codes recover when retried after which intervals
• Payment method signals - credit vs. debit, card network, primary vs. secondary saved card
• Geographic signals - billing city, state, country; regional issuer behavior patterns

The Predictor's output is a success probability for a candidate retry time, a probability surface across future times.

The Decider (RL-based)

The Decider is a reinforcement learning model that consumes the Predictor's probabilities and optimizes the retry schedule against the merchant's retry budget. When a failure event arrives, the Decider asks the Predictor: "if I retry at time T₁, T₂, T₃ … out to 30 days, 60 days, 180 days, 365 days, what's the success probability for each?"

Critically, the Decider operates over the billing cycle horizon. For a monthly subscriber, the Decider budgets retries across ~30 days. For a yearly subscriber, ~365 days. The retry budget is configured by the merchant and caps the total attempts. The Decider's job is to allocate that budget to maximize expected recovery.

The exploration loop is the difference between a single-model retry and a budgeted schedule optimization. A single-model approach outputs one retry timing per failure. The Decider considers a distribution of candidate times across the cycle, evaluates each against the Predictor, and outputs a schedule that balances early high-probability windows against later high-probability windows within the retry budget.

When Revenue Recovery is successful with the transaction or the retry budget is exhausted without recovery, the payment hands-off to the billing layer. Recurly, Chargebee, or Stripe Billing. The two systems are sequential - Revenue Recovery owns the first recovery window, billing owns the success tracking, escalation and stop service aspects.

Which payment features amplify recovery

The Predictor and Decider determine when and whether to retry. The execution itself draws on a set of payment features that increase the surface area for recovery, turning failures that a single-shot retry would miss into recoveries.

Hard Decline Retries. Automatically retries invoices that fail with hard decline codes, within the merchant's configured retry budget. The system identifies false positives by matching each decline against historical data on similar issuer patterns - same issuer, BIN range, and transaction characteristics that produced false positives in the past. The high-probability false positives are retried; genuine hard declines exit the recovery pipeline without consuming retry budget.

Partial Authorization Recovery. When a customer's account has insufficient funds for the full invoice amount but partial funds are available, capture the partial amount to complete payment. Particularly relevant for prepaid cards and accounts in the insufficient-funds state. The customer pays what they can now, and the remainder follows on the next retry cycle.

Automatic Account Updater. Automatically updates stored payment methods when cards are replaced due to them being expired, lost, stolen, or reissued. Integrates with card-network-level account update services so that a customer whose card was reissued does not need to manually update their payment method in the billing platform. This addresses the dependency on the customer to resolve the failure mode and removes the customer from the loop entirely.

Multi-Card Retries. When a customer has multiple saved payment methods, retries failed invoices across alternative cards. A primary credit card declines, the retry attempts a secondary debit card on file. The Decider treats each saved payment method as an additional retry candidate, expanding the option space without expanding the customer-facing friction.

Payment Method-Based Invoice Queuing. Groups all pending invoices by payment method. When a customer has multiple failed invoices on the same card, the system queues the invoices, retries the primary, and once the primary succeeds, processes all queued invoices on that payment method together. This prevents redundant retries from consuming retry budget and from triggering issuer rate-limit flags.

These features are not separate from the Predictor/Decider logic, they are the levers the Decider can pull. A retry schedule that includes "try alternate saved card on day-3" is only possible if Multi-Card Retries is enabled.

Configuring Revenue Recovery alongside existing subscription engine

Revenue Recovery is configured through the Hyperswitch dashboard — no code changes required on the merchant's billing platform or PSP integration. Setup completes in three steps:

Payment processor credentials and webhooks. Connect PSP credentials in the Hyperswitch dashboard and configure Hyperswitch's webhook endpoint with each payment processor. Revenue Recovery begins receiving real-time decline events from the PSP side.

Subscription platform credentials and webhooks. Connect Recurly, Chargebee, or Stripe Billing credentials and configure Revenue Recovery's webhook endpoint within the billing platform. This enables both directions of the integration: Revenue Recovery receives failure events from the billing side and writes successful recovery outcomes back to the subscription platform.

Recovery plan parameters. Configure the recovery plan on the business profile:

• Retry budget: Maximum retry attempts per failed payment before handoff to dunning
• Start retry after: Delay between failure event and first retry
• Subscription-cycle configuration: Different retry horizons for monthly, 6-month, and yearly subscriptions.
• Payment-feature toggles: Enable Hard Decline Retries, Partial Authorization Recovery, Account Updater, Multi-Card Retries, and Invoice Queuing

After configuration, Revenue Recovery monitors all incoming failure webhooks automatically. The first retry fires within the configured window.

The key configuration dependency: both Step 1 and Step 2 must be complete for the write-back to function. Revenue Recovery can execute retries with only the PSP webhook configured but without the billing platform credential, it cannot write successful outcomes back to Recurly, Chargebee, or Stripe Billing. The subscription platform would remain in a failed state despite a successful payment recovery.

The merchant's existing dunning configuration in Recurly, Chargebee, or Stripe Billing does not need to change. Revenue Recovery operates upstream of dunning. When Revenue Recovery succeeds, dunning never fires for that payment. When Revenue Recovery's budget is exhausted, dunning fires exactly as configured.