🧠 Sweat the Details

Presented by Checkout.com. A paid partnership, informed by conversations with its payments team.

I’m a frequent traveler, and one of the things I will go unreasonably out of my way for is a half-decent gym at a hotel. Fortunately, my recent stay in Orange County for Checkout.com’s annual Thrive event had something that was indeed more than half decent. A functional area, heavy free weights, a squat rack, and custom blue gym towels that said, “sweat the details.”

I’m not usually a towel enjoyer; they’re mostly functional. So at first, I thought it was a cute marketing slogan, but over the next 24 hours, every conversation I had made this tiny detail seem more and more apt. You see, Checkout.com is a payments company, a rather large one in fact, having processed more than $300bn globally in 2025 for the likes of Microsoft, Netflix and Uber. They’re currently on track to exceed $100bn in the USA alone in 2026.

And payments are all about details.

My good friend and king of payments nerds, Wade Arnold, once said: “Payments are easy; Edge cases are hard.” And the more time you spend in payments, the more that first principle finds you, slaps you across the chest, and screams WOOOOO! And as you stand there, slightly confused by how an ephemeral concept could cause physical pain, you begin to tell everyone who passes by, “It’s the edge cases” while developing an eye twitch.

I guess this is the story of how we all become that person.

Payments on the surface are really simple

A payment message is a bit like an email.

“Hi, your customer would like to spend $500 with my customer. Are we good?”

“Yes.”

Lovely. Someone gets their limited-edition Zelda Ocarina of Time Switch 2.

Except that message has to pass through several companies before you get an answer. Each has its own reasons to worry about the payment.

Start with you buying that Switch 2. You’re the cardholder, and the shop selling it to you is the merchant. Each of you has a financial institution on your side of the payment: yours is the issuer; the merchant’s is the acquirer. Those are the four parties in the four-party model.

But they need a way to talk to each other. That’s where the card network, like Visa or Mastercard, comes in. And the merchant needs a way to connect its checkout to all of this, which is where the payment service provider (PSP) comes in. One company can do more than one of these jobs. Checkout.com, for example, is both a PSP and an acquirer.

For simpler maths, take a $100 purchase. First comes authorization: asking the issuer whether it will approve the payment.

1. The customer presses buy. The merchant’s PSP sends a payment request through the acquirer and card network to the issuer.

2. The issuer decides. Does the customer have enough money or available credit? Does the payment look legitimate? It sends back an approval or a decline through the same chain.

3. An approval reserves the amount. The merchant can complete the order, but that “yes” hasn’t put money in its bank account.

4. The money follows. The merchant submits the completed sale. Clearing establishes what the parties owe; settlement moves money between the banks. The merchant receives its payout under its agreement with the PSP or acquirer, less fees.

Those fees are shared. In a simplified $100 example, suppose $2.10 goes to the issuer, $0.15 to the network, $0.10 to the acquirer and $0.85 to the PSP. Total fees are $3.20, leaving the merchant $96.80. These are illustrative amounts, not a standard price or a literal sequence of deductions.

The issuer’s share is called interchange. The merchant pays for the whole service; its provider passes the relevant shares to the other participants. We’ll come back to that bill.

So far, so email.

The request and reply happen first. The money moves later.

Except it’s an email where there’s a specific format and fields for the amount, currency, merchant, card and a load of context. Is the customer here now? Is this a subscription? Has anyone checked that the person using the card is the person who owns it?

At the other end of the email chain is a black box. The card issuer’s decision. You, as a merchant, send a request and get an answer, but you can’t see everything that happened in between. So if they decline, you often have to figure out why.

There’s a standard for these messages, ISO 8583, but thousands of banks implement it differently. There is no universally perfect payment message. There’s the message that works for this bank, for this payment. As I wrote in a previous payments piece:

“Wells Fargo might only accept it if you have a field filled but not on a full moon.”

And the answer changes. A bank updates its systems without telling you, and something that worked yesterday stops working today.

Every issuer’s black box is idiosyncratic. The customer sees “payment declined.” Somewhere, a payments nerd is trying to work out which bit of the email (payments message) upset the bank. That’s why payments nerds collect stories.

Payments edge case stories are my love language

In prep for this essay, I spoke to Daniel Linder, Senior Product Director at Checkout.com. He’s the kind of guy who gets unreasonably excited about payments edge cases. My kind of human.

Two examples from Checkout.com’s published work show the sort of detail I mean.

