DEV Community: arun rajkumar

We Built an Open-Source Coding Exam Platform Because Every Vendor Let Us Down

arun rajkumar — Sat, 11 Apr 2026 01:05:35 +0000

Every year, our team visits engineering colleges across India to hire freshers. The first round is always an online coding test — 300+ students, one shot at finding the ones who can actually think.

We tried Coderbyte. Fifty concurrent user limit. So we'd split students into batches, stagger timings, juggle schedules between college coordinators and our engineers.

We tried HackerRank's community edition. Different tool, different headache.

Every vendor had a ceiling — concurrency limits, inflexible problem formats, generic DSA questions that tested memorization over problem-solving. And the pricing? Designed for companies ten times our size.

I was ranting about this to my engineering team. Out loud. In our standup. Trying to find yet another vendor to evaluate.

My engineers — most of them freshers themselves just a couple years ago — went quiet. Said nothing for a few days.

Then they shipped a product. Two engineers. One weekend. AI-assisted development. And two days of intensive testing before it went live.

What They Built

A full-stack, self-hosted coding exam platform. Not a toy. Not a prototype. A production system we ran 300+ students through this hiring season.

Here's what's under the hood:

Monaco Editor — the same engine that powers VS Code. Syntax highlighting, autocomplete, multi-language support. Students write real code, not paste answers into a textarea.

Judge0 Sandboxed Execution — every submission runs inside a sandboxed Judge0 instance. Test cases execute in parallel with automatic batching. Students get instant, per-test-case verdicts.

ICPC-Style Scoring — not just pass/fail. Penalty points for wrong attempts. Time-based ranking. Race-condition-safe writes to the database. The leaderboard feels like a competitive programming contest, not a homework checker.

Live Leaderboard — backed by a PostgreSQL materialized view that refreshes after every accepted submission. O(1) rank queries. Students watch themselves climb in real-time.

API-Based Challenges — beyond traditional stdin/stdout problems, we built support for API-format challenges where students interact with real endpoints. This lets us test how candidates think about integration, not just algorithms.

Server-Synced Timer — the countdown runs on server time, not the client clock. No inspect-element tricks. Configurable start/end windows with server-enforced access guards.

Autosave — code drafts are debounce-saved to the server every few seconds. Browser crash? Tab closed? The student picks up right where they left off.

White-Label Ready — app name, logo, brand colors, copyright — all configurable via environment variables. Zero code changes. We use it as our own branded platform; anyone can make it theirs.

Architecture at a Glance

The platform is a monorepo with two core applications:

client/   → Vue 3 SPA (student exam UI + admin panel)
server/   → NestJS REST API (auth, exam logic, code execution, scoring)

In production, the server compiles and serves the client's static build directly — no separate web server or CDN needed.

The submission flow works like this:

Student writes code in the Monaco editor and hits Submit
The Vue client POSTs to the API with the code and language
The SubmissionsService fetches all test cases and sends batch requests to Judge0, automatically chunking to stay within limits
The server polls Judge0 tokens until all results resolve
The ScoringService applies the ICPC penalty formula and updates the score using a pessimistic database lock
The LeaderboardService refreshes the materialized view
Results return to the client with per-test-case verdicts and an updated leaderboard

All of this happens in seconds, even under load.

The Tech Stack

Frontend: Vue 3 (Composition API), Vite 8, TypeScript 5.9, Pinia 3 for state, Monaco Editor 0.55, Brotli compression

Backend: NestJS 11, TypeScript 5.7, TypeORM 0.3, Passport JWT, Swagger/OpenAPI docs, rate limiting via @nestjs/throttler

Database: PostgreSQL 17 for the application, PostgreSQL 16 + Redis 7.2 for Judge0's internal queue

Infrastructure: Docker Compose orchestrates six services — app, app-db, judge0-server, judge0-worker, judge0-db, and judge0-redis. Multi-stage Dockerfile produces a minimal Node 22-alpine image running as a non-root user.

Features That Matter

Here's what we built because we needed it, not because a product manager spec'd it:

Multiple concurrent exams — run several exams at once; students pick which to enter
Mixed formats — MCQs alongside coding problems in the same exam
Admin panel — create exams, duplicate them, manage problems with visible/hidden test cases, configure weights
Safe Exam Browser detection — a composable detects whether students are in a locked-down browser
Built-in API docs — interactive API reference baked right into the student UI for API-format challenges
QA role opt-in — students can flag interest in QA engineering during registration
Run mode — execute code against sample inputs without scoring; lets students experiment before committing

Why Open Source?

We're a fintech startup. Thirty-odd people. We didn't build this to sell it.

