Payments as a multistage optimisation problem

Optimising payments is often treated as an authorisation rate problem: send a well-formed message to the issuer and maximise the chance it comes back approved. In practice, the optimisation surface is much wider. A payment passes through several stages: checkout, fraud evaluation, authentication, authorisation, clearing and disputes – and each presents opportunities to increase conversion, reduce cost and prevent fraud.

Stripe applies optimisations at every stage, from personalising the checkout form, to deciding whether to request a 3DS challenge or an exemption, to formatting the fields of an authorisation message. The right intervention at one stage often depends on what happened at another: a fraud model that blocks too aggressively will improve dispute rates but hurt conversion, and an authentication strategy that minimises friction without accounting for risk appetite will produce more declines and disputes downstream. The best results come from accounting for these interactions and building systems at each stage that are aware of their impact on every other.

This guide describes how Stripe optimises payments across these stages, delivering as much as $27 billion per year in incremental revenue, helping reduce fraud by 38% on average, and lowering processing costs by up to 2.8% for Stripe businesses.

1. Checkout

The majority of revenue that businesses lose is never declined by an issuer. Instead, it's abandoned at checkout.

A customer in the Netherlands who doesn't see iDEAL might abandon their cart. A customer in Brazil who sees prices in USD might not complete a purchase because they're unsure if or what FX fees might appear on their statement. A customer considering a large purchase without the option to split payments with a buy now, pay later provider might simply decide the transaction is not worth it. These aren't edge cases; showing even one payment method that isn't relevant to a customer can reduce conversion by up to 15%.

Personalising the checkout form

The optimal checkout is different for every transaction. The right set of payment methods and their ordering, the currency, which form fields to display, and whether to initiate a fraud intervention all depend on who the customer is, where they are, what they're buying and what device they're using. A static configuration can't keep up.

Stripe treats this as a series of real-time decisions. Consider payment method selection. The classic approach is to pick a configuration and stick with it, but the optimal set of payment methods changes as customer behaviour, regional preferences and method availability shift. This is what's known as a multiarmed bandit problem, named after a gambler facing a row of slot machines with unknown payout rates. You need to keep trying new options to learn which performs best, while still making money from what's already working. Stripe's AI models, trained on billions of transactions, navigate this trade-off continuously, incorporating on-session signals such as device type, browser locale and payment method availability, alongside network-level signals such as the preferred payment methods used by similar businesses.

Currency is also a particularly high-leverage dimension. Most customers prefer to pay in their local currency, and Stripe's Adaptive Pricing uses an AI model that predicts a customer's true currency preference – helping drive a 17.8% increase in cross-border revenue.

Taken together, these optimisations – dynamic payment method ordering, Adaptive Pricing and saved credentials – drive an average revenue increase of 11.9% for businesses using the Optimised Checkout Suite.

The network effect of saved credentials

Even the best personalised checkout still requires the customer to type in a card number. For returning customers, this is unnecessary friction. Link, a digital wallet built by Stripe, eliminates it. If a customer has a saved payment method with Link, the system recognises them – either through cookies, account details, or other authentication methods. The customer can then pay faster on any business with Link enabled on the Stripe network – even one they've never visited before. This is a network effect in the literal sense. Each new business that adopts Link makes the experience better for customers on every other business, and vice versa. Link now has more than 200 million saved payment methods, and businesses with a large returning customer base have seen returning user conversion increase by an average of 14%.

2. Fraud evaluation

Once a payment is attempted, the problem changes. The question is no longer whether the customer will buy, but whether the transaction is legitimate. There is a greater than 92% chance that Stripe has seen the card before. But Stripe's network extends well beyond cards. Across millions of businesses, our network observes correlations between payment methods, devices and transaction patterns that help distinguish legitimate activity from fraud. Stripe's fraud models use these aggregate signals to assess the risk of each transaction.

Evaluating risk