• Network tokens are great until they’re not. A network token replaces a card number with a secure substitute. It can keep a stored payment working when the card details change. Except some issuers aren’t set up to accept it, so a change meant to improve payments can produce a decline. The provider has to learn which format works for which issuer, while following the network’s rules. So much for one universal “better” setting.

• Every data field matters. For eligible business-card payments, supplying accurate sales-tax data and other required details can qualify the payment for a lower interchange rate. The industry calls this Level 2 data. Same purchase, more information, different price. Separately, Checkout.com reports that adding one field to certain US payments saved a merchant ten cents per transaction and $2 million over a year. Ten cents doesn’t sound like much until you’re processing 20 million payments.

Imagine you’re running an online store. You paid to get someone to your website. You got the product, price and checkout right. The customer pressed buy. Losing them because the message wasn’t what their bank needed is a painfully expensive way to discover that details matter.

Issuers are from Venus; merchants are from Mars.

Issuers are weird.

And I mean that with love.

The merchant sees someone trying to buy something. The issuer sees someone trying to pull its customer’s money out of a bank account to complete a purchase. With a credit card, it is also deciding whether to lend money for that to happen.

Both want to know whether the customer is legitimate. They just have different information to go on.

• As a merchant: Imagine a customer ordering from you for the thirteenth time. They have the same delivery address, for the same sort of purchase. You’d quite like to take their money, thanks.

• As an issuer: You might see a new device, a foreign country and an amount larger than that customer usually spends.

The merchant might have twelve successful orders in its head. The issuer has three reasons to worry.

That doesn’t mean the issuer wants to decline everything (nor do merchants want to approve everything, as we’ll come on to later). As Patrick McKenzie explains in Bits about Money, issuers make money from a mix of interchange, interest, and fees. They want customers to use the card, pay them back, and keep it at the top of their wallet. Having a customer get embarrassed at a checkout isn’t a great retention strategy.

But the issuer has to think about all the spending on that card and whether its customer can pay it back. Your sale is only one part of that.

The acquirer has a different customer: the merchant.

It wants that merchant to sell more, process more volume, and stick around. It also has to worry about what happens if the merchant takes the money and doesn’t deliver the Switch 2.

A refund is when the merchant sends the customer’s money back. A chargeback starts when the customer disputes the payment through their issuer, which can reverse it under the card network’s rules. The merchant can challenge that dispute with evidence.

Now think of an airline selling flights six months ahead and then going bust. Customers paid, but nobody is flying. If the airline has no money left to cover the reversals, the acquirer can be left paying. That is why it cares whether a merchant can deliver what it sells.

So the issuer is assessing the cardholder and the payment. The acquirer is also assessing the merchant. And the merchant needs both of them to be comfortable enough to let a perfectly good customer buy a perfectly good Switch 2.

The fraud, acceptance, cost trilemma

Every merchant wants three things: less fraud, lower cost and higher acceptance. The difficulty is that a decision about one can change the other two.

• Higher acceptance means more payments approved. That can mean more sales, but approving bad payments creates losses.

• Lower cost means spending less to collect the money. But a cheaper payment route is a poor bargain if it loses profitable sales.

• Less fraud means losing less to bad payments. But a rule that blocks criminals can also block good customers.

In video games, skill points are how you build your avatar. You often start with a handful and can assign them to certain skills like stealth, weapons, or healing.

Now imagine you have 10 skill points to spend across three dimensions. To optimize, you’d want 5 out of 5 on each dimension, but you only have 10 points. So where do you spend them?

Here’s one possible build: four points toward less fraud, three toward lower cost and three toward higher acceptance. These are priorities, not measured performance scores.

The trade-offs show up in ordinary decisions. For example:

• You can ask more customers to prove it’s them, perhaps by confirming the purchase in their banking app. That’s authentication. It can stop fraud, but some good customers abandon the purchase along the way.

• You can retry a failed payment and recover a sale, but retries can cost money.

• You can pick the cheapest route and discover it declines more of your customers.

But the skill points aren’t a law of physics. Better information can improve all three.

If you can tell a good payment from a bad one more accurately, you can stop losing money to criminals and stop turning away customers. The interesting question is where you still have to choose, once you’ve stopped doing the obviously dumb stuff. That’s why at scale, it pays to sweat the details.

Fraud: Your risk is idiosyncratic

In video games, a stealth character is very different to a juggernaut. In retail, selling luxury second-hand designer goods has a very different fraud risk to someone selling an AI tool with a subscription, or someone selling gift cards. For example:

• A $500 gift card delivered by email can be moved on quickly.