We built it because we were tired of bending our hiring process around someone else's product limitations. And once we had it, we realized every small company visiting colleges faces the exact same problem.

Here's the thing that makes this story worth telling: two engineers built this in a weekend, with AI doing the heavy lifting on scaffolding, boilerplate, and iteration. Then two days of intensive testing to harden it for production. That's the power of AI-assisted development — it doesn't replace engineers, it turns two of them into ten.

In the AI era, expensive hiring software shouldn't be a gate that keeps small teams from finding great talent. If two engineers with AI tools can build a platform that handles 300+ concurrent students with ICPC scoring and sandboxed execution in a weekend, there's no reason that capability should be locked behind enterprise pricing.

The whole thing is AGPL-3.0 licensed. Fork it, brand it, run it on your own infrastructure — just keep your modifications open too.

Getting Started

The fastest path is Docker Compose:

cp .env.example .env
# Set DB_PASSWORD, JWT_SECRET, ADMIN_SETUP_KEY
docker compose up --build

Six services start in dependency order. The app waits for the database health check, runs migrations automatically, and you're live.

For local development without Docker, you'll need PostgreSQL 17 and a Judge0 instance. The README walks through every step — database creation, migrations, environment variables, and running the frontend and backend separately.

What's Next

We're cleaning up a few things before the public launch:

Finishing the test suite (Jest is installed and configured, specs are being added)
Polishing the contributor docs
Adding a demo mode so people can try it without setting up Judge0

If you're interested, follow me here — I'll drop the GitHub link as soon as the repo goes public.

The Bigger Lesson

I went looking for a vendor. My team handed me a product.

Two engineers. One weekend of building. Two days of intensive testing. Powered by AI-assisted development. A platform that replaced two commercial tools and produced measurably better candidate quality in round two.

That's what happens when you hire people for intent over resumes — and then get out of their way.

Built with Vue 3, NestJS, PostgreSQL, Judge0, and a healthy disregard for vendor lock-in.

Star the repo when it drops. Or better yet — fork it and run your own hiring season on it.

Open Banking Was Built for the Wrong Future — and That's Why It's Perfect for AI Agents

arun rajkumar — Tue, 07 Apr 2026 19:35:42 +0000

Visa announced infrastructure for AI agents to make payments without asking you first.

GoCardless shipped an MCP server in February so developers can talk to their payment platform in natural language.

I build open banking payment infrastructure for the UK. I've been watching both of these announcements very closely.

And I have a counterintuitive take: the payment rail everyone called "too complicated for normal users" might be the only one that actually works for AI agents.

The Problem With Cards and AI Agents

When an AI agent needs to make a payment on your behalf, the obvious infrastructure is what already exists. Cards. Stored credentials. The same rails your Netflix subscription uses.

Here's the problem.

Card authorisation is broad. When you give Stripe a card token, you're essentially giving that token permission to charge whatever you've authorised — subject to 3DS, fraud rules, and limits. But the authorisation scope isn't bound to a specific action.

For an AI agent, that's dangerous.

You want an agent to book a flight. It has your card token. Nothing technically stops it from booking the wrong flight, adding seat upgrades you didn't ask for, or — if the prompt is maliciously crafted — doing something you absolutely didn't intend.

Visa understands this. Their Trusted Agent Protocol exists precisely to solve it: a way for merchants to verify that an agent is legitimate and acting within its authorised scope. It's clever engineering. But it's being bolted onto rails that weren't designed for it.

Open banking wasn't designed for AI agents either. But its constraints happen to be exactly the right shape.

What Open Banking Consent Actually Looks Like

When a customer pays via open banking — the way Atoa processes payments — here's what actually happens under the hood:

1. Merchant creates a payment consent object
   → amount: £49.99
   → merchant: Atoa test merchant
   → purpose: "Coffee subscription - April"

2. Customer is redirected to their bank
   → Bank shows: "Atoa wants to take £49.99 from your account"
   → Customer approves or declines
   → Bank issues a single-use authorisation code

3. Atoa exchanges the code for the payment
   → One payment. Specific amount. Specific purpose.
   → The authorisation is consumed. It cannot be reused.

Every payment is its own consent event. Every consent is scoped to a specific amount and purpose. You can't overcharge. You can't quietly add extras. You can't reuse the authorisation.

For a human user, this is friction. That's why open banking adoption was slow. Nobody wants to log into their banking app every time they buy something.

For an AI agent, this friction is a feature.

Why the Consent Model Fits AI Agents

Think about what you actually want when an AI agent makes a payment on your behalf.

You want:

