Payments as a multistage optimization problem

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

Stripe applies optimizations at every stage, from personalizing the checkout form, to deciding whether to request a 3DS challenge or an exemption, to formatting the fields of an authorization 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 minimizes 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 optimizes 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%.

Personalizing 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 behavior, 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 optimizations—dynamic payment method ordering, Adaptive Pricing, and saved credentials—drive an average revenue increase of 11.9% for businesses using the Optimized Checkout Suite.

The network effect of saved credentials

Even the best personalized 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 recognizes 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 maximizing 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 modeling 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 maximizes 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 optimizing 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 behavior 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 behavior: 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 authorized payment volume and more than $2.5 million in savings for businesses each month.

Fingerprint time-out optimization

The decision tree determines which authentication path a transaction takes. But even within a given path, there are further optimizations. 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 optimizations 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 optimization has increased global authorized payment volume by over $1 billion annually.

4. Authorization

Once a transaction has been evaluated for fraud and, where appropriate, authenticated, it’s submitted to the issuing bank for authorization. This is yet another opportunity to influence authorization rates, fraud, and processing costs (for IC+ businesses). Stripe does this across three broad categories: choosing how to route the payment, making the authorization 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.

Authorization messages

The content of the ISO 8583 message the issuer receives, and the context surrounding it, significantly affects whether a payment is approved. Stripe optimizes 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 authorization. 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 behavior across their portfolio. But they don’t see what Stripe sees: the behavior 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 optimization isn’t simply enabling these tools. Network tokens generally improve authorization rates and reduce costs, but there are pockets of traffic where they don’t—issuers with poor token support where they hurt authorization rates, or transaction patterns where they increase fraud. Stripe learns where tokens help and where they don’t, selectively applying them to maximize 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 Authorization Boost—spanning routing, message and issuer optimizations, 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 authorization isn’t the end of the optimization surface. Between authorization and the business receiving funds, Stripe optimizes for two things: reducing the cost of settling the transaction and catching fraud that only becomes visible after authorization.

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 authorization 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 authorization 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-authorized 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 program with escalating penalties. Disputes are expensive in isolation and even more expensive in aggregate.

Like every other stage in this guide, disputes present an optimization problem. But the structure is different. Upstream, the objective is to maximize expected profit on each transaction in real time. Here, the objective is to minimize the total cost of disputes across three possible responses: deflecting the dispute at the point of inquiry, 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 recognize 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 programs.

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

Representment

For disputes that do proceed to a chargeback, the optimization problem shifts from prevention to evidence assembly. Which pieces of evidence, in which format, maximize 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 optimization

The optimizations in this guide span the full payment lifecycle, and they compound. Better fraud scoring can lead to fewer fraudulent transactions reaching authorization. Stronger authentication means more transactions carry liability shift. And post-authorization 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 optimization.

Compounding predictions

The more outcomes Stripe can predict accurately, the better every downstream decision becomes. We’re investing in modeling refund probability at charge time to optimize 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 optimization becomes most visible.

Richer objective functions

Stripe’s optimization 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 authorization optimizer should all know this, and they should adjust accordingly.

Some businesses care narrowly about fraudulent disputes; others want to minimize all risk, including first-party fraud and policy abuse. Some are willing to accept higher fraud in exchange for maximizing 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 optimize 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 optimizations 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 synthesizing 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 authorization rates, fraud, processing costs, and interchange. Every week, new ideas are tested, and the ones that succeed ship automatically to businesses on Stripe. Each optimization 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 optimization surface only gets wider. Contact us; we’d love to collaborate.