• A $500 couch needs somewhere to go, a courier, and someone to receive it.

Fraud is a business, with specialists, costs, and ways to turn stolen access into money. What you sell, how quickly you deliver it, and how easily you can resell it all affect whether that business works.

A common defense is a fraud rule: a condition that triggers a decision. For example, if the same device makes ten purchases with ten different cards and email addresses in 24 hours, block further attempts from that device. Device detection is something my alma mater Sardine* is excellent at, btw.

Payment newbies often accept the default rules from their PSP or fraud vendor, although the good ones will help tailor them. Defaults give you a starting point. They don’t know everything about your customers, products or appetite for risk.

For example,

• An overseas purchase might be unusual for one merchant

• Or a Tuesday for a travel company.

“Unusual” is doing a lot of work in a fraud rule.

Then there are false positives: good customers your fraud system mistakes for criminals. If you block every payment, you’ll stop every fraudulent one. You’ll also have no business.

But there’s another way to lose those customers. The more fraud a bank sees from you, the more it says no. Letting more through at your end can lead to more declines at theirs. Counterintuitive as hell, no?

And stopping the fraud doesn’t immediately stop the damage. Daniel described issuers continuing to decline good payments for weeks or months after a fraud attack. The goods you shipped and the chargeback fees are only part of the bill. There are also the legitimate purchases you never get to make.

That’s the opportunity cost of fraud.

We worry about turning away a good customer with our own fraud rules. We should also worry about that customer getting turned away by their bank later, because we let too many bad payments through.

The customer gets the same miserable result either way.

Cost: Everything impacts it

Cost line items are often obvious, like processing fees, disputes, and returns, but the levers to reduce them are far less obvious.

• Processing fees. The merchant discount rate (MDR) is the price the merchant pays to accept the payment. Remember the $3.20 taken from our $100 example? That’s the combined bill: interchange for the issuer, network fees, and the acquirer’s and PSP’s charges. The card type, country, and payment details can change it. Failed attempts and extra services can add charges too.

• Chargebacks and returns add costs too: lost goods, dispute fees, staff time, shipping and restocking. Those don’t disappear just because you negotiated a better processing rate.

Daniel gave me a good example of why even finding the cheaper route gets fiddly. In the US, some debit payments can go through an alternative network such as STAR or PULSE without the customer entering a PIN. This is PINless debit. Same card, another “route” to send the payment.

People assume that route is always cheaper. Except the price depends on the merchant’s category and the size of the purchase. A flat fee can be expensive on a $12 order and cheap on a $500 one compared with a percentage fee. And the routes can have different acceptance rates.

If a route is cheaper and approves more payments, obviously use it. If it costs more and approves fewer, avoid it. The more problematic cases are cheaper with fewer payments approved, or more expensive with more approved. Which matters more and when?

You can try one route and, where permitted, retry on another. But that means evaluating the cost of both attempts, the chance of recovering the sale, and whether it’s even a good payment to recover.

“Always try the cheap one first” only gets you so far.

The whole thing is like a pachinko machine. The Japanese vertical pinball machines, where you place a ball at the top, and what route it takes is decided by gravity. With payments routing, you have to think through the route ahead of time to minimize fraud and cost, considering every possible edge case.

But there’s a trap. If you save $0.10 processing a payment and lose a sale that would have contributed $20 after the cost of the goods, you haven’t optimized anything useful.

Acceptance: Isn’t as simple as saying yes

You hitting approve doesn’t mean the customer’s bank (the issuer) will approve. At all.

Acceptance depends on getting the payment through both sets of checks.

Some things only the bank can fix. Daniel described a bank software update that stopped saved cards from validating properly. Monthly subscription renewals started failing.

Imagine being the customer. You still want the service. Your card still works. Nobody told you anything had changed. Whoops, sorry, your payment’s been declined. The merchant hasn’t changed anything but now has to work out why those renewals are suddenly failing and get the bank to investigate (because remember, the issuer is a black box).

You can change your payment message all day; you can’t fix somebody else’s software with it.

Daniel gave another example where a bank wasn’t answering, so Checkout.com escalated through Visa. The bank changed its setup and payments recovered. Sometimes the useful bit of the payment network is knowing who can get somebody on the phone.

Knowing who to call and having relationships with issuers is a surprisingly squishy, human thing in the year of our lord 2026, but it gets results.

Even when the system is working, a decline message isn’t a diagnosis. You’ve got a reply to your email, but you still need to work out what the bank meant. Look at the different ways these banks respond to fraud:

