You've integrated Stripe. You've wired up PayPal. You've copy-pasted card tokenisation code from Stack Overflow at 2am.
But have you ever looked at what happens when a customer pays directly from their bank account — no card network, no Visa, no Mastercard — just a bank-to-bank transfer that settles in seconds?
That's open banking. And if you're building for the UK market, you need to understand how it works under the hood. Not the marketing version. The API version.
The Architecture in 30 Seconds
Open banking in the UK follows a simple three-party model:
ASPSP (Account Servicing Payment Service Provider) — the customer's bank (Barclays, Monzo, Revolut, etc.)
TPP (Third Party Provider) — that's you (or the payment platform you integrate with)
Open Banking Directory — the trust layer that verifies everyone is who they say they are
When a customer initiates a payment, the flow looks like this:
Your App → TPP (e.g. Atoa) → Open Banking API → Customer's Bank → Auth (SCA) → Payment Executed
Every connection is secured with mutual TLS certificates and OAuth 2.0. The Open Banking Directory acts as the certificate authority. If you're not in the directory, you don't get to play.
The Payment Initiation Flow (PISP)
Here's what actually happens when you trigger an open banking payment. I'll walk through it step by step because this is where most developers get confused.
Step 1: Create a Payment Consent
Before you can move money, you need consent. This isn't a form checkbox — it's a structured API request that tells the bank exactly what's about to happen.
POST /open-banking/v3.1/pisp/domestic-payment-consents
{
"Data": {
"Initiation": {
"InstructionIdentification": "ACME-PAY-001",
"EndToEndIdentification": "E2E-REF-12345",
"InstructedAmount": {
"Amount": "49.99",
"Currency": "GBP"
},
"CreditorAccount": {
"SchemeName": "UK.OBIE.SortCodeAccountNumber",
"Identification": "11223312345678",
"Name": "ACME Coffee Ltd"
}
}
},
"Risk": {
"PaymentContextCode": "EcommerceGoods"
}
}
The bank returns a ConsentId\. You'll need this for the next step.
Step 2: Redirect for Strong Customer Authentication (SCA)
This is the part that trips up developers coming from card-land. There's no "enter your card number" form. Instead, you redirect the customer to their bank's authentication page.
GET https://auth.bank.co.uk/authorize?
response_type=code
&client_id=your-tpp-client-id
&redirect_uri=https://yourapp.com/callback
&scope=payments
&state=random-csrf-token
&request=<signed-JWT-with-consent-id>
The customer logs into their bank. Approves the payment. Gets redirected back to your app with an authorization code. Standard OAuth 2.0 — nothing exotic.
Step 3: Execute the Payment
Exchange the auth code for an access token, then hit the payment execution endpoint:
POST /open-banking/v3.1/pisp/domestic-payments
Authorization: Bearer <access-token>
{
"Data": {
"ConsentId": "58923",
"Initiation": { /* same as consent */ }
}
}
That's it. The bank debits the customer. The money lands in the merchant's account. No interchange fee. No scheme fee. No acquirer. No gateway skimming a percentage.
Why This Matters (The Developer Economics)
Here's the part I care about as a CTO running a payments company.
Card payments involve four intermediaries, each taking a cut. Open banking has one: the payment initiation service. At Atoa, we charge roughly half what card processors do. That's not a marketing claim — it's structural. When you remove Visa and Mastercard from the equation, the cost drops.
For developers, the integration is actually simpler than cards. No PCI-DSS compliance headaches. No storing card numbers. No dealing with 3D Secure failures. The bank handles all the authentication.
The Even Simpler Path: Using a Payment API
Now, you could register as a PISP with the FCA, get your certificates, integrate with every UK bank individually, and handle all the consent management yourself.
Or you could use a payment initiation API that abstracts all of that.
Here's what a payment request looks like with Atoa's API:
curl -X POST https://api.atoa.me/api/payments/process-payment \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"amount": 49.99,
"currency": "GBP",
"reference": "Order-12345",
"redirectUrl": "https://yourapp.com/payment-complete",
"customerEmail": "[email protected]"
}'
Five fields. One API call. The customer gets redirected to their bank, authenticates, and the payment is done. You get a webhook when the money lands.
No card numbers to tokenise. No PCI audit. No 3D Secure fallback logic.
What's Coming: Variable Recurring Payments
Here's what's got me excited right now. The first wave of commercial Variable Recurring Payments (cVRPs) went live in Q1 2026. This is the open banking equivalent of Direct Debits — but better.
With cVRPs, a customer authorises a payment mandate once, and you can collect future payments within agreed limits without redirecting them to their bank every time. Think subscription billing, utility payments, or regular top-ups — all via bank transfer, no card-on-file needed.
The FCA and PSR are watching adoption closely. By end of 2026, they'll evaluate whether industry-led cVRP adoption needs regulatory nudges. If you're building subscription infrastructure for the UK market, this is the API to watch.
The TL;DR for Developers
Open banking payments are OAuth 2.0 + bank redirects. If you've built a "Login with Google" flow, you understand 70% of it.
No card data means no PCI-DSS scope. Your security surface shrinks dramatically.
Settlement is near-instant. No T+2 waiting for card settlements.
Costs are structurally lower. No interchange, no scheme fees.
VRPs are the next frontier. Recurring bank payments without the friction of Direct Debit mandates.
If you want to try it yourself, Atoa has a sandbox environment where you can test the full payment flow without moving real money. The API docs are at docs.atoa.me — the payment initiation endpoint is the one you want to start with.
Build something. Break something. Ship it.
Arun Rajkumar is Co-Founder & CTO of Atoa, a UK open banking payments platform. He writes about payments infrastructure, developer experience, and building fintech from India for the UK market. Follow him on X @mickyarun.
SOCIAL SHARE CARD GENERATOR