It to charge exactly the amount you authorised
The scope to be limited to what you asked it to do
The ability to revoke access without cancelling your card
A clear audit trail showing what was authorised and when
The payment to fail loudly if anything is out of scope — not silently proceed

Open banking gives you all of that by default.

Cards give you none of it by default, and you have to engineer it in.

The FCA even made it better recently. They removed the 90-day re-authentication requirement that was causing 20-40% customer drop-off for third-party payment providers. Persistent consent — once granted to an agent — can now remain valid without forcing a re-authentication loop.

That's a massive unlock for agentic payment flows.

The Real Engineering Challenge: Consent Lifecycle for Agents

Here's where it gets genuinely hard.

When a human completes an open banking payment, the flow is synchronous: they go to the bank, they approve, they come back. Done.

When an AI agent initiates a payment, the flow might look like this:

User: "Book the Bangalore to London flight if the price drops below £600"

Agent: [Monitors prices for 3 days]
Agent: [Price hits £598 on a Wednesday morning]
Agent: [Attempts to initiate payment]
         → But the user's open banking consent was granted for a specific session
         → That session token expired 6 hours ago
         → Payment fails

Result: Agent missed the window. User wakes up to a "couldn't book your flight" message.
        Price is now £640.

Consent that's synchronous and session-bound doesn't work for agents that act asynchronously.

This is the real engineering problem. Not "can AI agents make payments?" — they clearly can. But "what does the consent model look like for an agent that might act hours or days after the user gave permission?"

There are a few approaches:

Option 1: Pre-authorised payment mandates
Open banking supports Variable Recurring Payments (VRPs) — essentially mandates where the user sets a maximum amount and time window, and the payment provider can initiate within those bounds without re-authentication.

// Conceptual structure of a VRP mandate for an agent
interface AgentPaymentMandate {
  agentId: string;
  maxAmountPence: number;      // Agent cannot exceed this
  validUntil: Date;           // Time-bounded consent
  allowedMerchants: string[]; // Scope: only these merchants
  purpose: string;            // What this mandate is for
  requiresConfirmation: boolean; // Some actions still need approval
}

The agent operates within a pre-defined envelope. The user sets the boundaries once. The agent acts within them.

Option 2: Payment intent + human gate
Agent identifies a payment opportunity, creates a payment intent, notifies the user. User approves in one tap. Agent executes.

This is the pattern we're building toward at Atoa — merchant describes what they need in natural language, agent proposes the payment, human approves in one tap, open banking rails execute it.

// What an agent workflow might look like
const intent = await paymentAgent.proposePayment({
  merchant: 'flight-booking-service',
  amount: 59800, // £598.00 in pence
  reason: 'BLR→LHR flight, price hit target of £600',
  expiresAt: new Date(Date.now() + 30 * 60 * 1000), // 30 min window
});

// User gets notified: "Your agent wants to book your flight for £598. Approve?"
// One tap. Payment executes.

Option 3: Programmatic consent with audit trail
For fully autonomous agents — the Visa Intelligent Commerce model — the agent holds delegated credentials scoped to specific actions, with every payment logged against the authorisation that permitted it.

We're not here yet in open banking. But the architecture exists to get there.

What We're Thinking About at Atoa

We build open banking payment infrastructure. POS terminals, payment links, invoicing, online checkouts. Everything goes through bank payment rails.

We're thinking about this differently to most — our payment surfaces each have different agent-readiness, and that's shaped how we're approaching the consent problem. When Visa announced Intelligent Commerce, our first question wasn't "can we compete with this?" It was: "which of our surfaces are ready right now, and which ones need the architecture to change?"

Here's our honest assessment:

Pay by Link — probably the most agent-ready thing we have. An agent could generate a payment link, send it to a customer, and monitor completion. The consent event is triggered by the link recipient, not the agent. The agent just facilitates.

Payment Pages — also strong. A merchant's agent could build and publish a payment page with specific parameters. No card infrastructure needed.

POS Terminal — hardest. The consent flow requires physical presence for SCA. An agent isn't physically present. This one needs new thinking.

Invoicing — interesting. An agent managing a merchant's books could issue invoices and track payment status. The open banking payment confirmation is machine-readable. This is real today.

The shape of "agentic commerce" looks different for each surface. There's no one-size-fits-all answer.

The Question Every Open Banking Developer Should Be Asking

GoCardless shipping an MCP server tells you something important: payment infrastructure companies are now thinking about developers' AI workflows as a first-class use case.

Not just "can humans use our API?" but "can an AI agent use our API safely?"

