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 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.

I set the strategy and product direction around two principles, proving value before selling and explaining without overwhelming, and developed the adoption strategy with Product leadership. I worked closely with a product designer to translate it into the merchant experience, shaping iterations and experiments, reviewing the design work and running 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, because 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, either signing a pricing quote before seeing any merchant-specific evidence or entering a thirty-day free trial and hoping 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.

Whichever route a merchant took, the Intelligent Acceptance Dashboard was where they were expected to judge the result. It led with their acceptance rate and Boost, followed by revenue and transactions saved, a chart comparing performance with and without Intelligent Acceptance, and a list of the optimisations Checkout had applied on their behalf.

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

The Dashboard also had more fundamental credibility problems, most of which came from how its metrics were calculated. Figures were computed on the fly for whatever period a merchant selected, so a small change to the date range could shift the Boost noticeably, and revenue did not add up over time in the way anyone would expect it to. The daily uplift shown on the chart was not measured on the day at all, but projected from the value for the whole period. Merchants could also select periods for which there was no data to show, and the Dashboard gave them no explanation. Underneath all of this sat a volume problem, because 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. Missing data became the single biggest cause of support requests, and depending on the week, that support took up between a fifth and a half of the Data and Product team’s capacity.

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.

“I don’t take it very seriously when a processor says it can improve my acceptance rate by 10%.”Head of Customer Payments, $1bn+ retailer

We began by exploring how the existing trial model could be improved, testing 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, while 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, because 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, which we summarised as 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.

Alongside statistical significance, we set a 0.5 percentage-point improvement in acceptance rate as the threshold for a result to count as proven, high enough to be meaningful to the merchant and worth a commercial conversation. We added a second guardrail, requiring the improvement 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.

With a proven result in place, 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 boost already achieved, their measured acceptance-rate 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 boost already achieved 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.

With the numbers on a firmer footing, the interface then had to address the black-box problem the research had surfaced. 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, about what value merchants were receiving, where it was coming from and why they should believe the number.

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, showing the revenue boost, the acceptance rate improvement in percentage points against the merchant’s own baseline, and the number of transactions saved alongside the total optimised. 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 directly answered the question merchants asked most, about which parts of the engine were actually helping their 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 revenue boost.

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 revenue boost.

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.

The work set out to increase paid adoption by changing how Intelligent Acceptance proved and explained its value. Over its course, the number of merchants on the product grew by around 80%, Shadow Mode began building evidence in the background across Checkout’s merchant base, and merchants who had not yet adopted the product could see a proven result on their own traffic before being asked to pay for it.

The engine itself continued to deliver at scale over the same period.

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, with Intelligent Acceptance proving value on the merchant’s own traffic, explaining that value clearly enough to be trusted and letting the right person extend it across their full volume without waiting for a sales call.