What problem does it solve?
Every online card payment needs an approval from the card issuer, and a share of them are declined. Some declines are right (a stolen card, a closed account), but many hit genuine customers: the issuer suspects fraud on a normal purchase, the request is formatted in a way that issuer handles badly, the route through the network is slow or the issuer is briefly unavailable. Stripe cites an estimate that false declines cost US online retailers $81 billion in lost sales in 2023.
The merchant rarely sees why. A subscription renewal that fails becomes involuntary churn, and a checkout that fails sends the customer to a competitor or a second card. Static rules (retry once after a day, always send the same message format) leave money on the table, and blind retries break card network rules and draw fees. Stripe's Twilio story says Twilio needed a processor that would reduce issuer declines and, in turn, involuntary churn.
Most public evidence for this use case comes from one provider: Stripe's own blog and Stripe's stories about its customers (Twilio, Zapier, MATCHESFASHION), so most figures on this page are Stripe's. Razorpay is the other provider that describes its own model. Other payment providers and acquirers sell comparable features; this page lists only deployments with a public source.
- Stripe cites an estimate that in 2023 false declines cost US online retailers $81 billion in lost sales.AI enhancements to Adaptive Acceptance (2025)
How does it work?
- Shape the first request. Before a payment goes to the issuer, a model trained on past outcomes by issuer, card type, network and merchant type chooses the message format, the credential (card number or network token) and the route most likely to be approved.
- Read the decline. When the issuer declines, the decline code and context are classified: hard declines (stolen card, closed account) are final, soft declines may succeed on a second attempt.
- Decide on a retry. For soft and likely false declines, the model predicts whether a retry will be approved and how to adjust it (format, route, timing). At Stripe this happens in real time, before the customer sees the first decline; for subscriptions, retries can also be spread over days.
- Respect network limits. Transactions that are unlikely to be approved are not retried, so the merchant stays within card network retry rules and avoids their fees.
- Learn from outcomes. Every approval and decline goes back into training. Stripe says it now retrains and deploys its Adaptive Acceptance model several times a week.
The model works next to fraud scoring, not instead of it: deciding whether a payment is fraud is a separate use case, and every retried payment still passes the fraud checks.
- Audience
- Back office
- Autonomy
- Autonomous
- Adoption
- Early adopters
- Channels
- API and system to system
What is it worth?
Benchmarks are computed from the public deployments below: one data point per organization per KPI, with who made each claim.
| KPI | Median | Reported range | Data points | Claimed by |
|---|---|---|---|---|
| Revenue recovered | Not pooled | USD 1 million to USD 6 billion | 2 | 1 organization, 1 vendor |
Value drivers: Revenue growth, Customer experience.
Indicative value
An online subscription business with USD 500 million in card payments a year
USD 1.3 million to USD 7.5 million
Card sales recovered from declines per year
How this is calculated
Formula: cardVolume * declineShare * recoveredShare. The low scenario uses every low input, the high scenario every high input.
| Input | Low | High | Basis |
|---|---|---|---|
| Card payment volume cardVolume, USD per year | 500,000,000 | 500,000,000 | The reference business. |
| Share of card volume declined at the first attempt declineShare, fraction of card volume | 0.05 | 0.1 | Editorial assumption, replace with the decline rate from your own authorization reporting. |
| Share of declined volume the model recovers recoveredShare, fraction of declined volume | 0.05 | 0.15 | Editorial assumption, kept conservative against the evidence on this page: in Stripe's customer stories Twilio's treasury team credits Adaptive Acceptance with roughly a one percent authorization rate uplift, and Stripe attributes 1.24% out of Zapier's 4% total uplift to it. Replace with the result of your own A/B test. |
What it leaves out: Gross sales value of recovered payments, not margin. It leaves out the provider's fees, card network fees on retries, refunds and chargebacks on recovered payments, and the longer term value of customers who would otherwise have churned.
Who already uses it?
5 public deployments, strongest evidence first. Grades: A regulator or audit, B the organization itself, C vendor case study, D anonymous or estimate.
Razorpay
India · Payments and cards · 2026
Razorpay, an Indian payment gateway, launched Vulcan in August 2026: a transformer based AI foundation model trained on about 4 billion payments on its network. It routes each payment down the path most likely to succeed and flags fraud across merchants in real time; early components were already making routing, fraud and risk decisions on live transactions before the full launch. Razorpay names Blinkit, Bachatt and redBus among the businesses that see higher payment success rates and more international card fraud stopped. The figures are Razorpay's own.
No outcome disclosed.
Stripe
United States · Payments and cards · 2024
Stripe runs Adaptive Acceptance across the payments it processes: an AI model that optimizes the first authorization request and identifies and retries false declines in real time, before the customer sees the decline. In 2024 Stripe replaced its earlier gradient boosted tree model with a new architecture that adds high dimensional embeddings, and it now retrains the model several times a week. Stripe says the upgrade recovered a record amount of falsely declined payments in 2024 with 35% fewer retry attempts.
- Revenue recovered: USD 6 billion, 2024
"In 2024, this led to Adaptive Acceptance recovering a record-high $6 billion in falsely declined transactions, reflecting a 60% year-over-year increase in the retry success rate."
Claimed by: organization
MATCHESFASHION
United Kingdom · Retail and ecommerce · 2021
The London luxury fashion retailer MATCHESFASHION used Stripe features including Adaptive Acceptance, which applies machine learning to optimize authorization messages and make retry decisions. Stripe's story reports an authorization rate uplift over one year, but credits it to several features together (Adaptive Acceptance, Card Account Updater and added card networks), so the part due to the machine learning feature is not separated.
No outcome disclosed.
Zapier
United States · Technology and software · 2021
Zapier moved its card processing to Stripe after an authorization rate A/B test against its previous processor and uses Adaptive Acceptance, a feature that applies machine learning to optimize authorization messages. Stripe's customer story breaks the total authorization rate uplift down by feature and credits Adaptive Acceptance with part of it and with more than one million dollars in additional revenue. A larger share of the uplift came from Card Account Updater, which is not machine learning.
- Revenue recovered: at least USD 1 million
"Adaptive Acceptance created 1.24% of the total uplift leading to $1M+ in additional revenue."
Claimed by: vendor
Twilio
United States · Technology and software · 2020
Twilio moved its card processing to Stripe after an A/B test of several global processors and uses Stripe's Adaptive Acceptance, which applies machine learning to retry network declines in real time with adjusted routing and messaging. In Stripe's customer story, Twilio's Chris Nasson credits roughly one percent of authorization rate uplift to this feature alone. The overall ten percent uplift in the story mostly comes from local processing and card credential updates, which are not machine learning.
No outcome disclosed.
How do you implement it?
A model agnostic playbook: what to prepare, the order to build in, and what goes wrong.
Data you need
- Transaction level authorization outcomes with decline codes, by issuer, card type, network and country
- A baseline authorization rate per segment from before the change, or a live holdout group
- Refund, chargeback and fraud outcomes linked back to the original authorization
Systems to integrate
- Payment service provider or acquirer APIs and authorization reports
- Card network tokenization and account updater services
- Subscription billing system, for renewal retries
- Data warehouse or BI tool for authorization rate reporting
Complexity: Medium
For a merchant, the models run at the payment provider: the work is an A/B test of processors on live traffic, transaction level authorization reporting and a clear split of which change produced which uplift. A provider or large merchant that builds it in house needs authorization outcomes across many issuers, direct connections to acquirers and card networks, network tokenization and a retry policy that follows each network's rules.
- 1
Measure the baseline by segment
Report authorization rates by issuer country, card type, network and transaction type (first purchase, renewal, saved card), and separate hard declines from soft ones. A single blended rate hides where the losses are.
- 2
Test processors on live traffic
Split live traffic between the current processor and the candidate and compare authorization rates on the same mix. Twilio and Zapier both chose Stripe after such an A/B test.
- 3
Switch on optimization with retry limits
Turn on the provider's request optimization and real time retries, and agree on the retry policy: no retries on hard declines, a cap per card and period, and the card network rules on repeated attempts.
- 4
Attribute the uplift
Break the total uplift down by change. In the public stories on this page, local processing and card account updates explain more of the uplift than the machine learning retries, so report each one separately before you credit the model.
- 5
Watch fraud and disputes next to approvals
Track fraud and chargeback rates on recovered payments for at least one billing cycle. A higher authorization rate that brings more disputes is not a gain.
Guardrails
- No retries on hard declines such as lost or stolen card or closed account
- A cap on retries per card and period that stays within card network rules
- Fraud screening on every retried payment, with the same thresholds as the first attempt
- No change to transaction data that misrepresents the payment, such as the amount or merchant category
- Card data stays tokenized at the payment provider, never in the merchant's analytics
KPIs to instrument
- Authorization rate per segment, against the baseline or a live holdout group
- Revenue recovered from retried payments, net of refunds and chargebacks
- Retry attempts per recovered payment and card network retry fees
- Fraud and chargeback rates on recovered payments versus first attempt approvals
Human in the loop
The payments team sets the retry policy, approves each change to it and reviews authorization rates by segment every week. A sudden drop for one issuer or country goes to a person to investigate with the provider, because a model cannot fix an issuer outage or a misconfigured integration.
Common failure modes
- Bundled uplift credited to the model
- Processor switches, local acquiring, network tokens and account updaters all move the authorization rate at the same time. Without a breakdown, the machine learning gets credit for gains it did not produce.
- Retries that break network rules
- Too many attempts on the same card draw network fees and can make issuers more suspicious of the merchant. Cap retries and skip transactions the model rates as unlikely to succeed.
- Recovered payments that come back as disputes
- A retry can push through a payment the issuer was right to decline. Link chargebacks and fraud reports back to retried authorizations and tighten the policy where they cluster.
What are the risks and rules?
EU AI Act
Minimal risk
Choosing the format, route and timing of authorization requests is not listed in Annex III and is not a practice prohibited by Article 5. The system does not evaluate the creditworthiness of a natural person (Annex III point 5(b)): the issuer still makes the approval decision. If a provider used the same model to refuse service to individual customers, that design would need its own assessment.
Guidance
- Regulation (EU) 2024/1689, Annex III high risk AI systems (European Union, Europe). Annex III point 5(b) covers creditworthiness assessment of natural persons; optimizing the technical handling of a payment authorization is not listed.
Controls to put in place
- A written retry policy per card network, owned by the payments team
- Change control with an A/B or holdout comparison for every model or policy change
- Monitoring of fraud and chargeback rates on retried payments
- Merchant systems hold card data only as tokens, so raw card numbers stay in the provider's PCI DSS environment
Frequently asked questions
- How much does machine learning add to authorization rates?
Less than the headline numbers suggest. In Stripe's customer stories, Twilio's treasury team credits roughly one percent of its authorization rate uplift to Adaptive Acceptance, and Stripe attributes 1.24% out of Zapier's 4% total uplift and more than $1 million in additional revenue to the feature; the rest came from local processing and card account updates. Across its network, Stripe says Adaptive Acceptance recovered $6 billion in falsely declined transactions in 2024.
- Is authorization optimization high risk under the EU AI Act?
Usually not. Choosing how to format, route and retry a payment request is not an Annex III use, and the issuer still decides whether to approve. It would need a fresh assessment if the same model were used to refuse service to individual customers.
- Does it retry payments the issuer declined as fraud?
It should not retry hard declines such as a lost or stolen card, and card networks charge fees for excessive attempts. Good systems retry only declines the model expects to be approved, and every retry still passes fraud screening.
How to cite this page
Blits.ai AI Use Case Library, "AI payment authorization optimization for card acceptance", last verified 12 November 2026, https://www.blits.ai/ai-use-cases/payment-authorization-optimization. Licensed under CC BY 4.0. Method: how we verify use cases.
Changelog
- 12 November 2026: First published