Intelligent Acceptance is Checkout.com’s AI-powered payment optimisation engine, built to fight false declines, a $50.7 billion problem of legitimate payments that fail because of technical friction, outdated routing or issuer preferences that merchants have no way to see. Its machine learning models are trained on more than twenty billion transaction data points and make real-time decisions on live payments, adjusting how each transaction is messaged to the issuer, selecting the best routing path, choosing between a network token and full card details, and applying authentication exemptions where regulation allows.

By 2024 the engine was performing well, but adoption had stalled at around half of Checkout’s total processed volume. The reasons had little to do with the quality of the models. Merchants were being asked to agree pricing before they had seen evidence that the product worked for their own traffic, thirty-day trials often ended before the results were statistically meaningful, and the Dashboard reduced hundreds of decisions on every transaction to a number that merchants could not verify or explain internally.

The objective of the initiative was to increase paid adoption by changing how Intelligent Acceptance established and communicated merchant-specific value. Rather than asking merchants to commit before the evidence existed, we wanted to identify those with enough traffic to prove performance, demonstrate the improvement on their own live payments, and only present a commercial opportunity once that value was credible and sustained. The product also needed to explain the result clearly enough for payments and finance teams to understand, trust and defend internally.

As Director of Product Design, I set the strategy and product direction around two principles: prove value before selling, and explain without overwhelming. I developed the adoption strategy with Product leadership and worked closely with a product designer to translate it into the merchant experience. I established the guiding principles, shaped iterations and experiments, reviewed the design work and ran workshops with Product, Engineering, Data Science, Account Management and Commercial. My direct focus was the adoption model and the structure of the rebuilt Dashboard.

Every card payment travels from the merchant, through the card networks, to the bank that decides whether to approve it. A legitimate payment can fail anywhere along that path for reasons that have nothing to do with the customer or their funds. Intelligent Acceptance runs on a merchant’s payments and makes a set of decisions on each one to give it the best possible chance of being approved. A proportion of transactions is deliberately left unoptimised, creating a control group against which the product’s effect can be measured.

The engine can choose the route most likely to succeed, format the request in the way an issuer prefers to receive it, decide whether extra authentication is necessary, use a network token in place of full card details, and retry a declined payment using a different approach. It runs around 26,000 optimisations every minute across Checkout’s network. None of this changes what the customer sees at checkout. It changes what happens to the payment in the seconds afterwards, and how often it succeeds.

Checkout calls the measured difference in acceptance rate between the optimised traffic and the control group the Boost. The size of that Boost depends on each merchant’s mix of issuers, card types, geographies and payment patterns. Those differences are significant enough that the result cannot be predicted reliably in advance. It only becomes clear once the engine has run on that merchant’s own live traffic.

That created the central commercial problem. The evidence needed to sell Intelligent Acceptance only existed after the product was already running, while the existing model asked merchants to agree to it before anyone could show them what it was worth.

For a product that recovered revenue for merchants, Intelligent Acceptance was surprisingly difficult to sell. Every new conversation began with one of two imperfect choices: sign a pricing quote before seeing any merchant specific evidence, or enter a thirty day free trial and hope the data resolved before the trial ended.

Payment performance data is noisy. A month was frequently not long enough to reach statistical significance, the point at which Data Science could show that an improvement in acceptance rate was caused by the product rather than chance. Trials failed because the measurement window had failed. Account Managers responded by extending them to sixty or ninety days, which weakened the urgency of the sale and, over time, the merchant’s confidence in the result.

We spoke with merchants, Account Managers and Commercial leads across tiers, reviewed support requests and went back through the history of past trials. The same connected problems appeared repeatedly.

The Dashboard also had more fundamental credibility problems. Metrics changed with small adjustments to the date range, some revenue figures did not accumulate in ways merchants found trustworthy, and empty states did not explain when there was too little data to show. Only around four in ten merchants had statistically significant results. Many of the rest had too little volume for the measurement ever to resolve, so they bypassed the product and requested payment-performance reports through their Account Managers instead.

The strongest insight from our research was that price was not the primary barrier. Merchants were willing to let machine learning act on their payments, but they were reluctant to pay for a result they could not verify. If Intelligent Acceptance could prove value on a merchant’s own traffic and explain that value in terms their finance and payments teams accepted, the commercial conversation could move from persuasion to confirmation.

We began by exploring how the existing trial model could be improved. This included whether pricing was the real barrier to adoption, whether access should be limited by time, features or traffic volume, and how trial length should vary according to a merchant’s ability to reach statistical significance.

We pressure tested several approaches with Account Managers and Commercial leads. A permanent limited usage offer looked attractive because it removed the artificial time constraint, but Account Managers argued that an offer with no decision point would remove the urgency needed to convert interest into a paid commitment. Limiting the free experience by feature was also the wrong trade-off. Merchants needed to see the complete optimisation engine working on real payments, not a reduced version that could not demonstrate its full effect.