That's a different design question. An API designed for humans assumes there's a human reading error messages, handling edge cases, making judgment calls. An API designed for agents needs those things to be machine-readable, scoped, and predictable.

Open banking has a head start here. The consent model is explicit. The amounts are bounded. The authorisation chain is auditable. Every payment has a "why" attached to it.

The engineers who figure out the consent lifecycle problem — how do you grant an agent payment permissions that are time-bounded, amount-bounded, and purpose-bounded, without requiring the human to be present at the moment of execution — will be building the infrastructure that the next decade of agentic commerce runs on.

That's the problem I'm thinking about.

What's your take — does the card world catch up to open banking here, or does the consent model give open banking a structural advantage in the agent era?

Arun Rajkumar is CTO & Co-Founder of Atoa, an FCA-authorised open banking payments platform in the UK. He writes about payments, fintech engineering, and building for the UK from India. @mickyarun

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

arun rajkumar — Wed, 01 Apr 2026 15:41:55 +0000

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

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.

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

arun rajkumar — Tue, 31 Mar 2026 18:01:30 +0000

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:

Interchange fee → goes to the card-issuing bank (0.2–0.3% for UK debit, 0.3% for credit)
Scheme fee → goes to Visa or Mastercard (0.02–0.15% plus per-transaction)
Acquirer fee → goes to your payment processor
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": "customer@example.com"
  }'

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:

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.
Start with Pay by Link: It's the simplest integration. Generate a link, send it to a customer, they pay. No frontend changes needed.
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.
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.

How We Built Atoa's Payment Infrastructure with 15 NestJS Microservices (And What Took the Most Figuring Out)

arun rajkumar — Wed, 25 Mar 2026 05:44:58 +0000

Open banking in the UK just crossed 24 billion successful API calls in 2025. Payment initiation grew 53% year-on-year. That's not a trend — that's a tectonic shift.

We've been building in this space for years now. Atoa processes open banking payments for UK merchants — Pay by Link, QR codes, POS terminals, online checkouts. Half the cost of card payments. Instant settlement. No Visa or Mastercard in the middle.

And our entire payment infrastructure runs on 15 NestJS microservices.

Here's what we got right. And what took the most figuring out.

Why NestJS for Payments

When I started architecting Atoa's backend, the decision came down to two things: developer velocity and reliability.

We were a small team. Mostly freshers and interns — people I'd bet on because of intent, not because of their resume. One of our earliest hires joined as a fresher. Five years later, he's our Technology Architect making every major tech decision. Another started as an intern. He coded our Open Banking module end-to-end.

These people needed a framework that was opinionated enough to enforce structure but flexible enough to let them move fast. NestJS gave us that. Decorators, dependency injection, modular architecture — it reads like a blueprint, not spaghetti.

We chose TypeScript everywhere. Zod for runtime validation. If a payment request hits our API with a malformed amount or missing merchant ID, it dies at the gate. In payments, a silent failure isn't a bug — it's someone's revenue disappearing.

The 15-Service Architecture

Here's a simplified view of our service boundaries:

┌─────────────────────────────────────────────┐
│                API Gateway                   │
│            (Traefik v3 + Auth)               │
└──────────┬──────────┬──────────┬────────────┘
           │          │          │
    ┌──────▼──┐ ┌─────▼────┐ ┌──▼──────────┐
    │ Payment │ │ Merchant │ │ Notification │
    │ Service │ │ Service  │ │   Service    │
    └──────┬──┘ └──────────┘ └─────────────┘
           │
    ┌──────▼──────────────────────────────┐
    │        Open Banking Gateway          │
    │  (Bank API adapters, token mgmt,     │
    │   consent flows, SCA handling)       │
    └──────┬──────────────────────────────┘
           │
    ┌──────▼──┐ ┌──────────┐ ┌────────────┐
    │ Ledger  │ │ Webhook  │ │ Settlement │
    │ Service │ │ Service  │ │  Service   │
    └─────────┘ └──────────┘ └────────────┘

Each service owns its domain. The Payment Service doesn't know how settlements work. The Merchant Service doesn't touch bank APIs. Clean boundaries.

We use Traefik v3 as our API gateway — routing, rate limiting, TLS termination, health checks. It plays beautifully with Docker and our Kubernetes setup. Our DevOps lead (Kubestronaut certified, by the way) architected the infra. The only downtime we've ever had? AWS London went down during the UK heatwave about two years ago. That wasn't on us. Everything else — 100% uptime.

The Hard Part: Every Bank is Different

Here's what the "open banking is easy" crowd doesn't tell you.

