I've integrated both. Cards and open banking. In production. Moving real money for real UK merchants.
So when developers ask me "which is actually better to build on?" I don't give them the marketing answer. I give them the three numbers that decide it: how much it costs, how fast the money moves, and how much of your life you lose to the integration.
Let me walk through all three. Honestly. Including where cards still win.
1. Cost — and why it's not close
Here's the part nobody at the card networks wants in a headline.
A UK card payment costs you somewhere between 1.5% and 3%+ per transaction once you stack interchange, scheme fees, and your processor's margin. The "0.2% debit interchange cap" everyone quotes is the floor of the floor — it's not what lands on your statement.
An open banking payment costs roughly 0.1%–1.0%, or a flat 20p–50p. No interchange. No scheme fee. Because there's no scheme. The customer authorises the payment inside their own banking app and the bank moves the money directly.
The concrete version: a local garage takes £500 for a repair. A 1.5% card fee costs them £7.50. The same payment over open banking can cost around 10p. (Noda)
That's not a rounding difference. That's the difference between a payments line item you tolerate and one you forget exists.
And there's a second-order cost cards carry that nobody puts in the pricing table: chargebacks. £20 a pop, plus the engineering time to fight them, plus the fraud surface you have to defend. Open banking payments are bank-authenticated at source. There's no card number to steal and no "I didn't authorise this" dispute when the customer tapped approve in their own banking app. The fraud surface is smaller, so the price can be lower. The two facts are connected.
2. Latency — settlement, not the spinner
This is where developers get the comparison wrong, so let me split it cleanly.
Authorisation latency — the spinner the user stares at — is comparable. Both flows take a few seconds. A card auth round-trips the network; an open banking payment redirects the user to their bank's SCA and back. From the user's chair, both feel like "tap, wait, done."
Settlement latency is where they diverge violently.
A card payment authorises instantly but settles in ~2 business days. The money is promised, then it sits in limbo, then it arrives — minus fees, and reversible for months.
An open banking payment runs over Faster Payments. Settlement is near-instant — seconds to minutes — straight bank-to-bank, 24/7. There's no two-day float, no "pending payout" dashboard, no reconciling Tuesday's sales against Thursday's deposit. (Payop)
If you've ever written reconciliation code, you already feel why this matters. Half the complexity in payments tooling exists to model the gap between "authorised" and "settled." Close that gap to near-zero and a whole category of state machine — pending, settling, settled, partially-reversed — collapses into one event: paid.
3. Developer experience — where I'll be honest both ways
Let me give cards their due first.
Card SDKs are mature. Stripe's docs are art. The card flow is a solved, copy-paste problem with twenty years of Stack Overflow behind it. If you're doing global, card-first commerce, that maturity is worth real money. I'd still reach for cards there.
Open banking is younger, and the early ecosystem was genuinely painful — you were integrating against dozens of bank APIs, each with its own quirks, its own auth dance, its own downtime. That's the part that earned open banking its "hard to build on" reputation a few years ago.
But that reputation is now outdated, and here's why: the bank-by-bank mess is exactly what a good PISP abstracts away. You don't integrate 40 banks. You integrate one API that speaks Payment Initiation, handles SCA, manages the consent lifecycle, and fans out to Faster Payments for you.
In practice, the flow is short:
// 1. Create a payment — you describe intent, not card mechanics
const payment = await atoa.processPayment({
amount: 4999, // £49.99 in minor units
currency: 'GBP',
reference: 'order_10472',
redirectUrl: 'https://yourapp.com/return',
});
// 2. Send the customer to their bank to authorise (SCA happens here)
redirect(payment.authorisationUrl);
// 3. The bank moves the money over Faster Payments.
// You get told when it's actually settled — not "authorised, check back Thursday."
// Webhook: the event you actually care about is real, not a promise
app.post('/webhooks/atoa', (req, res) => {
const event = verify(req); // verify signature
if (event.type === 'payment.completed') {
fulfilOrder(event.data.reference); // money is already in the bank
}
res.sendStatus(200);
});
Notice what's missing from that code. No card object. No PCI scope to inherit. No tokenisation vault to secure. No requires_capture → capture two-step. No chargeback webhook to handle. You describe a payment, the customer approves it in their bank, the money arrives, you fulfil. The thing you're modelling is the thing that actually happens.
That's the DX argument in one sentence: open banking lets you write code that matches reality instead of code that models a 1970s settlement delay.
The honest scorecard
| Card rails | Open banking | |
|---|---|---|
| Cost per txn | 1.5%–3%+ | 0.1%–1% / 20p–50p |
| Settlement | ~2 business days | Near-instant (Faster Payments) |
| Chargebacks | Yes, £20+ each | Structurally absent |
| PCI scope | Yours to carry | Not your problem |
| SDK maturity | Excellent, 20 yrs | Younger, but abstracted |
| Best for | Global, card-first | UK consumers, instant settlement |
Cards aren't dead. If your customers are international and card-native, build on cards. I mean that.
But if you're a UK SaaS, marketplace, or merchant tool charging UK consumers — you're paying card prices and eating card latency for an experience your users don't need. The numbers back the switch, and they're moving in one direction: UK open banking payments are up 53% year on year, with nearly 1 in 3 adults already using it. (Open Banking Ltd)
Try it yourself
The fastest way to feel the difference is to build it. Atoa's sandbox gives you a real Payment Initiation API, real Faster Payments settlement, and webhooks that fire when money actually moves — not when it's promised. docs.atoa.me
Spin up a test payment. Watch it settle in seconds instead of days. Then look at what you'd have paid in card fees for the same transaction.
That second number is the one that changes your mind.
Have you shipped both card and open banking flows in production? I want to hear where the DX actually broke down for you — the messy bits, not the brochure version.
Top comments (0)