The first proposal therefore kept a firm end date but varied the duration according to the merchant’s traffic profile. Strong fits would receive a three month trial aimed at conversion; others would receive six months, giving the measurement more time to resolve and giving Data Science more evidence with which to improve the models. The free experience would be limited by the share of traffic being optimised rather than by the capabilities available.

Turning that model into a target list required segmenting Checkout’s entire merchant base by volume, traffic composition and prior product history. That analysis identified the merchants with enough traffic to prove a result and established a credible route from 51% to 76% of Checkout’s total processed volume on the product. It converted a design proposition into a quantified commercial opportunity and gave the programme a clear basis for prioritisation.

The proposal improved targeting and trial design, but it still left the most important problem untouched: the merchant had to agree before the evidence existed. Reviewing the model with Product and Data Science led to the turning point. Intelligent Acceptance already operated through the merchant’s existing integration, so the evidence did not need to wait for the sales process. A portion of traffic could begin building a merchant-specific result in the background, allowing the first commercial conversation to open with evidence rather than a request.

That thinking became Shadow Mode, an internal name for the mechanism that underpinned a new adoption strategy: prove value first, then push.

Shadow Mode allowed Intelligent Acceptance to establish performance on a merchant’s own live traffic before a commercial conversation began. It used the merchant’s existing integration, so no implementation work was required before the evidence could build. Merchants never saw the internal name. When the result was eventually surfaced, the experience spoke only about their payments, their measured improvement and what it could be worth across their full volume.

The traffic split varied by merchant rather than being applied uniformly. Larger merchants typically had 10% to 20% of their traffic optimised, limiting exposure while still producing enough volume to measure. Smaller merchants could have up to half of their traffic optimised because they were more likely to struggle to reach significance. The remaining traffic formed the control group, and the higher-risk optimisations were disabled while the merchant remained in Shadow Mode.

Data Science set a 0.5 percentage-point improvement in acceptance rate as the threshold at which the observed result reached statistical significance. We added a second guardrail: the improvement had to remain above that threshold for two consecutive months. That prevented a short-lived spike from being mistaken for sustained value and reduced the risk of selling the product to a merchant who was unlikely to benefit.

Once a merchant cleared that bar, their Dashboard updated automatically with the proven result and the appropriate activation path began. Proof alone was not enough, however. The product also had to make the evidence understandable, because a statistically valid number still has little commercial value if the merchant cannot explain where it came from.

Once a merchant cleared the threshold, the commercial experience could begin with evidence rather than persuasion. The merchant already had a measured result on live traffic. The activation journey needed to make that result visible, show what the same performance could be worth across their full eligible volume, and carry the evidence consistently into the commercial conversation. The first touchpoint was an in-product notification on the Business overview. Rather than introducing Intelligent Acceptance with a generic product message, it led with the additional annual revenue available if the merchant’s measured performance was extended across their full eligible traffic.

The Intelligent Acceptance Dashboard then made the evidence concrete. It separated what had already happened from what could happen next. Merchants could see the revenue gained, their measured Boost and the proportion of traffic already being optimised, alongside the projected annual value if that performance was extended across their full eligible volume. Keeping realised and projected value together but clearly distinct was important. The commercial opportunity could be ambitious without presenting a projection as evidence.

Payments specialists could go deeper into the optimisations contributing to the result. The detail view showed the contribution from capabilities such as Network Tokens, Adaptive Messaging, 3D Secure configurations, Smart Payment Routing and Intelligent Retries, alongside their associated revenue and transaction impact. This allowed the headline proposition to remain simple while giving merchants who needed more evidence a path into what was driving the result.

Up to this point, the experience was the same for managed and unmanaged merchants. The difference was how the commercial conversation continued. For managed merchants, the Account Manager retained ownership of direct outreach. We deliberately avoided automated sales emails for these relationships. The Dashboard and notification surfaced the opportunity, while the Account Manager could decide when and how to introduce it using the same merchant-specific evidence already visible in the product.

For unmanaged merchants, the same evidence supported an automated email journey, with Merchant Support taking the follow-up where needed. The email carried through the measured Boost, revenue already gained and projected full-volume value shown in the product.

The important design principle was continuity of evidence. The notification, Dashboard, email and commercial conversation all worked from the same measured result. The route into the conversation could change according to the merchant relationship, but the evidence did not. We chose to deliver this model before self-serve activation. A one-click path would have reduced friction, but the person viewing the Dashboard was not necessarily authorised to agree to a paid service, and some important merchants did not use the Dashboard as their primary relationship with Checkout. More importantly, our work with Commercial teams consistently showed that activation itself was not the main barrier. Proving the value was. The priority was therefore to get the timing, targeting and evidence right first.