Every UK bank implements authentication differently. What works in sandbox breaks in production. Extra consent screens. Different redirect logic. Strong Customer Authentication flows that behave one way on mobile, another on desktop.

We built an adapter layer inside our Open Banking Gateway. Each bank gets its own adapter that normalises the authentication flow into a consistent interface. When a merchant's customer pays via Atoa, they don't know (or care) that Barclays handles redirects differently than Monzo.

// Simplified bank adapter pattern
interface BankAdapter {
  initiatePayment(params: PaymentInitParams): Promise<ConsentUrl>;
  handleCallback(bankResponse: unknown): Promise<PaymentResult>;
  getPaymentStatus(paymentId: string): Promise<PaymentStatus>;
}

// Each bank gets its own implementation
class BarclaysAdapter implements BankAdapter {
  async initiatePayment(params: PaymentInitParams) {
    // Barclays-specific consent flow
    // Handles their unique SCA requirements
    const validated = PaymentInitSchema.parse(params); // Zod validation
    // ... bank-specific logic
  }
}

This adapter pattern saved us hundreds of hours. New bank? New adapter. Same interface. No touching the Payment Service.

What Took the Most Figuring Out: Local Development

Fifteen microservices. Each with its own database connection, environment variables, and dependencies. Onboarding a new developer used to take two weeks. Two weeks of "why isn't this service connecting" and "which env file do I need."

We fixed this. I wrote about it in detail on dev.to — how we went from 2 weeks to 1 day for developer onboarding. The short version: Docker Compose orchestration, shared environment templates, and a single make dev command that spins up the entire stack.

One of our developers joined with a B.Sc and "Googling" as his only listed skill. He was shipping code within days, not weeks. That's the real test of your developer experience. Not whether your senior architect can navigate it. Whether someone brand new can.

Lessons for Developers Building Payment Systems

1. Validate at every boundary. Zod on the API layer. Zod between services. Payments don't forgive data inconsistencies.

2. Idempotency is not optional. Network retries happen. Bank callbacks come twice. Every payment mutation needs an idempotency key. We learned this the hard way.

3. Treat webhooks as first-class citizens. Merchants need real-time payment status. We built a dedicated Webhook Service with retry logic, dead-letter queues, and delivery receipts. It's not glamorous. It's essential.

4. Abstract your bank integrations. The adapter pattern isn't clever engineering — it's survival. Banks change APIs. New banks join. Your payment logic should never care.

5. Invest in local dev early. The time you save on onboarding compounds. Every developer you hire benefits. Every feature ships faster.

Why Open Banking Over Cards

I'll be direct. If you're building a payment flow for the UK market in 2026, you should seriously consider open banking.

Card payments: ~1.5-2.5% processing fees, T+2 settlement, chargebacks, PCI-DSS compliance overhead.

Open banking via Atoa: lower fees, instant settlement, no chargebacks (because the customer authenticates with their bank), and simpler compliance.

We're FCA-authorised. ISO-27001 and SOC2 certified. We have SDKs for Flutter (atoa_sdk, atoa_flutter_sdk), a Vue-based Web Client SDK, a WooCommerce plugin, and full API docs at docs.atoa.me.

If you want to test it yourself: docs.atoa.me/api-reference/Payment/process-payment. Sandbox is free. Takes about 10 minutes to get your first payment flowing.

What's Next

We're investing heavily in AI-assisted code migration and developer tooling. The 15-service architecture is growing. But the principles stay the same: clean boundaries, validate everything, and build for the developer who joins tomorrow, not just the one who built it yesterday.

If you're building in payments — especially in the UK open banking space — I'd love to hear how you're approaching it. Drop a comment or find me on X: @mickyarun.

We Had 15 Microservices and It Took 2 Weeks to Onboard a Developer. Here's How We Fixed It in a Weekend.

arun rajkumar — Tue, 24 Mar 2026 07:29:26 +0000

How we went from "ask someone for the .env" to one-click local development for our entire microservice stack.

If you're running microservices, you've probably been here:

A new developer joins. You point them at the repos. Then begins the ritual. Clone this. Run migrations on that. Ask Slack for the latest .env. Debug why nginx isn't routing. Realize they're on Node 20 but this service needs Node 23. Spend two hours figuring out why the queue consumer isn't connecting.

Two weeks later, they write their first line of actual code.

We had 15 NestJS microservices. Each with its own repo, its own .env, its own database schema, migrations, queues, and inter-service dependencies. Every developer had their own frankensteined local setup — commented-out code, hardcoded URLs, an nginx config held together with hope.

Integration testing? People just tested directly against the shared dev database. New joiners spent their first week or two just getting things running.

