Why Open Banking Is Eating Card Payments in the UK (And the Numbers Prove It)

I've been building payment infrastructure for the last few years. Cards were the default. Visa, Mastercard, Stripe — the holy trinity of "just make it work."

Then I looked at the numbers.

53% growth in open banking payments year-on-year. 351 million payments in 2025 alone. 33.1 million users expected by 2026 — that's over 60% of UK adults. And account-to-account payments are projected to grow at 13.63% CAGR through 2031 — the fastest of any payment method in the UK.

Meanwhile, card transaction growth has flatlined. Debit cards still hold about 42% of the UK market, but merchants are quietly migrating away. The reason isn't complicated.

It's the fees.

The Tax You Don't See

Here's what actually happens when a customer taps their card at your checkout:

1. Interchange fee → goes to the card-issuing bank (0.2–0.3% for UK debit, 0.3% for credit)
2. Scheme fee → goes to Visa or Mastercard (0.02–0.15% plus per-transaction)
3. Acquirer fee → goes to your payment processor
4. Gateway fee → goes to your payment gateway

Stack all of that up and you're looking at around 2.8% per transaction. On a £100 sale, that's £2.80 gone before you've paid rent.

For a small UK business doing £50K/month in card payments, that's £1,400/month in processing fees. £16,800 a year. Just for moving money from point A to point B.

I kept staring at that number. There had to be a better way.

How Open Banking Actually Works (Developer Edition)

Open banking cuts out the middlemen. No card networks. No interchange. No scheme fees. The money moves directly from the customer's bank account to yours via the UK's Faster Payments rails.

Here's the flow:

Customer → Clicks "Pay by Bank" → Redirected to their bank app
→ Authenticates (biometrics/PIN) → Confirms payment
→ Funds move instantly via Faster Payments → Merchant receives funds

From a developer's perspective, the integration looks like this:

// Initiate a payment via open banking API
const payment = await fetch('https://api.youropenbanking.provider/v1/payments', {
  method: 'POST',
  headers: {
    'Authorization': \`Bearer \${access_token}\`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    amount: {
      currency: 'GBP',
      value: '49.99'
    },
    creditor: {
      account: {
        sortCode: '123456',
        accountNumber: '12345678'
      },
      name: 'Your Business Ltd'
    },
    reference: 'ORDER-2026-0331',
    redirect_url: 'https://yoursite.com/payment/callback'
  })
});

// Response includes a bank authorization URL
const { authorizationUrl, paymentId } = await payment.json();
// Redirect customer to their bank for SCA
window.location.href = authorizationUrl;

The customer gets redirected to their bank, authenticates with Strong Customer Authentication (usually biometrics on their phone), confirms the payment, and gets redirected back. The whole flow takes under 10 seconds.

Cost? Around 0.8%. On that same £100 transaction, you're paying £0.80 instead of £2.80.

That's not an optimisation. That's different economics entirely.

The Developer Experience Gap (And Why It's Closing)

I'll be honest — two years ago, integrating open banking was painful. Multiple bank APIs, inconsistent standards, redirect flows that broke on mobile. Stripe was easier, and "easier" wins in developer land.

That's changed. Fast.

The UK Open Banking Standard (maintained by the OBIE) has matured. Payment Initiation Service Provider (PISP) APIs now follow consistent patterns. You don't need to integrate with each bank individually — providers aggregate the bank connections and give you a single API.

At Atoa, this is exactly what we built. One API. All UK banks. Pay by Link, QR code, eCommerce checkout, even POS terminals. We're FCA-authorised, ISO-27001 and SOC2 certified, because when you're moving money, "it works on my machine" doesn't cut it.

Here's what our integration looks like:

# Create a payment link via Atoa API
curl -X POST https://api.atoa.me/api/v1/payments \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "amount": 49.99,
    "currency": "GBP",
    "description": "Order #2026-0331",
    "redirectUrl": "https://yoursite.com/thanks",
    "customerEmail": "[e-mail]"
  }'

That's it. No card tokenisation. No PCI-DSS scope expansion. No 3D Secure headaches. The customer pays directly from their bank.

What Developers Get Wrong About Open Banking

Myth 1: "Customers won't trust it."
33 million UK adults are already using it. Every major UK bank supports it. The authentication happens inside your own banking app — it's actually more secure than typing card numbers into a web form.

Myth 2: "It's only for big transactions."
Wrong. The fastest growth is in everyday payments. Coffee shops, retail, subscriptions. The flat-fee model makes it more cost-effective for small transactions than cards.

Myth 3: "The UX is worse than cards."
Have you tried Apple Pay recently? Open banking checkout is the same number of taps. Select bank → authenticate → done. No card number entry. No expiry dates. No CVV.

Myth 4: "It's a UK-only thing."
PSD2 covers all of Europe. Open banking frameworks are launching in Brazil, Australia, India (UPI is essentially open banking on steroids), Saudi Arabia, and Nigeria. If you build for open banking now, you're building for the global rails of tomorrow.

The Numbers That Changed My Mind

Let me put this plainly:

Metric	Card Payments	Open Banking
Cost per £100 txn	£2.80 (2.8%)	£0.80 (0.8%)
Settlement time	1–3 business days	Instant
Chargebacks	Yes (costly)	No (irrevocable)
PCI-DSS scope	Full	None
Failed payment rate	5–15% (expired cards)	<2%
Integration complexity	Moderate	Simple (single API)

The chargeback point alone is massive. If you've ever dealt with friendly fraud on card payments, you know how much time, money, and sanity it costs. Open banking payments are irrevocable — once the customer authenticates with their bank, the payment is final.

So Why Hasn't Everyone Switched?

Awareness. That's the honest answer.

Here's a stat that blew my mind: only 38% of UK consumers recognise the phrase "Pay by Bank" — down from 55% in 2025. Usage is up 53%, but brand recognition is falling. The payments industry has a marketing problem, not a technology problem.

And that's actually the opportunity for developers. The infrastructure is ready. The economics are compelling. The UX is mature. What's missing is more developers building with it, more merchants offering it, and more consumers seeing it at checkout.

Getting Started

If you want to try this yourself:

1. Sandbox first: Most open banking providers offer sandbox environments. At Atoa, ours is at docs.atoa.me — you can test payment flows without moving real money.
2. Start with Pay by Link: It's the simplest integration. Generate a link, send it to a customer, they pay. No frontend changes needed.
3. Add to checkout: Once you're comfortable, add a "Pay by Bank" button alongside your card option. A/B test it. Watch the conversion rates.
4. Go deeper: Webhooks for real-time payment notifications, recurring payments via Variable Recurring Payments (VRP), and batch payments for payroll or marketplace payouts.

The docs are at docs.atoa.me/api-reference. If you're on WordPress/WooCommerce, there's a plugin that takes about 5 minutes to set up.

The Bottom Line

Card payments aren't going to vanish overnight. But the trajectory is clear. 53% growth. Instant settlement. 0.8% vs 2.8%. No chargebacks. Simpler compliance.

I'm biased — I've spent the last few years building this. But the numbers aren't biased. They just are.

If you're building payments in the UK and you're still defaulting to cards, you're leaving money on the table. Literally.

Try the sandbox. Run the numbers for your use case. Then decide.

→ docs.atoa.me

---

Arun Rajkumar is Co-Founder & CTO of Atoa, a UK open banking payments platform backed by a16z. He writes about payments, developer experience, and building fintech from India for the UK market. Follow him on X @mickyarun and dev.to/mickyarun.