Card testing requires different models and signals than stolen card fraud, where a real human is attempting a purchase with someone else's payment method. For stolen card fraud alone, Stripe maintains several distinct predictions: is this card likely stolen? Will this transaction result in a fraudulent dispute? Will it trigger an early fraud warning from the card network? And even if the bank is unlikely to dispute it, does Stripe believe the transaction is fraudulent? Each prediction has different implications for what should happen next.

The models draw on three layers of signal. The first is the Stripe network itself: aggregate patterns observed across more than a trillion dollars in annual payment volume, spanning millions of businesses. The second is external data, such as compromised card credentials ingested from across the internet. The third is business-specific: through learned business embeddings, Stripe Radar captures what normal looks like for a given business while still benefiting from the global model's breadth.

The shape of these predictions is also expanding. Historically, fraud meant stolen cards and card testing. But a customer who abusively signs up for thousands of free or discounted trials will likely never convert, and the trial itself carries direct costs to the business. Today, a customer on a usage-based billing plan might rack up charges they have no intention of paying. This isn't a traditional form of payment fraud, but it requires the same discipline: distinct predictions, trained on the right signals, used to drive the right response.

These predictions might be used differently depending on a business's risk appetite. A deeply risk-averse business can block all predicted fraud, regardless of whether the issuer would dispute it. A business focused on maximising conversion can choose to block only transactions likely to result in fraudulent disputes. A business approaching a card brand monitoring threshold can block both fraudulent disputes and transactions likely to trigger early fraud warnings.

Choosing the right intervention

A risk assessment is a prediction of how dangerous a transaction is, but it doesn't tell you what to do about it. The simplest response is to block the transaction, but a false positive means lost revenue. The question is whether there's a less costly way to mitigate the risk.

Stripe treats intervention selection as a contextual bandit problem, choosing from a set of actions and modelling the expected outcome of each. Some interventions are familiar, such as presenting a CAPTCHA challenge to filter bots, or requesting 3DS. These are a few examples from a broader set of interventions, each affecting conversion, fraud and cost differently, and the impact varies by context. Many US issuers, for example, have low 3DS completion rates: adding a 3DS challenge on those issuers might not reduce fraud, but it definitely hurts conversion.

Stripe models this. We select between these interventions by estimating expected profit. For each candidate intervention, Stripe estimates how the conversion probability, fraud probability and cost change depending on which is selected. A transaction routed through a 3DS challenge often has a near-zero probability of a fraudulent dispute but a measurably lower probability of conversion. The model selects the intervention that maximises expected profit given the transaction's risk profile, the business's risk preferences and the specific issuer and payment method involved.

Across these predictions and interventions, Radar reduces fraud by 38% on average for businesses on Stripe while blocking fewer than 0.05% of legitimate transactions.

3. Authentication

The previous section described how Stripe selects interventions, including whether to trigger 3DS authentication at all. This section goes deeper into what happens when 3DS is the chosen path, because the decision doesn't end there. 3DS is a family of options with very different implications for conversion, cost and compliance, and the right choice depends on the transaction's risk, the regulatory context and the specific issuer involved.

We're optimising across three competing objectives simultaneously: regulatory compliance, fraud prevention and conversion. The right answer is to make a different decision for every transaction, using everything you know about its risk, the customer's device and the issuer's behaviour to choose between a full challenge, a frictionless exemption, a behind-the-scenes data exchange, or no authentication at all.

Exemptions and challenges

Stripe's authentication engine uses the fraud scores from Radar to route eligible transactions through the lowest-friction path available. Low-risk transactions below the regulatory threshold get a low-value exemption, skipping authentication entirely. Above the threshold, the engine requests a TRA exemption, where applicable. When the risk is moderate, it uses Data Only authentication, sharing device fingerprints and transaction context with the issuer behind the scenes, so the customer never sees a challenge. A full 3DS challenge is reserved for cases where the risk warrants it or no exemption is available.

The fraud score is the branching variable at every node, and the engine adapts to issuer behaviour: some issuers approve Data Only flows reliably while others don't, and Stripe routes accordingly. Across European volume, Data Only authentication alone produces $147 million in incremental authorised payment volume and more than $2.5 million in savings for businesses each month.

