Stripe's AI optimisation paper, read from the failed payments side

Stripe published a white paper called Optimising payments at scale: how Stripe applies AI across the payment lifecycle. It is the clearest public account yet of how Stripe thinks about payments: not as an authorisation rate problem, but as a chain of decisions, each with its own models, each feeding the next.

FlyCode is a payment recovery platform built on top of Stripe, and our CEO leads the Stripe Tel Aviv community. So we read the paper twice. Once as a Stripe partner, nodding along. And once as a company whose customers lose revenue in a stage the paper's six stages don't name: the moment a renewal fails.

This is the second read. The paper's framework is right. It also applies, almost line by line, to what happens after a subscription payment is declined, and that is the part of the lifecycle most subscription and AI businesses are still running on fixed schedules and a single retry rule.

Stripe's argument: payments is a multistage optimisation problem

The paper's core claim is that a transaction passes through six stages, each a separate decision point, and that the decisions are interdependent. A fraud model that blocks too hard protects the dispute rate and kills conversion. An authentication policy that removes all friction raises declines. Stripe's answer is a model per stage, trained on network data, with gains that compound as a payment moves downstream.

Two things stand out. First, every stage is treated as its own problem with its own objective function, not as a tuning knob on authorisation. Second, almost all of it is on-session: a customer is at a checkout, and Stripe has one attempt to get the payment through at the lowest cost and risk.

Retries get a paragraph inside the authorisation section. For off-session subscription payments, Stripe says it retries through intelligent dunning with models that predict when funds are likely to be available, rather than on a fixed schedule. That is the right principle. It is also the only line in the paper about the part of the lifecycle where recurring revenue actually lives.

The stage the paper doesn't cover: the failed renewal

For a subscription or usage-based business, the paper's lifecycle describes the first payment well and the next thirty-six badly. Most of a subscription company's volume is off-session renewals on a card that worked last month. Nothing from the checkout stage applies. There is no cart to personalise, no payment method to reorder, no Link session to recognise. There is no cardholder present to challenge with 3DS. The customer doesn't even know a payment is being attempted.

The failures look different too. On-session declines are dominated by fraud and risk signals. Off-session renewal failures are dominated by insufficient funds and generic declines. Across the subscription businesses we work with, insufficient funds alone is often 50 to 70 percent of failed renewals. The card is real, the customer wants the product, and the issuer said no because the balance was wrong on the day the invoice ran.

And the economics are different. A lost checkout is one transaction. A lost renewal is the rest of that customer's lifetime, plus the cost of winning them back after their access was cut. Involuntary churn from failed payments is the largest churn source most subscription businesses never measure, because it hides in the gap between the billing system and the CRM.

So the failed renewal has everything Stripe's paper says qualifies a stage for its own optimisation: a distinct set of signals, a distinct set of possible interventions, a distinct objective function, and a decision that depends on everything upstream. It is a seventh stage. It just isn't in the diagram.

Stripe's own principles, applied to payment recovery

The useful thing about the paper is that each principle Stripe lays out for on-session payments transfers directly to the failed renewal. Here are the five that matter most.

1. Distinct predictions per failure mode

Stripe doesn't have one fraud score. It keeps separate predictions for whether a card is stolen, whether a dispute is likely, whether an early fraud warning will fire, and whether Stripe itself thinks the payment is bad, because each one calls for a different response.

Recovery needs the same discipline. Insufficient funds, do not honor, issuer unavailable, and a credential that has gone stale are four different problems. One wants a retry timed to when money arrives. One wants a different message or a different route. One wants to wait an hour. One wants a new card, and no retry schedule on earth will fix it. A single retry rule applied to all four is the recovery equivalent of blocking every payment Radar scores above 50.

2. Choose the intervention by expected profit, not by rule

Stripe's most interesting section treats fraud intervention as a contextual bandit: block, CAPTCHA, request 3DS, or let it through, each with an estimated effect on conversion, cost and fraud, and the model picks whichever maximises expected profit for that transaction, that issuer, that business.

Recovery has a richer action space than that. Retry now. Retry on the predicted payday. Email. SMS. In-app prompt. Send the customer a one-tap update-card flow. Pause and preserve access. Downgrade. Stop entirely because the customer has already cancelled in their head and every further attempt costs you an authorisation fee and goodwill. Each action has a cost and a success rate that vary by customer, plan and decline reason. The right answer is the one with the highest expected recovered lifetime value, and it changes per attempt as the signals update.

