I've spent UK FinTech Week (April 20–24) reading developer threads about open banking. Same misconceptions every time.
PSD2 is "just OAuth for banks." Payment Initiation Services are "basically a bank transfer." The whole open banking stack is "Stripe with worse DX."
None of that is right. And the gap matters, because the developers carrying these assumptions are the ones building the next wave of UK checkouts. If you're shipping payments code in 2026, here's what I'd want you to know before you write the first line.
1. PSD2 is not OAuth
The flow looks like OAuth. It is not OAuth.
OAuth gives an app permission to read or write data on behalf of a user. PSD2's Payment Initiation Service (PIS) gives a regulated third party — the PISP — the legal right to instruct a payment from the user's bank account, with the bank legally obligated to execute it.
That is a fundamentally different contract.
The bank is not "letting your app do something." The bank is being compelled by regulation to act on a payment instruction from a licensed PISP, after Strong Customer Authentication (SCA) has been completed. The user authenticates inside their banking app — biometrics, PIN, or device binding — and the bank moves the money. No card network. No tokenisation. No 3DS dance.
If you treat PIS like OAuth, you'll over-engineer the consent layer and under-engineer the settlement layer. They're different problems.
2. "Just hit the bank API" is not a real architecture
I see a lot of "we'll integrate directly with each bank's API." Sure. There are 9 CMA9 banks in the UK alone. Add the building societies, the challenger banks, and the EU PSD2 obligations if you're cross-border.
Each bank exposes a slightly different flavour of the Open Banking Standard. Different consent expiry rules. Different ASPSP redirect quirks. Different webhook delivery patterns. Different rate limits.
We learned this the hard way running 15 microservices for UK payment flows. Bank-by-bank integration is not a feature. It is a maintenance liability that grows linearly with every new bank you add and exponentially with every spec revision the OBIE pushes.
The architectural choice is binary: become an FCA-authorised PISP yourself (months of compliance work, a regulated entity, ongoing capital requirements), or integrate against an aggregator who's already done it.
If you're not building a payments company, do not become a PISP. Use one.
3. SCA is not a checkbox
Strong Customer Authentication is the single biggest thing developers underestimate.
You don't add SCA to a payment flow. SCA is the payment flow.
Every payment initiation in the UK requires two of three factors: knowledge (PIN), possession (device), inherence (biometrics). The user has to authenticate inside their bank, on every payment, unless an exemption applies — and the exemption rules are tighter than most teams realise. Low-value contactless. Recurring TPP-managed VRPs. Trusted beneficiaries. That's mostly it.
If your UX assumes "save the bank, charge silently next time" the way Stripe lets you save a card — you're going to ship a flow the bank will block.
This is also why commercial Variable Recurring Payments (cVRP) is the most-watched topic at UK FinTech Week this week. UK Finance proposed the cVRP Wave 2 commercial model earlier this month. cVRP is the legitimate, regulator-blessed answer to "how do I take recurring open banking payments without making the user re-auth every time." It's coming. Build for it.
4. The webhook is the source of truth, not the redirect
This one breaks junior payments code more than anything else.
The user completes authentication in their bank. The bank redirects them back to your redirectUrl. Your app shows "Payment successful."
Wrong. The redirect is a UX hint. It is not a payment confirmation.
The actual payment status — COMPLETED, PENDING, FAILED, CANCELLED — comes from a server-to-server webhook the PISP fires once the bank has settled (or refused) the payment instruction. Sometimes that's instant. Sometimes there's a delay if the bank is doing fraud checks. Sometimes the user closes the browser before the redirect fires but the payment still completes.
If your fulfilment logic depends on the redirect, you will eventually ship orders for payments that never landed, or refuse orders for payments that actually did. We had to retrofit this in our merchant app early on. Webhook-first, redirect-second. Always.
5. Open banking is not "Stripe but cheaper"
I'll be opinionated here because I think the framing matters.
Stripe is a magnificent product. It abstracts card networks beautifully. It is also, structurally, a card-rails product paying Visa and Mastercard interchange on every transaction. That's why UK card processing costs sit at 1.5–2.9%. The interchange is a tax built into the rail.
Open banking is a different rail. There is no interchange. The money moves over Faster Payments (UK) or SEPA Instant (EU). The cost structure is fundamentally different — flat fee, not percentage. Atoa is roughly half the cost of cards because we're not paying Visa for the privilege of moving the money.
The right mental model is not "Stripe alternative." It is "second payment rail, with different economics, different latency, different UX, different fraud profile, different settlement guarantees."
For high-ticket B2B invoices, open banking is dramatically better. For impulse e-commerce, cards still win on conversion friction. For UK SaaS doing recurring billing, cVRP is about to flip the calculus. Pick the rail that fits the use case. Don't pick the rail that fits last year's mental model.
TL;DR for developers shipping in 2026
PSD2 is not OAuth. Don't integrate banks directly. SCA isn't optional. Webhooks are the source of truth. Open banking is its own rail, not a Stripe replacement.
If you're at UK FinTech Week this week and want to see this in code, the Atoa sandbox takes 5 minutes to set up. We've spent years getting the integration down to a single API call so you don't have to relearn what we already did wrong.
Try it: docs.atoa.me
What's the misconception about open banking you keep hearing from your engineering team?
Arun Rajkumar is Co-Founder & CTO of Atoa, an FCA-authorised UK open banking payments platform. He writes about CTO lessons, microservices, and what we're learning building a payments rail outside the card networks.
Top comments (0)