Most write-ups about Checkout.com focus on the valuation swings. What's more useful if you actually build software is the architectural decision sitting underneath the business: bundling gateway, acquirer, and processor into one API instead of making merchants stitch together five vendors.
That decision is why the company is one of the more interesting names in UK startups right now, and it's worth understanding regardless of whether you ever touch their SDK.
The problem it was built to solve
Before consolidated payment platforms existed, accepting cards internationally meant integrating a gateway, a separate processor, an acquiring bank relationship, and standalone fraud tooling, each from a different vendor, each a separate point of failure.
Checkout.com collapses that stack into a single integration. A merchant makes one API call instead of coordinating five systems that don't naturally talk to each other.
This matters more as a business scales internationally. A merchant selling into 40+ countries doesn't just need card acceptance, it needs high authorization rates, local payment method support that actually converts in each market, and fraud detection precise enough to catch bad actors without blocking legitimate customers.
Get any one of those wrong and the failure is invisible in your logs; it just shows up as a customer who got declined at checkout and never came back.
Why the regulatory status isn't just a footnote
Checkout.com is authorized by the UK's FCA as an electronic-money institution and holds direct principal membership with the major card schemes. That's a meaningfully different position than being a reseller sitting on top of someone else's infrastructure.
Direct scheme membership means fewer intermediary hops between the merchant and the actual settlement, which is part of what lets the platform run domestic acquiring across 45+ countries instead of funneling every transaction through one home market.
It's not a bank though. Customer funds sit under EMI safeguarding rules, not FSCS-insured deposits. That distinction matters if you're comparing it architecturally against a company with a full banking license, since the regulatory footing shapes what the platform can and can't do at the account level.
Where the money actually comes from
The core revenue model is a per-transaction fee, structured as Interchange Plus Plus (IC++). Instead of one bundled percentage, the fee gets split into three visible components:
| Component | Set by | Goes to |
|---|---|---|
| Interchange fee | Card network rules | The customer's issuing bank |
| Scheme fee | Visa/Mastercard directly | The card network |
| Platform markup | Negotiated per merchant | Checkout.com |
The first two are pass-through costs. The third is the actual business. For high-volume merchants, that markup reportedly lands somewhere around 0.1%–0.4% plus a small fixed fee, though nothing is published as a fixed rate, pricing gets negotiated per merchant based on volume and risk profile.
On top of the base fee, FX conversion margin and fraud detection tooling (trained on aggregate transaction data across the platform) add further layers to the revenue stack.
The infrastructure lesson worth taking away
If you're designing payment infrastructure of your own, the interesting takeaway isn't the fee percentages, it's the architectural bet: unify multiple separately-regulated functions behind one interface, take on the regulatory and compliance overhead yourself, and let that consolidation become the actual product.
Stripe optimizes for developer speed and fast time-to-integration. A platform like this optimizes for depth, direct scheme access, wide local payment method coverage, and fraud infrastructure tuned across a large enterprise transaction volume, at the cost of self-serve simplicity.
Neither approach is objectively better. But if you're ever weighing whether to build payment logic on top of a fast, generic API versus a deeper, negotiated enterprise integration, this is basically the tradeoff in miniature: speed and simplicity on one side, direct infrastructure control and negotiated economics on the other.
Top comments (0)