I'm the CTO. I'm hands-on, but lately I only code two or three times a month. The last time I tried to pick up a feature, I had to pull the code, run migrations, ask someone for the latest env vars, debug why things weren't connecting, fix my local nginx config — and by the time I had a working setup, I'd lost half a day and gotten pulled into something else.

That weekend, I decided to fix this. For everyone. Forever.

The Problem Isn't Microservices. It's Environment Chaos.

Here's what we found when we audited our 15 repos:

1. Env variable naming was a mess. The same database connection string was called DB_HOST in one repo, DATABASE_HOST in another, and POSTGRES_HOST in a third. Some were just plural changes — QUEUE_URL vs QUEUES_URL. One service used DB_HOST_CREDENTIALS for a secondary database, another used DB_HOST_CREDENTIAL (singular). Multiply this across 15 repos and you get a combinatorial nightmare.

2. No single source of truth. Each repo had its own .env.example that was perpetually outdated. Developers copied .env files from each other over Slack. Some had AWS credentials hardcoded. Others had localhost URLs that only worked on one person's machine.

3. Node version drift. Some services were on Node 20, others on Node 23. The package.json didn't enforce this, so things would break silently.

4. AWS services in local dev. Some services connected to real AWS SQS queues locally. Others mocked them. There was no standard.

5. Nginx configuration hell. Every developer maintained their own nginx config to route between services. One person's config looked nothing like another's. New joiners spent days getting this right.

Step 1: A Shared Env Schema with Zod (The Hard Part)

The first thing we built was a centralized env schema package — a single source of truth for every environment variable across all services.

Sounds simple. It wasn't.

We had to map every .env file across 15 repos, find the overlaps, resolve the naming conflicts, and split variables into shared building blocks and service-specific schemas.

This is where AI agents saved us hours. I spawned multiple agents to do a retrospective across all repos — mapping every env variable, finding common ones, identifying naming conflicts, and generating a unified schema. What would have taken a team days of grep-and-spreadsheet work took a couple of hours.

The result: a shared npm package using Zod for runtime validation. Here's the actual pattern:

// shared.schema.ts — Reusable building blocks
import { z } from 'zod';

export const DatabaseConfigSchema = z.object({
  DB_HOST: z.string().default('localhost'),
  DB_PORT: z.coerce.number().default(5432),
  DB_USER: z.string().default('postgres'),
  DB_PASSWORD: z.string(),
  DB_NAME: z.string(),
});

export const RedisConfigSchema = z.object({
  REDIS_HOST: z.string().default('localhost'),
  REDIS_PORT: z.coerce.number().default(6379),
  REDIS_PASSWORD: z.string().optional(),
});

export const QueueConfigSchema = z.object({
  SQS_ENDPOINT: z.string().default('http://localhost:9324'),
  SQS_REGION: z.string().default('us-east-1'),
  AWS_ACCESS_KEY_ID: z.string().default('local'),
  AWS_SECRET_ACCESS_KEY: z.string().default('local'),
});

export const JWTConfigSchema = z.object({
  JWT_SECRET: z.string(),
  JWT_ACCESS_TOKEN_EXPIRY: z.string().default('15m'),
});

export const InterServiceAuthSchema = z.object({
  INTER_SERVICE_SECRET: z.string(),
});

// Base schema every backend service inherits
export const SharedBackendSchema = z.object({
  NODE_ENV: z.enum(['dev-local', 'dev', 'uat', 'production']),
  PORT: z.coerce.number(),
}).merge(DatabaseConfigSchema)
  .merge(RedisConfigSchema)
  .merge(JWTConfigSchema);

Each service composes its schema from these shared blocks:

// services/payments.schema.ts
export const PaymentsEnvSchema = SharedBackendSchema
  .merge(QueueConfigSchema)
  .merge(InterServiceAuthSchema)
  .merge(z.object({
    PAYMENT_PROVIDER_API_KEY: z.string(),
    PAYMENT_ENCRYPTION_KEY: z.string(),
    WEBHOOK_SIGNING_SECRET: z.string(),
  }));

The key insight: composition via .merge(). When we renamed DATABASE_HOST to DB_HOST, we only changed it in one place. Every service that imports DatabaseConfigSchema gets the fix automatically.

We published this as an internal npm package. Each service declares it as a dependency and validates on startup:

// Any service's index.ts
import { validateEnv } from '@company/env-schema';

const env = validateEnv('payments');
// Throws with clear error messages if anything is missing
// Returns a frozen, type-safe env object

