The secret sauce behind payment performance. A conversation with Checkout.com’s Daniel Linder

Hey there,

Payment performance is often reduced to a single metric, but in reality it is the result of continuously balancing three forces: acceptance rates, fraud and cost.

To start 2026, I’m joined by Daniel Linder, Senior Product Director at Checkout.com, one of the architects behind the company’s payment optimization and fraud technology. In this conversation, we explore why real payment performance is about maximizing value for merchants, not just approvals, and how Checkout.com combines technology, data, and issuer relationships to do it at scale. 

Arthur Bedel: Daniel, let’s start at the beginning. “Payment performance” is a phrase that gets used a lot, but what does it actually mean in practice?

Daniel Linder: At its core, payment performance is maximizing the value of legitimate payments for merchants. That starts with increasing acceptance rates, but it also means doing so without increasing fraud or unnecessary costs. Every card payment triggers a complex exchange of messages between the merchant, Checkout.com, the card networks, and issuing banks. Performance is about making sure those messages land in a way issuers understand and trust, so good payments go through, and bad ones don’t.

Arthur: Why do payments fail so often in the first place?

Daniel: There are a few main reasons why a transaction might fail. First, payments are effectively a translation problem. Every card payment is sent as an ISO 8583 message, large, structured data payloads with hundreds of possible fields, and issuing banks don’t interpret those fields in the same way. As a result, the same decline code from two different banks can mean very different things. Second, fraud plays a significant role. Banks may decline transactions they believe are risky based on their internal models, merchant category codes, or local fraud patterns, even when the transaction is legitimate. Finally, some declines are expected and appropriate, such as genuine cases of insufficient funds. It’s this combination of complexity and nuance that makes payment optimization so valuable for merchants.

Arthur: So where does Checkout.com step in?

Daniel: Our role is to act like a highly specialized translator. We adapt each payment message so it arrives at the issuer in the format and structure they prefer based on historical behavior, real-time signals, and context. That might mean adjusting field formats, including extra device data, retrying with updated card details, or selectively modifying things like AVS or authentication data. However, in many cases, performance improves not just because we change the message, but because we work directly with issuing banks. That can mean sharing fraud signals, aligning on risk models, or even asking issuers to change rules or policies on their side when something clear isn’t working.

Arthur: Retry logic is often misunderstood. How do you decide when to retry a payment, and when not to?

Daniel: Context is everything. If it’s suspected fraud, retrying would be irresponsible. But some declines are recoverable. For example, an expired card might succeed instantly if we use a Real-Time Account Updater. The challenge is that the same decline code can mean different things depending on the issuer, which is why static rules don’t work at scale.

Arthur: That’s where machine learning comes in?

Daniel: Exactly, but not in the way people often think. The real power isn’t just “ML,” it’s how we combine machine learning with deep payments expertise. We use contextual multi-armed bandit algorithms to decide, in real time, which optimization to apply to which payment, for which issuer, in which situation.

Arthur: For readers less familiar with that term, how would you explain a contextual multi-armed bandit?

Daniel: Imagine a machine with two levers and each representing a possible optimization. The goal is to pull the lever most likely to get the payment approved. The “contextual” part means the algorithm also looks at the situation: issuer, scheme, transaction amount, AVS response, time of day, and more. Crucially, it never fully stops testing. It balances using what works today with exploring alternatives because issuer behaviour and fraud patterns are always changing. 

Arthur: How is that different from traditional A/B testing?

Daniel: A/B testing splits traffic evenly and waits for a winner. That’s slow and risky in payments. Our approach learns after the very first transaction. It starts favoring better-performing options immediately, while still keeping a small amount of exploration. You never go 100% in one direction, because banks, schemes, and fraud patterns are changing constantly.

Arthur: Can you give an example of this in action?

Daniel: Take Address Verification Service (AVS). Dropping AVS can increase acceptance, but it can also increase fraud risk and costs, especially in the US. So the question isn’t “Should we drop AVS?”, it’s “For which payments, with which issuers, under which conditions does dropping AVS increase legitimate approvals without increasing fraud?”. Our algorithms learn to balance dynamically, factoring in fraud scores, issuer behavior, transaction value, and cost impact, and apply the optimization only when it makes sense.

Arthur: Fraud is often the elephant in the room. How do you avoid optimizing payments for fraudsters?

Daniel: Optimization never runs in isolation. Every payment is first assessed by our fraud engine and only payments we believe are legitimate are eligible for optimization. This ensures we’re increasing acceptance without increasing fraud exposure, which is a very difficult tightrope to walk. We also give merchants a say. By default, we optimize for overall profit, but merchants can align with us on risk appetite. Some want to maximise growth, others want to minimize costs or cap fraud tightly. We can tune the system accordingly. 

Arthur: Merchants often ask about uplift. How do you actually measure the value of payment performance?

Daniel: Uplift has two dimensions. First, acceptance rate improvement, how many additional payments succeed. Second, transaction value, the revenue attached to those saved payments. We maintain control groups so merchants can see the difference between optimized and non-optimized traffic. That’s how we show real, attributable revenue impact in our merchants’ dashboard.

Arthur: So, after all this, what is the secret sauce behind Checkout.com’s payment performance?

Daniel: It's a deep understanding of why payments fail, years of issuer-specific learning, real-time algorithms, strong issuer relationships, and continuous human oversight. Sometimes the right action is algorithmic. Sometimes it’s reducing fraud. Sometimes it’s calling a bank. And sometimes it’s rethinking costs or scheme rules.

Arthur: Final question, what should merchants do to get the most out of Checkout.com?

Daniel: Share as much context and data as possible, align with us on risk appetite, and treat payment performance as a strategic lever, not a set-and-forget metric. The more data we have, the more precisely we can optimize. Merchants benefit immediately from what we’ve already learned, and every new payment makes the system smarter.