Customer Payment Retry Recovery Rate

A subscription invoice fails on the first payment attempt, the billing system retries later and some invoices are eventually paid. Customer payment retry recovery rate measures the share of an eligible failed-payment cohort that is successfully collected through an authorised retry process within a declared window.

Define initial failure, since a declined card, network error and incomplete authentication challenge may need different treatment. Stripe documents automated subscription and invoice retries and recovery analytics for failed payments, and Adyen describes automatic retry products for eligible refused recurring transactions.

These are provider capabilities, not permission to charge outside a customer's accepted terms. Choose the denominator carefully, because invoices with a first failure or individual failed attempts produce different rates, so use a cohort of obligations to avoid counting retries as new failures.

Choose the numerator by requiring a final successful payment tied to the same obligation within the recovery window, and set the window, since a seven-day and 30-day rate are different and the observation period and matured cohorts should be published. Keep recent failed invoices without enough follow-up pending rather than forcing them into recovered or unrecovered groups.

Check finality too, because a processor success event can be reversed or disputed later, and define finality at the report cutoff. Check authorisation: a retry must fit the original payment mandate, card-network rules, customer notices and any updated payment method consent, and some refusal codes should not be retried automatically under provider rules.

Watch authentication, since a required challenge may need the customer's direct completion rather than repeated unattended attempts, and avoid harassment, as repeated attempts without suitable spacing or authorisation can harm customers and violate provider rules. Distinguish card update by classifying whether a new authorised payment method supplied by the customer is included in retry recovery.

Check duplicate collection, because two processors or jobs could collect the same invoice and should be reconciled before counting a recovery, and confirm the billing record: if an invoice is paid by bank transfer while retries are underway, stop or reconcile the card attempts before another charge lands, since a paid obligation is not a new collection target. Check cancellations, as an obligation that was voided or refunded should not count as successful recovery by a later payment, and check currency and amount, since a retry that collects the wrong amount is not a clean recovery.

Track partial payments with a separate value-based recovery measure. Segment by cause, since expired card, insufficient funds and technical outage have different remedies, and avoid selection bias by showing eligibility and exclusion reasons when a provider retries only certain failures.

Preserve attempt dates, outcomes and provider reasons, use an audit sample that traces invoice, mandate, attempts, successful charge and customer notification, and pair the rate with the failure rate, because high recovery can coexist with an unusually high initial-failure rate. Send accurate failed-payment notices through the approved customer channel, restore suspended access only under the agreed service rule once payment resolves, and remember that collected cash may not be revenue for the same accounting period and that a successful retry can still incur processor costs, so use the metric to improve legitimate collection and customer continuity, not to maximise charge attempts at any cost.