Environment-aware strictness was crucial. In dev-local mode, missing optional vars log warnings but don't block startup — so developers can run just the services they need. In dev, uat, and production, missing required vars call process.exit(1). No silent failures in deployed environments.

Step 2: Auto-Generate .env Files (The CLI)

Having a schema is useless if developers still have to manually create .env files. So we built a CLI that generates them:

# Generate .env for all 15 services
npx env-schema init --all --base-path ~/code

# Generate for a single service
npx env-schema init --service payments

# Preview without writing
npx env-schema init --service payments --stdout

The generator:

Fills in safe local defaults (localhost URLs, local Redis passwords, sandbox API keys)
Reuses shared secrets across services (same JWT secret, same inter-service auth token)
Comments out optional fields so developers know they exist
Is idempotent — safe to re-run, merges new keys without overwriting existing values

No more Slack messages asking "can someone send me the .env for the notification service?"

Step 3: Prevent Future Drift (The Regex Scanner)

Fixing the current mess was one thing. Preventing it from coming back was another.

We built a drift checker that scans source code for process.env references and compares them against the schema registry:

// check-drift.ts — simplified version
function extractEnvVars(filePath: string): string[] {
  const content = fs.readFileSync(filePath, 'utf-8');
  const matches = [
    ...content.matchAll(/process\\.env\\.(\\w+)/g),
    ...content.matchAll(/process\\.env\\['(\\w+)'\\]/g),
  ];
  return matches.map(m => m[1]);
}

function checkDrift(serviceId: string) {
  const schemaKeys = Object.keys(schemaRegistry[serviceId].shape);
  const codeKeys = walkDir('src/').flatMap(extractEnvVars);

  const unregistered = codeKeys.filter(k =>
    !schemaKeys.includes(k) && !IGNORED_VARS.includes(k)
  );

  if (unregistered.length > 0) {
    console.error(`Env drift detected! Unregistered vars: ${unregistered}`);
    process.exit(1);
  }
}

This runs as:

Pre-commit hook — blocks commits with unregistered env vars
CI check — PRs can't merge if drift is detected
Pre-startup check — each service runs npm run check-env before starting

// package.json of any service
{
  "scripts": {
    "check-env": "npx env-schema check payments",
    "check-infra": "npx env-schema infra",
    "start:local": "npm run check-env && npm run check-infra && cross-env NODE_ENV=dev-local tsnd src/index.ts"
  }
}

We know how teams work. Lint rules get ignored, pre-commit hooks get bypassed with --no-verify. That's why the same check runs in CI. The PR won't merge if there's env drift. No exceptions.

Step 4: Kill Nginx with Traefik

This was the game-changer.

Every developer had a custom nginx config to route API calls between services locally. /api/payments -> port 3001, /api/users -> port 3002, and so on. When a new service was added, everyone had to update their nginx config manually. Nobody's config was the same.

We replaced all of it with Traefik v3.

Traefik is a reverse proxy that auto-discovers services. We use a file-based dynamic provider that watches a config directory for changes — hot reload, no restart needed.

# docker-compose.yml
services:
  traefik:
    image: traefik:v3.0
    ports:
      - "9090:9090"    # API Gateway
      - "8080:8080"    # Dashboard
    volumes:
      - ./traefik/traefik.yml:/etc/traefik/traefik.yml
      - ./traefik/dynamic:/etc/traefik/dynamic  # Hot-reload configs
    networks:
      - app-network

No more per-developer nginx configs. One shared Traefik config in the repo. Add a new service? Add 5 lines to services.yml. Traefik picks it up automatically via hot reload. Everyone gets the same routing.

The dashboard at localhost:8080 gives you a visual map of every route, middleware, and service — something nginx never offered out of the box.

Step 5: One Command to Rule Them All

With the env schema, Traefik, and local service mocking in place, we built the orchestration layer.

Bootstrap for new developers — a single script that handles everything from zero:

# New developer runs this on day one
./bootstrap.sh

This 10-step wizard:

Checks prerequisites (git, Docker, Node.js, VS Code)
Collects git identity
Configures workspace directory
Clones all 15 repos in parallel (4 concurrent)
Sets up git config in each repo
Configures npm registry for private packages
Runs npm install in parallel (3 concurrent)
Generates all .env files from the shared schema
Provisions infrastructure (Docker containers, databases, migrations)
Installs the VS Code extension + generates workspace file

For existing developers — the daily startup:

npm run start

--- Infrastructure Check ---

  [OK] PostgreSQL is responding on port 5432
  [OK] Redis/Valkey is responding on port 6379
  [OK] ElasticMQ (SQS) is responding on port 9324
  [OK] Traefik (API Gateway) is responding on port 9090

