Retrying failed recurring payments by the reason they failed

1The problem

A subscription business collects most of its revenue without the customer present. When a charge fails, the customer has not chosen to leave; the payment has simply not gone through. That makes failed recurring charges one of the most recoverable kinds of churn, and also one of the easiest to mishandle.

Declines are common enough to matter even when the customer is present: among US shoppers who abandoned an online checkout for a reason other than browsing, 10 percent said their card was declined¹. For an unattended renewal there is no one at the screen to try another card, so what the system does next decides the outcome.

The common approach is a fixed schedule: retry after one day, three days, a week, then cancel. It treats every failure alike. But a card reported stolen will never succeed, a charge that needs the customer to authenticate cannot succeed without them, and a charge that failed for lack of funds may well succeed on payday. One schedule for all of them wastes attempts on the first two and may give up too early on the third.

2Four classes of failure

We propose sorting each failure, at the moment it happens, into one of four classes, each with its own action.

Class	Typical signals	Action	Retry?
Final	Lost or stolen card, incorrect card number, closed account, no payment method on file	Ask the customer for a new payment method	No
Needs the customer	The issuer requires authentication	Bring the customer back to authenticate the charge	Not without the customer
Temporary	Insufficient funds, issuer unavailable, processing error	Retry on a schedule, at times more likely to succeed	Yes, within a limit
Suspected fraud	High fraud score, signs of card testing, issuer fraud signal	Stop, review, contact the customer through a known channel	No

Source: our design. Final and temporary classes follow the processor rules in²; the needs the customer class follows^{3, 4}.

2.1Final

Some decline codes mean the card can never be charged again. One major processor's documentation states that it does not retry a payment automatically when no payment method is available or when the issuer returns a hard decline code, such as an incorrect number or a lost or stolen card, and that the invoice cannot be paid without a new payment method². Every retry after such a decline is wasted and, repeated across many customers, can look to issuers like abuse. The only useful action is to ask the customer, by email and in the account page, for a new method.

2.2Needs the customer

In the European Economic Area, electronic payments are subject to strong customer authentication under the PSD2 rules, which the regulatory technical standards specify along with the conditions for exemptions³. With EMV 3-D Secure, many transactions are approved without friction, but for higher-risk transactions the issuer can require the customer to authenticate with a one-time passcode, biometrics or another method⁴. When an issuer answers a renewal with a request for authentication, no retry on its own will succeed. The system should send the customer a link to a page where they can complete the authentication, and only count the failure as churn if they do not.

2.3Temporary

Insufficient funds and short-lived issuer or network problems are the cases a retry exists for. The same processor's recommended default is 8 attempts within 2 weeks, with timing chosen from signals that include the time of day, in the customer's local time zone, at which payments tend to succeed². A design should keep two limits: a maximum number of attempts and a maximum period, after which the failure moves to the final class and the customer is asked to update their method.

2.4Suspected fraud

A recurring charge can also fail because the card is being used fraudulently, for example after a stolen card was used to start a subscription. Retrying such a charge helps no one. Statistical fraud detection uses supervised models trained on labeled fraud and unsupervised methods that flag unusual behavior, and in both the costs of a missed fraud and of a false alarm are unequal and must be set explicitly⁵. A comparison of methods on real card transaction data found that random forests performed well overall against logistic regression and support vector machines, while noting that the right choice depends on the measure and the operating point⁶.

One detail makes the threshold trustworthy. Fraud is rare, so training sets are often balanced by discarding most legitimate transactions. That shifts the model's scores: a score of 0.5 after undersampling does not mean a 50 percent chance of fraud. The shift can be corrected with a closed form adjustment that depends on the sampling rate, so that the calibrated score is again a probability and a threshold set on it means what it says⁷.

3Order of checks

The classes are checked in a fixed order: fraud first, then final, then needs the customer, then temporary. A charge that is both suspected fraud and declined for lack of funds is treated as fraud. A charge that is declined as final is not retried even if the decline also says the issuer was unavailable. Every class change is logged with its reason, so a customer service agent can see why a subscription was paused.

4Limitations

The decline codes that place a failure in each class differ between processors and networks and change over time; a real system needs a maintained mapping, which we do not give here. We cite one processor's published defaults as an example, not as the only sound policy. The authentication rules we describe are those of the European Economic Area; other markets have their own. We report no recovery rates of our own.

5Conclusion

A failed recurring charge should be classified before it is retried. Final failures need a new payment method, failures that need the customer need the customer, temporary failures need a bounded, well-timed retry and suspected fraud needs a stop. Sorting first and acting by class spends retries only where they can work.