If you take every reply at face value, you can end up trying to solve the wrong problem. You have to learn how each bank uses these messages before you decide what to do next.

And a recoverable payment isn’t always worth recovering. Daniel’s team uses a fraud score, an estimate of how likely a payment is to be fraudulent, to decide whether to try again or use a different route. Pushing more bad payments through would bring us straight back to the problem above: the bank trusts the merchant less and starts declining good customers too.

Meanwhile, your customer is still waiting to buy their Switch 2.

Where should you spend your skill points?

The annoying thing about working with a personal trainer is that the first thing they ask you is “What is your goal?” And the problem is most people have no idea what their goal is.

It’s usually “a bit better at everything.” But for others, it’s a specific body fat and lean muscle percentage.

The ideal personal trainer gets to know you over time and helps you figure out what to work on: strength, cardio, or whatever matters to you.

The best payments nerds are like personal trainers. They want to know your goal. They can help you get more payments through, reduce fraud or bring the bill down. But first they need to know which problem is hurting you most.

The largest merchants in the world tend to have an informed opinion on what their overall priority is (revenue or cost especially), but a lot don’t.

Daniel called this “best outcome routing.” Do you use a network token for this issuer? Which data should you include? Is another attempt worth its cost? Each decision should serve the same goal: keep more money from legitimate sales after fees and losses.

The cheapest attempt and the most profitable sale are different calculations.

The “a bit better at everything” option

There are a few things worth checking before you get into the fiddly stuff:

• Keep stored card details up to date.

• Send payment messages the issuer can understand.

• Stop retrying failures that aren’t going to recover.

• Regularly check which good customers your fraud rules are rejecting.

A customer who gets a replacement card shouldn’t have to remember every subscription they’ve ever signed up for. If you can keep the payment working securely, the customer keeps the service, and the merchant keeps the customer.

This is the payments equivalent of a trainer fixing your form. You can get stronger and stop hurting your back or shoulder in the process.

Measure completed purchases, money lost to fraud and the full cost of collecting the money, and measure them together. Work out what you keep from those purchases after the fees and losses.

Otherwise, each team can hit its target while the business gets worse.

Optimizing for your goal

Then you get to the choices that depend on your business.

• A subscription business might want to recover more failed renewals because it knows what a retained customer is worth.

• A high-volume merchant with thin margins might prioritize lower cost, provided it doesn’t give away more profit in lost sales.

• A business selling instantly delivered, easily resold goods might accept more friction because it has very little time to catch a mistake.

Even that is too broad. Your loyal subscriber and a first-time buyer on a new device might deserve different treatment inside the same business. An AI subscription business, for example, also has to worry about people repeatedly creating accounts to use free trials without ever paying.

The goals need refining before you can optimize.

• “Get my acceptance rate up” becomes “get more legitimate purchases through, within this fraud-loss limit.”

• “Make payments cheaper” becomes “save on fees without losing more profit in declined sales.”

Now the payments nerd has something to work with.

My old CEO at Sardine Soups always used to say, “all risk problems are data problems.” I think that expands to all payments optimization problems. Daniel is a data scientist. But he sits across fraud, issuer relations, and acceptance. That’s something merchants could and should mirror.

The system can watch payment traffic and test which messages and routes work best. But when a bank changes something, and subscriptions start failing, someone still has to investigate, work out what to try next, and get the bank involved. That’s why the people doing this need to see the fraud, the declines, and the cost together. The person trying to recover a sale needs to know whether the fraud team would want it stopped.

Your build will vary based on how you want to play the game.

A good payments partner helps you work out the build, tests whether it works and changes it as your business changes.

Which brings me back to the towel.

Sweat the details.

ST.

Brought to you by Checkout.com. Thanks to Daniel Linder and the team for sharing the details behind this piece.

That's all, folks. 👋

Remember, if you're enjoying this content, please do tell all your fintech friends to check it out and hit the subscribe button :)

Want more? I also run the Tokenized podcast and newsletter.

(1) All content and views expressed here are the authors' personal opinions and do not reflect the views of any of their employers or employees.

(2) All companies or assets mentioned by the author in which the author has a personal and/or financial interest are denoted with a *. None of the above constitutes investment advice, and you should seek independent advice before making any investment decisions.

(3) Any companies mentioned are top of mind and used for illustrative purposes only.

(4) A team of researchers has not rigorously fact-checked this. Please don't take it as gospel.

(5) Citations may be missing, and I’ve done my best to cite, but I will always aim to update and correct the live version where possible. If I cited you and got the referencing wrong, please reach out