Payments as a multistage optimization problem

Payment optimization is often framed as an authorization rate problem, but authorization is only one component of a larger system. Each transaction moves through checkout, fraud evaluation, authentication, authorization, clearing, and disputes, with distinct decision points at each stage. These decisions are interdependent: a fraud model that blocks too aggressively might reduce dispute rates but also reduce conversion, while an authentication strategy that minimizes friction without accounting for risk will increase declines and disputes.

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. Across the payment lifecycle, these optimizations deliver as much as $27 billion per year in incremental revenue, reduce fraud by 38% on average, and lower processing costs by up to 2.8% for Stripe businesses.

1. Checkout

Most failed transactions never reach authorization; they’re lost 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 hesitate because the final cost with FX fees is uncertain. A customer considering a large purchase without the option to split payments with a buy now, pay later provider might decide not to buy at all.

Personalizing the checkout form

The optimal checkout is different for every transaction. The right set of payment methods, their ordering, the presented currency, the required form fields to display, and the decision 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.

Stripe treats these as a series of real-time decisions. Payment method selection is one example: Stripe’s AI models, trained on billions of transactions, select which payment methods to display per checkout session according to on-session signals such as device type, browser locale, and payment method availability, alongside network-level signals such as which payment methods perform best for similar businesses and customers. And because the optimal set of payment methods changes as customer behavior, regional preferences, and payment method availability shift, the system also continuously explores the performance of new configurations.

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

The network effect of saved credentials

Even an optimized checkout still creates friction if the customer has to type in a card number. For returning customers, that friction is unnecessary. Link, a digital wallet built by Stripe, eliminates it. If a customer has a saved payment method with Link, Stripe can recognize them using cookies, account details, or other authentication signals. The customer can then check out faster at any business with Link enabled, including those they’ve never visited before.

Each new business that adopts Link improves the experience for customers across the network, and each additional credential improves the value of Link for businesses. 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%.

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

2. Fraud evaluation

After a payment attempt, the objective shifts from conversion to evaluating whether the transaction is legitimate, using AI that trains on data across millions of businesses and over a trillion dollars in annual payment volume. For card payments, there is a greater than 92% chance that Stripe has seen a given card before. And Stripe’s network extends well beyond cards: we observe 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

Different fraud modes require different models and signals. Card testing, for example, has a different signature than stolen card fraud, where a real person attempts to purchase something using someone else’s payment method. Even within stolen card fraud, Stripe maintains several distinct predictions: whether the card is likely stolen, whether the transaction is likely to result in a fraudulent dispute, whether it is likely to trigger an early fraud warning from the card network, and whether Stripe independently assesses the transaction as fraudulent—even if the bank is unlikely to dispute it.

Stripe Radar’s fraud detection models draw on three layers of signal. The first is the Stripe network itself: aggregate patterns across all the businesses and transactions on Stripe. The second is external data, including compromised card credentials ingested from across the internet. Third, they use business-specific signals: Radar learns patterns unique to each business and uses them to compare new activity against that business’s usual behavior.

Businesses can use these predictions differently depending on their risk appetite. A highly risk-averse business can choose to 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.

The scope of these predictions is expanding. Historically, fraud models focused on stolen cards and card testing. But new patterns of fraud and abuse are emerging, especially as bad actors increasingly target AI services with high compute costs by exploiting free trials or racking up usage bills that go unpaid. These aren’t traditional forms of payment fraud, but they require the same discipline to address: distinct predictions, trained on the right signals, used to drive the right response.

Choosing the right intervention

Risk scoring does not specify an intervention policy. The simplest response is to block a risky 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—such as presenting a CAPTCHA challenge, or requesting 3DS—and modeling the expected outcome of each. The impact varies by context: many US issuers, for example, have low 3DS completion rates, and adding a 3DS challenge on those issuers might not reduce fraud, but will definitely hurt conversion.

For each potential intervention, Stripe estimates the impact to conversion, cost, and fraud rates. 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 decides whether to request authentication. This section focuses on what happens when 3DS is the chosen path. 3DS is not a single flow. It’s a family of options with 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 optimize across three competing objectives simultaneously: regulatory compliance, fraud prevention, and conversion. That requires transaction-specific decisions that consider risk signals, device context, 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 Radar fraud scores to route eligible transactions through the lowest-friction path available. Low-risk transactions below the regulatory threshold use a low-value exemption, skipping authentication entirely. Above that threshold, the engine requests a TRA exemption, where applicable. Moderate risk transactions might use Data Only authentication, which shares 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