3. Retry with more assurance when the issuer asks for it

Stripe found that a risk-related decline isn't always final. Retrying with 3DS, where the decline code and issuer suggest the bank wanted cardholder presence, recovers over $1B a year. The point is not 3DS. The point is that a decline is information about what the issuer wants, and the retry should answer it.

Off-session, the cardholder isn't there to challenge. But the same logic holds. A generic decline on a renewal often means the issuer wants a signal that this is a real customer, not a bot cycling cards. The recovery equivalent of the 3DS retry is bringing the customer back on-session: a link, a confirmation, an authenticated flow, timed and worded so they actually complete it. Blind retries can't do that. Nothing in the paper suggests Stripe is doing it off-session either.

4. Richer objective functions, per business

In the closing section Stripe argues that a business selling digital goods at 60 percent margin should tolerate a very different fraud level than one selling physical goods at 8 percent, and that the fraud model, the authentication engine and the authorisation optimiser should all know it.

This is the strongest argument in the paper for per-merchant recovery models. An AI company with heavy compute costs behind a $200 a month plan should pursue a failed renewal harder, sooner and across more channels than a $9 newsletter. A customer in month 18 is worth a different recovery policy than one in month 2. A business running a promotion wants to tolerate more retry cost for a week. A single network-wide retry model, however well trained, cannot represent any of that. The objective function has to be the merchant's own economics.

5. Apply credential tools selectively, and know what they don't touch

Stripe is candid that network tokens and card account updater are not uniformly good. There are issuers with poor token support and traffic patterns where tokenisation hurts approval, so Stripe applies them where they help and withholds them where they don't.

Two lessons for recovery. First, if your answer to failed payments is "we have CAU and network tokens switched on," Stripe's own paper says that is not a complete answer even on the credential problem. Second, and more important, credential tools address stale credentials only. They do nothing for insufficient funds and generic declines, which is where the bulk of subscription revenue is lost. The stage that handles those has to be built separately.

Where the compounding ends up

Stripe's closing argument is that every new prediction improves every downstream decision. Better fraud scoring means fewer bad payments reach authorisation. Stronger authentication means more payments carry liability shift. Post-authorisation signals reverse risky charges before they become disputes.

Follow that chain one step further and it lands on the failed renewal. By the time a subscription payment is declined, it has passed through Stripe's checkout, fraud, authentication, authorisation and clearing models. The recovery decision inherits all of that: the decline code, the issuer's behaviour, the credential state, the risk score, the customer's full payment history with this business. Recovery is the last downstream decision in the lifecycle, and the one with the most accumulated signal to work with.

It is also the decision with the longest horizon. Every upstream stage is optimising a single transaction. Recovery is optimising whether a customer stays. A 3.8 percent lift in first-attempt acceptance is real money. So is turning a 60 percent recovery rate on failed renewals into an 80 percent one, except that the second number compounds every month the customer stays subscribed.

Stripe optimises the attempt. Someone has to optimise the recovery.

None of this is a criticism of Stripe. The paper describes the best on-session payment optimisation in the industry, and every subscription business should want all of it switched on. If the first attempt can be approved, Stripe is more likely than anyone to approve it.

The argument is about what the paper's own framework implies. If payments really is a multistage problem, where each stage deserves its own models, its own interventions and the merchant's own objective function, then the failed renewal cannot be the one stage that runs on a fixed schedule and a generic retry rule. It needs the same treatment: distinct predictions per decline reason, an intervention chosen by expected lifetime value, a way to bring the customer back on-session when the issuer wants assurance, and a model that knows this merchant's margins and this customer's tenure.

That is what FlyCode is. We sit on top of Stripe, take the signal Stripe's lifecycle produces, and run the seventh stage: per-merchant recovery models trained on Visa and Mastercard network data, deciding for each failed payment what to do, when, and through which channel. Stripe gets the first attempt right. We get the customer back when it fails.

Stripe's paper ends by inviting businesses that can provide richer inputs to get in touch. We'd extend the same invitation from the other side of the decline. If you run a subscription or AI business on Stripe and you want to know what your failed renewals are actually costing you, we will show you, on your own data, before you commit to anything.

Source: Stripe, Optimising payments at scale: how Stripe applies AI across the payment lifecycle (white paper, 2026). All Stripe figures above are Stripe's own and describe on-session optimisation; none of them measure failed-payment recovery.