Select services to start (SPACE=toggle, A=all, N=none, ENTER=confirm):

The infrastructure check does TCP port scanning with 2-second timeouts. If something's down, it offers to auto-start it via Docker. Then you select which services you need.

Smart terminal detection — the startup script auto-detects your terminal and adapts:

tmux: Grid layout with split panes
iTerm2: Native AppleScript-driven split panes (up to 8 per tab)
Terminal.app: Opens tabs per service
Fallback: Color-coded concurrent output in a single terminal

Each service gets a color-coded label. Health monitoring polls every service in real-time — green when healthy, yellow when starting, red when unhealthy.

The Team Took It Further

I built the core over a weekend and handed it to my tech lead. "Check and deploy," I said.

What they shipped blew me away. They didn't just deploy it — they built a VS Code extension on top:

A welcome page with a 5-step onboarding flow:

Run Preflight Checks -> Start Your First Service -> Manage Branches -> Explore Utilities -> Keyboard Shortcuts

A Services Dashboard (Cmd+Alt+S):

Init All Envs, Start All (Dev), Start All (Build), Stop All
Real-time status: 0/15 running | 0/15 healthy | 0 missing env
Click a service to see logs, restart, or open its Swagger docs

A Preflight Diagnostics panel (Cmd+Alt+P):

The dependency graph visualization — 237 checks passing across all services
Shows which services depend on which, what infrastructure they need

A Branch Manager (Cmd+Alt+B):

View and switch branches across all 15 repos from one UI
No more cd-ing into each repo to check what branch you're on

A Web Portal (Vue 3 + Vite):

Swagger UI aggregator for all service APIs
ElasticMQ queue inspector
Real-time service status monitoring

Now anyone — including our product managers — can run all 15 services with millions of lines of code in under 5 minutes. They can test features end-to-end on their local machine. They ask AI to check if a design is practical. They run the code and see for themselves.

A new developer's first day? Clone, click, code. Not clone, cry, configure.

How to Avoid This at Your Startup (Before It's Too Late)

If you're at 3-5 microservices, here's what to do now before it becomes a 15-service nightmare:

1. Start with a shared env schema from day one. Use Zod (or Joi, or JSON Schema). Even with 2 services, standardize your variable names. DB_HOST everywhere, not DATABASE_HOST in some and POSTGRES_HOST in others. Compose shared blocks with .merge() so naming changes propagate automatically.

2. Pin your runtimes. .nvmrc + engines in package.json. Enforce in CI. It takes 5 minutes and saves weeks of debugging.

3. Mock external services locally. Use ElasticMQ instead of real SQS, MinIO instead of real S3. Your env schema should auto-switch endpoints based on NODE_ENV=dev-local.

4. Use Traefik instead of nginx from the start. File-based dynamic provider + hot reload beats editing nginx.conf every time a service changes. Your future self will thank you.

5. Add env drift detection to CI. A regex scanner that checks process.env references against your schema catches problems before they spread. Run it in pre-commit hooks AND CI — belt and suspenders.

6. Invest in the "first 5 minutes" experience. If a new developer can't run your entire stack in 5 minutes, you have a problem. It will only get worse. Build a bootstrap script. Make it idempotent. Make it parallel.

The Before and After

	Before	After
Onboarding	1-2 weeks	5 minutes
Env setup	Ask on Slack, copy-paste	Auto-generated from schema
Env validation	Crash at runtime	Fail fast on startup with clear errors
Routing	Manual nginx per developer	Traefik with hot-reload config
Integration testing	Against shared dev DB	Full local stack, end-to-end
Starting services	Manual, per-service, per-developer	One command, interactive selection
Node version	Whatever was installed	Pinned in `.nvmrc`, enforced in CI
New service added	Update everyone's nginx, share new .env	Add 5 lines to Traefik config, schema auto-generates .env
Drift prevention	None (hope-based)	Pre-commit + CI drift checks
Who can run the stack	Senior devs only	Anyone, including PMs

The tools matter less than the principle: your local development environment is a product. Treat it like one. Your developers are the users. If the onboarding experience is painful, every day after that is a little painful too.

We used NestJS, TypeScript, Zod, Traefik, ElasticMQ, Docker, and VS Code. You might use different tools. The pattern is the same: centralize config, validate on startup, auto-generate defaults, prevent drift, make it one click.

Build it once. Fix it for everyone. Forever.

I'm Arun, CTO at a fintech startup. We're a team of 15 engineers in India building payment infrastructure for the UK. I write about the messy reality of scaling engineering teams and systems. Find me on X @mickyarun.