Fingerprint time-out optimisation

The decision tree determines which authentication path a transaction takes. But even within a given path, there are further optimisations. Consider fingerprinting, the optional first step of any 3DS flow. 3DS fingerprinting collects device and browser information through an iframe to help the issuing bank assess transaction risk. It's an optional step in the protocol, supported by roughly 68% of transactions on Stripe, and it can improve conversion when successful. But the process takes varying amounts of time on different devices, and the added latency can cause authentication to fail entirely.

This is the kind of problem that rewards precise measurement. Stripe ran a multivariant A/B test to determine the ideal amount of time to wait for fingerprinting before proceeding without it. This is a delicate balance: wait too long and you lose customers to latency; skip too quickly and you lose the information that would have improved the issuer's decision. The optimal time-out varies by device and issuer, and finding it recovered more than $39 million in payments since March 2025.

3DS as a retry strategy

Most processors treat a risk-related decline as final. One of the more counterintuitive optimisations we explored is that for these declines, adding authentication after the fact can recover the payment.

3DS authentication adds latency, introduces friction and carries its own processing cost. So the question isn't simply "would 3DS help?" but "does the expected value of retrying with 3DS exceed the cost of attempting it?" Stripe models this directly based on a specific decline reason, issuer, card type and transaction profile. Some decline codes are nearly deterministic (the card is genuinely invalid, and no amount of authentication will change that). Others signal that the issuer wants more assurance that the cardholder is present, and a 3DS challenge provides exactly that. The model learns which codes, on which issuers, respond to authentication and routes retries only where the expected recovery justifies the cost. This optimisation has increased global authorised payment volume by over $1 billion annually.

4. Authorisation

Once a transaction has been evaluated for fraud and, where appropriate, authenticated, it's submitted to the issuing bank for authorisation. This is yet another opportunity to influence authorisation rates, fraud and processing costs (for IC+ businesses). Stripe does this across three broad categories: choosing how to route the payment, making the authorisation message as effective as possible, and recovering payments that fail on the first attempt.

Routing

Stripe can route payments across multiple gateways and rails, such as regional debit networks, and can select the most cost-effective path on first attempt. For many payments, alternative rails actually hurt conversion, so the models learn where these routes reduce cost without sacrificing acceptance. On retry, the calculus changes: if a signature debit transaction is declined, routing the retry through debit rails can recover it.

Authorisation messages

The content of the ISO 8583 message the issuer receives, and the context surrounding it, significantly affects whether a payment is approved. Stripe optimises this on several fronts.

The first is the message itself. Stripe continuously experiments with the formatting and content of ISO fields, testing changes across issuers, card types and geographies. The volume of the Stripe network means that even experiments with small expected effect sizes reach statistical significance within hours, and Stripe runs dozens every week. Successful experiments are often surprisingly small: for example, a minor change to which transactions are submitted for authorisation. The effect is difficult for any single business to distinguish from noise, but at Stripe's scale, it's measurable with high confidence and worth tens of millions of dollars annually in aggregate. These improvements compound.

The second is sharing fraud risk signals with issuers. Issuers have their own view of risk, often based on a cardholder's spending history, account standing and behaviour across their portfolio. But they don't see what Stripe sees: the behaviour of the customer across other payment methods, or the fraud patterns associated with a given email address or shipping address. Stripe built the Enhanced Issuer Network – direct Radar data-sharing integrations with issuers, including Capital One, Discover and American Express – to bridge this gap. When Stripe believes a transaction is low-risk, sharing that signal helps the issuer avoid false declines it might otherwise trigger on its own.

The third is card credentials. Stale credentials are a significant source of unnecessary declines. Stripe uses network tokens and card account updater to keep credentials current, but the optimisation isn't simply enabling these tools. Network tokens generally improve authorisation rates and reduce costs, but there are pockets of traffic where they don't – issuers with poor token support where they hurt authorisation rates, or transaction patterns where they increase fraud. Stripe learns where tokens help and where they don't, selectively applying them to maximise their benefit.