The activation message was only the first test of the evidence. Once merchants were using the Dashboard to monitor performance, the numbers had to withstand repeated scrutiny. We therefore started with the measurement itself rather than the interface. Working with Data Science, we moved the calculations onto a dependable schedule, removed metrics we could not defend and rebuilt figures that did not reconcile over time. Merchant interviews, Account Manager feedback and recurring support requests all pointed to the same failure in the existing experience: it showed that performance had improved without exposing enough of the evidence for a merchant to trust the result or justify the cost internally. We tested prototypes with merchants and Account Managers, compared alternative information hierarchies, assessed whether people could understand and explain the Boost, and reviewed the work through our internal design process. That testing changed the metric hierarchy, simplified the language, exposed more supporting evidence and reshaped the page around progressively deeper levels of detail.

The final experience was organised around the three questions that kept returning through research and support conversations: what value am I receiving, where is it coming from, and why should I believe the number? It only surfaced once the improvement had reached the threshold defined with Data Science and remained consistent for two consecutive months. Everything shown to the merchant therefore represented proven, sustained performance rather than an early or inconclusive result. The top of the page answered the first question, the middle answered the second and the lower sections answered the third. A finance lead could take the headline result, while a payments specialist could continue into the evidence and methodology beneath it.

The page opened with the commercial result: recovered revenue, the acceptance rate improvement in percentage points against the merchant’s own baseline, and the number of transactions saved. A chart directly beneath showed how that improvement had performed across the selected period, connecting the headline result to its behaviour over time.

The optimisation breakdown attributed the measured improvement to the individual levers working on that merchant’s traffic, including dynamic routing, adaptive messaging, network tokens and smart authentication. This answered the most common merchant question directly: which parts of the engine are actually helping my payments?

The next section separated the result by attempt, showing how much of the improvement came from optimising the first presentation of a payment and how much came from recovering declines through retries. The first-attempt view placed optimised traffic and the control group side by side, including their traffic split, transaction volumes, acceptance rates, transactions saved and recovered revenue.

The first attempt chart then showed how that part of the improvement varied across the year. It retained the confidence interval rather than smoothing the data into one artificially clean line, exposing the natural variation behind a result that had already met the threshold for proven value.

Retries completed the attribution story by showing the total number of declines, how many were retried and saved, and the success rate across individual decline reasons. Together, these views showed whether value was being created by improving the original payment request, recovering failed payments afterwards, or both.

The final layer explained how the Boost was calculated through a progressive walkthrough. Rather than presenting the full methodology at once, each step built on the last, moving from total payment volume into the optimised and control groups, then through authorised, declined and retried transactions, before resolving into the acceptance-rate improvement and estimated recovered revenue. This made the calculation traceable without overwhelming the reader. Merchants could follow the logic behind the headline figure at their own pace, while payments specialists still had enough depth to scrutinise the methodology.

By the end of the walkthrough, the merchant was not only being told that the Boost was real. They had seen how the result was constructed and had enough evidence to explain it themselves. A number that could be defended to a finance leader was trusted differently from one that simply arrived with the authority of an AI model, and that difference was the central design outcome of the experience.

Building a product whose job is to prove its own worth meant the hardest decisions were rarely about what could be shown. They were about what could be claimed, when it was responsible to claim it and how the operating model around the product should respond.

By the beginning of 2026, Intelligent Acceptance was delivering measurable value across Checkout’s merchant portfolio, increasing acceptance, recovering revenue that would otherwise have been lost, and reducing unnecessary payment retries.

The impact showed up across payment performance, merchant revenue, processing efficiency and scale. Boosts were substantial across the portfolio, billions in merchant revenue were recovered, retry volumes fell, and the engine was operating across billions of live payment decisions.

The takeaway from this work was that an AI product can perform exceptionally well and still struggle to earn adoption. Intelligent Acceptance was producing meaningful gains, but those gains only became commercially useful when merchants could see enough evidence to trust what the models were doing and explain the value.

That shifted the role of Design much further upstream. We were not simply redesigning a Dashboard. We were shaping when value was strong enough to become a commercial claim, how it should be measured, and how the product and commercial experience should respond once that value had been proven.

Explainability also turned out not to mean exposing everything. Finance teams needed a small number of credible figures they could defend. Payments specialists needed a path into the attribution, comparison and methodology behind them. Designing that hierarchy allowed the experience to remain simple at first glance without becoming a black box underneath.

The more interesting opportunity in AI products is not making the intelligence visible for its own sake. It is deciding what evidence people need in order to trust the decisions being made on their behalf, and building that proof into the product from the start.

Self-serve activation is the next step once the broader permissioning it depends on is in place. A one-click upgrade only works when the product can verify that the person acting has authority to agree to a paid service. Once that is solved, the model can close the loop: Intelligent Acceptance proves value on the merchant’s own traffic, explains that value clearly enough to be trusted, and lets the right person extend it across their full volume without waiting for a sales call.