DEV Community

arun rajkumar
arun rajkumar

Posted on

How Open Banking APIs Actually Work — A Developer's Guide

#openbanking #api #fintech #webdev

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:

  1. ASPSP (Account Servicing Payment Service Provider) — the customer's bank (Barclays, Monzo, Revolut, etc.)
  2. TPP (Third Party Provider) — that's you (or the payment platform you integrate with)
  3. 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
Enter fullscreen mode Exit fullscreen mode

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"
  }
}
Enter fullscreen mode Exit fullscreen mode

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>
Enter fullscreen mode Exit fullscreen mode

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 */ }
  }
}
Enter fullscreen mode Exit fullscreen mode

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": "customer@example.com"
  }'
Enter fullscreen mode Exit fullscreen mode

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

  1. Open banking payments are OAuth 2.0 + bank redirects. If you've built a "Login with Google" flow, you understand 70% of it.
  2. No card data means no PCI-DSS scope. Your security surface shrinks dramatically.
  3. Settlement is near-instant. No T+2 waiting for card settlements.
  4. Costs are structurally lower. No interchange, no scheme fees.
  5. 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.

Top comments (1)

Collapse
 
johnfrandsen profile image
John Frandsen •

Great writeup Arun — the OAuth 2.0 + SCA walkthrough is the cleanest I've seen for the PISP flow, and the consent → redirect → execute decomposition is exactly how I explain it to engineers new to the rails.

One thing I'd add for developers weighing "build vs. use an aggregator": the reason almost nobody goes direct, even when the API surface is this well-defined, is the certificate + authorisation tax, not the integration itself.

Concretely, to call UK bank APIs directly as a TPP you need:

  • An FCA AISP/PISP authorisation (6–12 months, several thousand pounds in reg fees, plus capital adequacy and a compliance function)
  • An eIDAS QWAC + QSeal certificate pair from an accredited QTSP (€5,000–15,000/year, renewed annually)
  • OB Directory sandbox + production onboarding, per-bank testing, and per-bank production access requests

That's why Plaid, Tink, TrueLayer, GoCardless, Atoa, and similar aggregators exist — they amortise those fixed costs across thousands of merchants. You pay them 10–40bps instead of paying €15k/yr and waiting a year. For most use cases that's the right trade.

Two practical nuances that also bite:

  1. Standards divergence. The UK OB standard is excellent and well-enforced, but the moment you extend to the EU you're into Berlin Group NextGenPSD2 — same bones, different field names, consent models and SCA approaches per bank. "Integrate once" holds within a single regulator, not across them.
  2. Bank API consistency. Even in the UK, banks honour the spec to varying degrees — error codes, consent expiry behaviour, and rate limits all differ. That's what aggregator SDKs are quietly papering over.

For experimenting or building POCs without going through authorisation, a few cert-free options exist — open-banking.io (which I maintain) is one; it's aimed at letting devs hit sandbox flows without the QWAC overhead. Useful for understanding the rails before committing to a real TPP contract.

Curious what you're seeing on cVRP adoption numbers — the Q1 2026 launch has felt undermarketed so far.
aimed at letting devs hit sandbox flows without the QWAC overhead. Useful for understanding the rails before committing to a real TPP contra