Retries

Some declines are recoverable. A soft decline based on insufficient funds or temporary issuer unavailability might succeed on a second attempt with different timing or routing. Stripe retries synchronously at charge time, selecting an alternative gateway or adjusting the message based on the decline reason. For off-session payments such as subscriptions, Stripe retries asynchronously through intelligent dunning, using models that predict when funds are most likely to be available rather than retrying on a fixed schedule.

In aggregate, Stripe's Authorisation Boost – spanning routing, message and issuer optimisations, and credential management – increases acceptance rates by 2.2% on average and reduces processing costs by up to 2.8% for IC+ businesses.

5. Clearing

A successful authorisation isn't the end of the optimisation surface. Between authorisation and the business receiving funds, Stripe optimises for two things: reducing the cost of settling the transaction and catching fraud that only becomes visible after authorisation.

Reducing costs

Refunding a settled transaction is expensive. On US debit, there are no interchange fee returns at all, making a post-settlement refund up to 24x more costly than reversing the authorisation before clearing. Stripe predicts which transactions are likely to be refunded shortly after capture and delays their clearing for a short period of time accordingly, converting refunds into reversals. Nearly 25% of refunds occur within the first 48 hours, which is why even a brief, targeted delay for high-probability refunds can meaningfully reduce costs.

When minor changes to a transaction's value are expected, like a tip added to a base charge, Stripe holds the authorisation open and captures the full amount once rather than incurring a second set of fees. And for businesses processing commercial card transactions, submitting detailed product and tax data at clearing time can qualify transactions for lower interchange rates through programs such as Visa's Commercial Enhanced Data Program.

Reducing fraud

In the hours after a transaction completes, Stripe continues to observe signals from other transactions across the network, such as a card used in a confirmed fraud attack elsewhere or a device fingerprint newly linked to a pattern of disputes. These signals can materially change the risk picture of an already-authorised payment.

This creates an asymmetry that works against fraudulent actors: every subsequent attempt from a stolen card puts their previous successful transactions at risk. A bad actor who makes one successful purchase and then tries to extract more value gives Stripe additional signal to catch them, and reverse the earlier charge before it results in a chargeback. When risk signals escalate, Stripe can proactively refund or reverse the charge before it results in a dispute.

6. Disputes

Despite everything upstream, some transactions will be disputed. The business pays a dispute fee, absorbs the operational cost of responding, and if the dispute is lost, the business forfeits the transaction amount. If a business's dispute rate exceeds the card networks' thresholds, the business can be put in a monitoring programme with escalating penalties. Disputes are expensive in isolation and even more expensive in aggregate.

Like every other stage in this guide, disputes present an optimisation problem. But the structure is different. Upstream, the objective is to maximise expected profit on each transaction in real time. Here, the objective is to minimise the total cost of disputes across three possible responses: deflecting the dispute at the point of enquiry, resolving it before it is filed, or fighting it after the fact. Each response has a different cost, a different success rate, and a different effect on the business's standing with the card networks. The right strategy depends on the dispute amount, reason code, the business's proximity to monitoring thresholds, and the strength of the available evidence.

Deflection

Stripe integrates with Visa's Verifi and Mastercard's Ethoca to deliver enhanced transaction details to issuers (purchase descriptions, business information, and transaction metadata) that help the cardholder recognise the charge before a dispute is filed. In cases where Stripe can establish proof of a prior relationship between the cardholder and the business (matching customer identifiers, IP address, or shipping address from previous successful transactions), the data meets the requirements for what Visa calls Compelling Evidence (CE) 3.0. When CE3.0 criteria are met, the issuer is required to block the dispute from being filed at all. The deflection rate depends on data availability, but for businesses with repeat customers, it can help prevent fraudulent disputes from ever entering the system.

Resolution

Our Verifi and Ethoca integrations also allow businesses to resolve disputes before they formally enter the chargeback process. When a cardholder initiates a dispute, these networks send an alert to Stripe before the chargeback is filed. Businesses can configure rules to automatically refund qualifying disputes (for example, all "product not received" disputes under $10). The refund resolves the dispute instantly, the business avoids the chargeback fee, and most importantly, the card networks don't count it toward the business's dispute rate, which helps keep the business out of monitoring programmes.