Choosing an authentication path is only part of the challenge. The implementation details within a given path are also important. 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 it also introduces additional latency, which can cause the authentication to fail entirely.

Stripe ran a multivariate A/B test to determine the optimal amount of time to wait for fingerprinting before proceeding without it. This is a direct trade-off: wait too long, and conversion fails due to latency; proceed too quickly, and the issuer loses the information that might have improved the issuer’s decision. The optimal time-out varies by device and issuer. Since March 2025, this optimization has recovered more than $39 million in payments.

3DS as a retry strategy

Most processors treat a risk-related decline as final. Surprisingly, our tests have found that adding authentication after the fact can recover the payment. That said, 3DS authentication adds latency, introduces friction, and carries its own processing cost. So, the question isn’t simply, “Would 3DS help to recover this payment?” but instead, “Does the expected value of retrying with 3DS exceed the cost of attempting it?”

Stripe models this directly based on the 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. Stripe improves outcomes here through routing, authorization message optimization, and retries.

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. In many cases, 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 might 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.

First, Stripe continuously experiments with the formatting and content of ISO fields 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. Many successful changes are small, but at network scale, even low-effect size improvements can be measured quickly and produce aggregate impact worth tens of millions of dollars annually. Stripe runs dozens of these experiments each week, and the gains compound over time.

Second, Stripe shares 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 do not observe the same cross-business network patterns that Stripe does, such as 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 can reduce false declines.

Third, Stripe optimizes the use of 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 problem isn’t simply whether to enable those tools globally. Network tokens generally improve authorization rates and reduce costs, but there are pockets of traffic where they don’t: issuers with poor token support, or transaction patterns where tokenization harms approval rates or increases fraud. Stripe learns where tokens help and where they don’t, and applies them selectively.

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 settlement, 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

Fraud signals continue to develop after a payment is authorized. In the hours after a transaction completes, Stripe might observe the same card used in a confirmed fraud attack elsewhere on the network, or a device fingerprint newly linked to a pattern of disputes. These signals can materially change the risk assessment of an already-authorized payment.

This creates an asymmetry that works against fraudulent actors. Every subsequent attempt using 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 post-authorization risk signals escalate, Stripe can proactively refund or reverse the charge before it results in a dispute.

6. Disputes

Even after upstream optimization, some transactions will be disputed. The business pays a dispute fee, absorbs the operational cost of responding, and if the dispute is lost, 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.

Dispute handling is another optimization problem. Upstream, the objective is to maximize expected profit on each transaction in real time. Here, however, 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 expected cost, success rate, and effect on the business’s standing with the card networks. The right strategy depends on the dispute amount, reason code, evidence availability, and the business’s proximity to monitoring thresholds.

Deflection

Stripe integrates with Visa’s Verifi and Mastercard’s Ethoca to deliver enhanced transaction details to issuers before disputes are filed. Purchase descriptions, business information, and transaction metadata increase the chance that a cardholder recognizes the charge and does not escalate it. 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 resulting evidence might satisfy Visa’s Compelling Evidence (CE) 3.0 criteria. In those cases, the issuer is required to block the dispute from being filed. For businesses with repeat customers, it can prevent fraudulent disputes from entering the chargeback process.

Resolution

Verifi and Ethoca also allow disputes to be resolved 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). This avoids the chargeback fee, and more importantly, keeps the event from counting toward the business’s dispute rate.

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. Most individual businesses do not observe enough disputes to learn those patterns reliably.

Stripe’s Smart Disputes system is trained on dispute outcomes across millions of transactions and learns which combinations are most effective in a given 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 described here are stage-specific, but their effects compound across the full payment lifecycle. 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 multistage optimization compounds most clearly.

Richer objective functions

Optimization quality depends on how precisely Stripe can represent 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 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 expanded 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 payment optimizations 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. Stripe is 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

Underlying all of this is continuous experimentation. Stripe runs experiments across the full payment lifecycle and measures effects on authorization rates, fraud, processing costs, and interchange. New ideas are tested continuously, and those that succeed ship automatically to businesses on Stripe. Over the past 2 years, the pace of experimentation has increased by more than 4x.

Businesses that provide richer inputs, such as margin data, tuning risk preferences, and product metadata, expand the optimization surface even further. Contact us; we’d love to collaborate.