These deflection and resolution tools have reduced dispute rates by 51% on average across fraud and non-fraud reason codes.

Representment

For disputes that do proceed to a chargeback, the optimisation problem shifts from prevention to evidence assembly. Which pieces of evidence, in which format, maximise the probability of winning a given dispute? The answer varies by reason code, issuer and transaction type, and any individual business likely sees too few disputes to learn these patterns.

Stripe's Smart Disputes system is trained on dispute outcomes across millions of transactions, giving it enough signal to identify what works. The system learns which combinations are most effective in each context. It automatically assembles and submits a tailored evidence packet, and businesses can supplement it with their own evidence before submission. Early adopters have won 13% more chargebacks on average.

The future of payment optimisation

The optimisations in this guide span the full payment lifecycle, and they compound. Better fraud scoring can lead to fewer fraudulent transactions reaching authorisation. Stronger authentication means more transactions carry liability shift. And post-authorisation interventions reverse high-risk charges before they can be disputed. By the time a transaction reaches the dispute stage, it has already passed through multiple layers of optimisation.

Compounding predictions

The more outcomes Stripe can predict accurately, the better every downstream decision becomes. We're investing in modelling refund probability at charge time to optimise clearing timing. We're building better predictions of expected network costs, so that routing models can make more precise cost-accuracy trade-offs.

Each new prediction improves the entire payment lifecycle. This is where the compounding effect of multistage optimisation becomes most visible.

Richer objective functions

Stripe's optimisation models are only as good as their understanding of what a business actually cares about. Today, tools like Radar's risk preferences let businesses express their fraud tolerance. But this is a starting point. A business selling digital goods at 60% margins should tolerate a very different level of fraud risk than a business selling physical goods at 8% margins, and some businesses sell both. The fraud model, the authentication engine, and the authorisation optimiser should all know this, and they should adjust accordingly.

Some businesses care narrowly about fraudulent disputes; others want to minimise all risk, including first-party fraud and policy abuse. Some are willing to accept higher fraud in exchange for maximising conversion during a promotional period. The more precisely Stripe can capture a business's actual economics and priorities, the better every model in the pipeline can optimise on the business's behalf.

Bigger models

Stripe's models are getting both wider and deeper. We recently scaled our fraud model's training dataset from roughly 800 million to more than 11 billion historical transactions, covering a much broader range of geographies, products and fraud patterns. Our deep neural networks can learn from this volume of data in ways that traditional models cannot, and we're pushing them further. We're building multitask models that predict several outcomes simultaneously, which lets the models share representations across tasks, so that signal from one prediction strengthens another.

Agents for unstructured problems

Most of the optimisations in this guide operate on structured data such as transaction amounts, decline codes, device fingerprints and fraud scores. But some of the highest-value problems in payments involve unstructured information. Dispute representment is a natural fit, which requires assembling a winning evidence packet, reading network rules (Visa and Mastercard each publish hundreds of pages of dispute regulations that are subject to change regularly), matching the right evidence type to the specific reason code and issuer, and synthesising transaction data into a coherent narrative. We're building agents that can interpret network regulations directly and can combine that understanding with AI models that predict which evidence is most persuasive for a given dispute scenario, handling cases that rule-based systems can't.

Experimentation

Beyond any individual initiative, Stripe runs experiments continuously across the entire payment journey. Every experiment in the payment lifecycle is instrumented to measure impact on authorisation rates, fraud, processing costs and interchange. Every week, new ideas are tested and the ones that succeed ship automatically to businesses on Stripe. Each optimisation in this guide was discovered, tested and deployed through this process, and the pace of experimentation has increased by more than 4x over the past 2 years.

And for businesses that want to go further by sharing margin data, tuning risk preferences, providing richer product information and testing new ideas, the optimisation surface only gets wider. Contact us; we'd love to collaborate.