DEV Community: arun rajkumar

Payment Webhooks Will Lie To You. Here's How We Built Ones That Don't (in NestJS)

arun rajkumar — Wed, 29 Apr 2026 11:48:31 +0000

A payment webhook fires once. You miss it. The customer thinks they paid. Your dashboard says they didn't.

Welcome to my Tuesday morning, two years ago.

I've shipped four payment webhook systems in my career. The first three taught me everything I now refuse to do again. The fourth — the one running inside Atoa today — handles open banking payment notifications across our Node.js services without a single missed event in the last 14 months.

Here's the boring, opinionated, production-tested pattern.

The lie webhooks tell you

Every payment platform sells webhooks the same way:

"We'll notify your endpoint the moment the payment status changes."

What they don't sell you on:

Webhooks retry. Sometimes 8 times. Sometimes never.
Webhooks arrive out of order. failed can land before pending.
Webhooks lie about idempotency. Two succeeded events for the same payment is normal, not a bug.
Webhooks drop. Network blip, your pod restart, a bad DNS lookup — one missed delivery and your reconciliation is wrong.

If your webhook handler is a 30-line controller that updates a row in your database, you don't have a payment system. You have a hope.

The four-layer pattern

Every webhook flow we run at Atoa has four layers. Skip any one and you'll be reconciling spreadsheets at midnight.

1. Verify the signature before you parse the body

The most common bug I see in code reviews from junior devs: parsing the JSON before checking the HMAC.

// webhook.controller.ts
@Post('atoa')
async handle(
  @Headers('x-atoa-signature') signature: string,
  @RawBody() body: Buffer,        // raw, not parsed
) {
  if (!this.crypto.verify(body, signature, this.secret)) {
    throw new UnauthorizedException();
  }

  const event = JSON.parse(body.toString());
  await this.queue.enqueue(event);
  return { received: true };
}

Two non-negotiables:

Use the raw body for HMAC verification. NestJS's default JSON parser will mutate whitespace and break your signature check. Enable rawBody: true on the app.
Reject before you do anything else. No DB hits, no logging the payload at info level, nothing.

2. Acknowledge fast. Process slow.

The webhook controller does two things: verify, enqueue. That's it.

async handle(...) {
  // verify (above)
  await this.queue.enqueue('payment.webhook', event);
  return { received: true };  // 200 within ~50ms
}

If your handler takes 8 seconds because you're hitting Stripe + your DB + sending an email, the sender will time out and retry. Now you have two events. Then four. Then the on-call engineer.

We use BullMQ on Redis. You can use SQS, NATS, Kafka — pick your poison. The point is: the HTTP response is decoupled from the work.

3. Idempotency keys are not optional

Every event has an event_id. Before you do anything in your worker:

@Processor('payment.webhook')
export class WebhookProcessor {
  async process(job: Job<WebhookEvent>) {
    const { event_id, payment_id, status } = job.data;

    const seen = await this.events.firstSeen(event_id);
    if (!seen) {
      this.logger.log(`Duplicate event ${event_id} — skipping`);
      return;
    }

    await this.applyStatus(payment_id, status, event_id);
  }
}

firstSeen is a write to a Postgres table with event_id as the primary key. If the insert succeeds, this is the first time we've seen this event. If it conflicts, we've processed it before. No race conditions, no Redis dance — just let the database do the work it's good at.

4. State machines, not status updates

This is the one that took me three failed payment systems to learn.

A payment doesn't have a "status field." It has a state machine. Some transitions are legal. Most aren't.

const ALLOWED: Record<PaymentStatus, PaymentStatus[]> = {
  initiated: ['authorising', 'failed'],
  authorising: ['succeeded', 'failed'],
  succeeded: [],            // terminal
  failed: [],               // terminal
};

async applyStatus(id: string, next: PaymentStatus, eventId: string) {
  const payment = await this.payments.findById(id);
  if (!ALLOWED[payment.status].includes(next)) {
    this.logger.warn(`Illegal transition: ${payment.status} → ${next}`);
    return;       // do not update, do not throw — this is normal
  }
  await this.payments.transition(id, next, eventId);
}

Why this matters: when failed arrives before pending (and it will), your code shouldn't downgrade a succeeded payment to failed. With a state machine, the invalid transition is dropped. The reconciler picks it up later. The customer's payment stays correct.

What we'd never do again

Three patterns I see in the wild that I had to unlearn:

Polling instead of webhooks. "We'll just check the status every 30 seconds." Sure — and you'll burn rate limits, miss the 5-second window where a customer is staring at the spinner, and pay for compute that does nothing 99% of the time.
Replaying webhooks by re-running the handler. If the handler does five things, replaying it does five things again. Idempotency keys mean replays are free.
Logging the full payload at info level. PSD2 says your logs are PII now. Log the event_id and the status. Nothing else.

Where this gets you

We process open banking payment notifications across dozens of UK merchants on this exact pattern. Zero missed events in 14 months. Reconciliation runs once a day and finds nothing to reconcile.

The pattern doesn't care which payment provider you use. Stripe, GoCardless, Atoa — same four layers.

If you want to see what these webhooks look like on the open banking side, our API docs walk through the full payment lifecycle and the webhook events we fire: docs.atoa.me. Sandbox is free, no card needed.

Build the boring layers first. Sleep through Tuesday mornings.

Arun is co-founder & CTO of Atoa, a UK open banking payments platform. He's @mickyarun on X and dev.to. Driven by passion.

I Asked Three Coding Agents to Build My Son's Cricket Coach a Website. The Result Wasn't Decided by the Model — It Was Decided by Taste.

arun rajkumar — Tue, 28 Apr 2026 08:51:56 +0000

TL;DR — Codex GPT-5.5, Claude Opus 4.7, Gemini 3.1 Pro. Same prompt. Same 18 photos. Five total runs across different effort budgets. The one that won wasn't the prettiest. It was the one that understood the job: parents in Bengaluru enquire on WhatsApp, not contact forms.

My son's cricket coach asked me for a website.

Saturday afternoon. He runs Bangalore Royal Cricket Academy — a small but seriously good cricket academy for kids. He had two phone numbers, a folder of 18 WhatsApp photos taken by parents, and a single line of brief: "Like a real cricket academy, parents should be able to call or WhatsApp from their phone."

I'm a CTO. I'm in the trenches with AI coding agents most weeks. This felt like a clean, low-stakes test.

So I gave the exact same prompt and the exact same 18 photos to three coding agents:

OpenAI Codex (GPT-5.5, medium effort)
Anthropic Claude Opus 4.7 (low effort, then re-run on medium)
Google Gemini 3.1 Pro (low effort, then re-run on high)

Five outputs. One Saturday. Five very different opinions on what "a cricket academy website" actually is.

I went in expecting a verdict on visual quality. I didn't get one. I got something more interesting.

The setup

The prompt was deliberately short:

Build a single-page website for Bangalore Royal Cricket Academy. Brand line: "Nurturing champions, one delivery at a time." Programs: Summer Camp, Weekday Batch, Weekend Batch, Intensive (elite). Two phone numbers. The photos are in /photos for website. Parents should be able to contact us easily from their phone.

That's it. No design system. No colour palette. No mention of WhatsApp by name. No mention of tests, deployment, SEO meta, or Cloudflare. Whatever each agent decided "easily contact us from their phone" meant — that was on the agent.

What I got back, in five outputs

1. Claude Opus 4.7, low effort

Single-file HTML, Tailwind via CDN, Bebas Neue display font, royal navy + gold palette.

The headline made me sit up: "CHAMPIONS ARE / BUILT HERE." with the second half in gold. It was the only one of the five where the hero felt like it belonged on a printed flyer the coach would hand out at a school. Visually polished.

Engineering-wise, thin: no tests, no OG tags beyond a <meta description>, photos referenced as img-01.jpg…img-18.jpg, all 14 used in a uniform 4-column grid. Tel: links only. No WhatsApp.

2. Claude Opus 4.7, medium effort

Same starting point, completely different output.

<section id="top" class="relative h-screen min-h-[640px] w-full overflow-hidden">
  <div class="absolute inset-0">
    <img src="assets/photos/brca-01.jpeg" alt="" class="kenburns" />
    <div class="absolute inset-0 bg-gradient-to-b from-navy-deep/85 via-navy/70 to-navy-deep/95"></div>
  </div>
  ...
</section>

Full-screen hero with a Ken Burns animation on the image. A scroll indicator with an animated dot inside a mouse outline. A gold cricket-seam pattern divider between sections — actual dashed lines that look like ball stitching. Two-image collage in the about section with offset margins. CSS-columns masonry gallery using all 15 photos. Inline-SVG favicon as a data URI (one fewer request). OG tags. theme-color. WhatsApp deep-link button on the contact section.

<a href="https://wa.me/917337726777?text=Hi%20BRCA%2C%20I%27d%20like%20to%20know%20more%20about%20your%20programs."
   target="_blank" rel="noopener"
   class="bg-gold text-navy font-semibold px-6 py-3.5 rounded-md">
  💬 Message us on WhatsApp
</a>

This was the prettiest output of the five. By a clear margin. Bebas Neue + Inter, Ken Burns, gold seam, masonry — the only one I'd let near a printer.

Still Tailwind via CDN. Still no test suite. Still no automated deploy. Photos renamed semantically (brca-01.jpeg).

3. Codex GPT-5.5, medium effort

Vanilla HTML + 800-line vanilla CSS + 16 lines of vanilla JS. White-and-navy local-business layout. Numbered "01–04" feature blocks. WhatsApp green CTAs in the contact section.

It looks less editorial than Claude-medium. It also does five things none of the others did.

One. It picked 6 photos out of 18 and renamed them by content:

brca-team-ground.jpeg
brca-trophy-team.jpeg
brca-trophy-presentation.jpeg
brca-young-achievers.jpeg
brca-coaching-moment.jpeg
brca-floodlight-batch.jpeg

That's editorial judgement encoded in code output. It chose; it didn't dump everything into a grid.

Two. It wrote a _headers file:

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

/assets/*
  Cache-Control: public, max-age=31536000, immutable

Security headers and cache rules. I didn't ask for them.

Three. It wrote a real test suite using node:test:

test('home page exposes call and WhatsApp enrollment links', async () => {
  const html = await text('index.html');
  assert.match(html, /href="tel:\+917337726777"/);
  assert.match(html, /href="tel:\+917337736777"/);
  assert.match(html, /https:\/\/wa\.me\/917337726777/);
  assert.match(html, /https:\/\/wa\.me\/917337736777/);
});

test('referenced local assets and Cloudflare Pages config exist', async () => {
  const imageRefs = [...html.matchAll(/src="([^"]+\.(?:jpg|jpeg|png|webp))"/gi)]
    .map(m => m[1]);
  assert.ok(imageRefs.length >= 6, 'at least six academy photos are used');
  for (const ref of imageRefs) {
    assert.ok(existsSync(new URL(ref, root)), `${ref} exists`);
  }
});

Three tests. They assert brand text, both phone numbers, both WhatsApp links, security file existence, responsive CSS, and that every referenced image actually exists on disk. That last one is the one I respect most. It catches the single most common silent break in a static site.

Four. Every primary CTA is a wa.me deep link with prefilled message text:

<a class="contact-link whatsapp"
   href="https://wa.me/917337726777?text=Hi%20BRCA%2C%20I%20would%20like%20to%20know%20more%20about%20cricket%20training."
   target="_blank" rel="noopener">
  <span>WhatsApp</span>
  <strong>7337726777</strong>
</a>

Not just wa.me/91…. Pre-filled message text. Parent taps. Message lands. Zero typing.

Five. It deployed it. It opened my browser, walked me through a Cloudflare OAuth handshake, then pushed the build to Cloudflare Pages. The .wrangler/cache/pages.json left behind:

{ "account_id": "...", "project_name": "brca-academy" }

Most coding agents stop at "here's the HTML." Codex stopped at a live URL. That distinction — treating "build a website" as a unit of work that includes shipping, not just generating markup — is what made me rate it the most production-ready output of the five.

4. Gemini 3.1 Pro, low effort

Dark slate background. Electric blue + amber accents. 60 lines of vanilla JS with an IntersectionObserver scroll-reveal effect.

It looked like a SaaS analytics dashboard. Wrong audience by about ten years. Photos referenced as photo_1.jpeg…photo_18.jpeg. Tel: only.

5. Gemini 3.1 Pro, high effort

Palette fixed: navy + amber. Playfair Display + Outfit for typography. About section with an image collage and an "Elite Training Facility" badge. Wider elite-program card with a dedicated highlights box. Mobile menu with hamburger.

Visually, a different website from the low-effort version. Genuinely better.

What it still didn't have:

WhatsApp deep links. Anywhere. Tel: only.
OG tags or theme-color.
A test suite.
A deployment config.
Semantic photo names — still img1.jpeg through img8.jpeg.

More budget bought better visuals. It didn't buy better judgement about what a Bengaluru cricket academy website is for.

What actually decided it

Not the prettiest hero. Not the cleverest animation.

This:

In Bengaluru, parents enquire on WhatsApp. Not email. Not contact forms. Not phone calls until they've messaged first.

The single biggest conversion lever for an Indian local business website is wa.me deep linking with prefilled message text. Parent opens the page. Parent taps the button. WhatsApp opens with "Hi BRCA, I would like to know more about cricket training" already typed. They send. Coach gets a notification.

Codex did this on every primary CTA. Claude-medium did it as one button at the bottom of the contact section. Claude-low, Gemini-low, and Gemini-high didn't do it at all.

That single decision was worth more than the prettiest hero in the comparison.

The thing I wasn't expecting

I went in assuming effort budget would be the variable that explained quality differences.

Compare what happened when I doubled the effort budget on each model:

Claude (low → medium): The visual quality jumped from "pretty" to "editorial-grade". It added Ken Burns animation, masonry gallery, OG tags, a theme-color, semantic photo names, and a WhatsApp button. It also renamed photos from img-XX.jpg to brca-XX.jpeg. The model used the extra budget to upgrade both taste and product judgement.

Gemini (low → high): The visual quality jumped. The palette got fixed. The typography got upgraded. The layout got more sophisticated.

It still didn't add WhatsApp.

It still didn't write tests.

It still didn't deploy.

It still left photos as img1.jpeg.

More budget didn't teach the model what the website was for. It only taught it to make the wrong website prettier.

The headline isn't Codex won because GPT-5.5 is the best model. The headline is:

Effort budget isn't the variable that explains output quality. Taste is.

Codex on a single medium run produced more production-ready output than Gemini on high. Claude on medium produced the most beautiful site in the lineup. Gemini on high produced a much-improved-but-still-fundamentally-misjudged website.

The extra budget surfaced what each model already understood about the job. It didn't change what the model thought the job was.

Sidebar: Two paths to a Cloudflare token

Worth mentioning because it's the kind of thing CTOs care about.

When each agent needed to deploy to Cloudflare Pages, they took one of two paths:

Path A — silent OAuth. Codex (medium) and Gemini (low) opened my browser, walked me through Cloudflare's OAuth flow, and got a session. Fast. Smooth. I never saw the token. The agent now has access to my entire Cloudflare account for the duration of that session.

Path B — paste-your-own-token. Claude (at every effort level) and Gemini (at medium effort) said: "Go to Cloudflare → My Profile → API Tokens → Create Token with these specific scopes — Account: Cloudflare Pages: Edit — and paste it here. I won't see your account session." More friction at install time. Also more control: the token is scoped, I can see exactly what I gave the agent, I can rotate or revoke it without touching my main session.

Both are defensible. Path A optimises for time-to-deploy. Path B optimises for credential hygiene.

If you're a solo developer building a side project, Path A is probably fine. If you're running production infrastructure for a fintech and an AI agent is asking for credentials, Path B is the only answer. The fact that two of three agents converge to Path B at higher effort levels — Claude always, Gemini at medium and above — suggests their "thoughtful" mode is more security-aware. Codex stayed silent-OAuth even at medium. Worth knowing.

What this means for picking a coding agent in 2026

Three takeaways, none of them about benchmarks.

One. Test the agent on a job, not on a problem. "Build a website" and "build a website that converts WhatsApp leads for an Indian local business" are different evaluations. The first is a syntax exercise. The second tells you whether the agent can read the room.

Two. Effort budgets are amplifiers, not teachers. They make a model more of what it already is. If a model doesn't understand the job at low effort, high effort will produce a more polished version of the wrong thing.

Three. Production scaffolding is the cheapest signal of seriousness. Tests. Headers. OG meta. A 404.html. Curated photos with content-aware filenames. None of these were in my prompt. The agent that wrote all of them on its own is the one I trust with code I can't review line by line.

Coda — what actually shipped

I have to be honest about something the single-shot benchmark couldn't capture.

Codex won my engineering eval. That stands. It's the one I'd hand a junior dev and say "ship it."

But the one I reached for next was Claude.

Two more prompts with the medium-effort Claude — "add a persistent WhatsApp floating button," "add a three-card contact section like a real local business, with primary office / coaching desk / WhatsApp" — and a bit of browser automation to handle the Cloudflare deploy and DNS, and the site went live at brca.in.

That's the version the coach is using today. WhatsApp floating button. Three contact cards. A "Free trial session available" pill the coach asked for after the first parent enquiry. A schedule strip. Custom domain. Live HTTPS.

Why Claude, not Codex — given my own engineering verdict?

Because the single-shot test answers "which agent has the best instincts." The shipping test answers "which agent do I want as a collaborator."

Those are different questions. They had different answers for me.

Claude was the one I wanted to keep editing. The Bebas Neue + gold-seam aesthetic, the masonry gallery, the Ken Burns hero — those are the parts of the design I didn't want to throw away. Codex's output was more correct. Claude's output was the one I had a relationship with.

That's a real signal. Worth saying out loud.

The closer

The coach got a website. Parents got a WhatsApp button. The site is live at brca.in.

The first parent message landed in the inbox before sundown. "Hi BRCA, I would like to know more about cricket training."

The one-shot finding holds: at first contact, taste decided the comparison. Codex's instinct for what an Indian local business website needed to do was sharper than any other model in the lineup.

But the part of the comparison nobody benchmarks is the part that matters most after the demo: which agent do you actually want to keep working with.

For me, on this job — it was Claude.

Champions are built here. Apparently websites too.

Site live at brca.in. Drop a comment if you'd like the source code for all five runs — happy to share the GitHub repo.

What I'd love to know: which agent are you reaching for in 2026 — and what's the smallest job you've used to test whether it actually understands the room? Reply below.

Your Agent Doesn't Need a Better Model — It Needs a Context Layer

arun rajkumar — Fri, 24 Apr 2026 12:49:42 +0000

We stopped trying to find a better model.

We built a better context surface. Different problem. Different fix.

Here's the story of how we got there, and why I think most teams in 2026 are optimising the wrong side of the equation.

The 1,200-line PR

A few months ago, one of our engineers asked an AI agent to help add a new refund flow to our merchant service. The agent returned a PR. 1,200 lines. It compiled. The tests passed.

It also did three things we'd explicitly decided, months earlier, to never do in this codebase:

It created a new service-to-service HTTP client instead of using our internal ServiceBus abstraction.
It persisted refund state in the merchant service's own database instead of emitting a domain event for the ledger service to consume.
It wrote a retry loop with setTimeout instead of using our @Retryable decorator, which has backoff policies tied to our SLOs.

None of this is in the agent's training data. Nothing in the README told it either. And the reviewer — doing the review at 6pm on a Friday — skimmed the diff, saw green CI, and approved.

Two weeks later we had a duplicate-refund incident. One hour of debugging to find the cause. Not a bug in the agent's code. A design-pattern violation the agent had no way to know existed.

The realisation

Here's the uncomfortable part.

The agent didn't do anything wrong. It did exactly what a capable junior engineer would have done if dropped into the repo for the first time with no context. Which is: it solved the immediate problem with reasonable-looking code, using the patterns it had seen in its training data.

Our new hires did the same thing. I went back and checked. In the six months before that incident, we'd had three separate PRs from three different people — two human, one AI — all creating bespoke HTTP clients instead of using ServiceBus. All of them reviewed by people who knew better but missed it under time pressure.

The bug wasn't the model. The bug was that the knowledge of which patterns we'd consciously chosen to standardise lived nowhere an agent could read it, and only half-lived in the heads of senior engineers who weren't always in the review.

So we stopped chasing model quality and started building the thing that was actually missing: a context layer.

What "context layer" actually means

The phrase gets thrown around loosely since MCP took off, so let me be concrete.

In our stack, a context layer is:

A single, versioned source of truth for architectural decisions, design patterns, and merchant-domain invariants.
Structured as machine-readable documents (MDX with frontmatter, not free-form Confluence pages).
Served over MCP so the same corpus is queryable by every AI tool on the team — Claude, Cursor, Copilot, our internal agents.
Enforced by CI through design-pattern lints that fail the build when any PR — human-authored or AI-authored — violates a recorded pattern.

The enforcement layer is what most teams skip. The context on its own is a wiki nobody reads. The lints on their own are arbitrary rules nobody remembers the reason for. Pairing them is where the leverage lives.

The three files that made it work

Here's the minimum structure we settled on, with real examples from our monorepo.

1. `adr/*.mdx` — architectural decisions, machine-readable

---
id: ADR-0047
title: "Service-to-service communication goes through ServiceBus"
status: accepted
date: 2025-11-12
tags: [microservices, inter-service, nestjs]
supersedes: null
lint_rule: no-direct-http-client
---

## Context
15 NestJS microservices. Two years ago, every service had its own
Axios instance. Retry semantics drifted. Timeouts drifted. Tracing
headers got dropped. Incidents had no consistent trail.

## Decision
All service-to-service calls go through @atoa/service-bus, which
wraps Axios with retries, circuit breaking, OpenTelemetry tracing,
and our standard auth header injection.

## Rationale
- Retry policies live in one place, tied to SLOs.
- Every call is traced by default.
- Failures surface consistently in Grafana.

## Enforcement
eslint rule: no-direct-http-client (see lint-rules/)
CI gate: fail on import of 'axios' or 'node:http' in service code.

Every ADR has a lint_rule pointer. No ADR ships without one, unless explicitly marked advisory.

2. `lint-rules/no-direct-http-client.ts` — the actual enforcement

import { TSESTree, TSESLint } from '@typescript-eslint/utils';

const BANNED = ['axios', 'node:http', 'node:https', 'undici'];
const ALLOWED_PATHS = [
  'libs/service-bus/',
  'libs/http-primitives/',
];

export const rule: TSESLint.RuleModule<'useServiceBus', []> = {
  meta: {
    type: 'problem',
    messages: {
      useServiceBus:
        'Direct HTTP clients are banned. Use @atoa/service-bus. See ADR-0047.',
    },
    schema: [],
  },
  defaultOptions: [],
  create(ctx) {
    const filename = ctx.getFilename();
    if (ALLOWED_PATHS.some((p) => filename.includes(p))) return {};

    return {
      ImportDeclaration(node: TSESTree.ImportDeclaration) {
        if (BANNED.includes(node.source.value)) {
          ctx.report({ node, messageId: 'useServiceBus' });
        }
      },
    };
  },
};

Nothing clever. The point is: when an agent (or a human) ships the banned pattern, the PR cannot land. Not "a reviewer will notice." The build fails. Every time.

3. `context.mcp.json` — what we expose to every tool

{
  "name": "atoa-engineering-context",
  "version": "1.4.0",
  "resources": [
    { "uri": "adr://*", "description": "Architectural decisions with enforcement status" },
    { "uri": "pattern://*", "description": "Approved design patterns with code examples" },
    { "uri": "domain://merchant", "description": "Merchant domain invariants and flows" },
    { "uri": "domain://payments", "description": "Payment flow state machines" }
  ],
  "tools": [
    {
      "name": "check_pattern",
      "description": "Given a code snippet, return any ADR violations it would trigger"
    },
    {
      "name": "find_precedent",
      "description": "Search for prior implementations of a similar pattern in our codebase"
    }
  ]
}

Every AI tool our team uses mounts this MCP server. When an engineer asks Claude to "add a refund flow," the model has the ADRs in retrieval before it starts writing code. When it asks "how have we handled async retries in the past," find_precedent returns the real decorator, not something that looks plausible.

The agent stopped hallucinating patterns not because the model got smarter. Because we gave it somewhere to look.

What happened in the last 30 days

We've been running this layer across the full engineering team — 18 people, mix of AI-heavy and AI-light workflows — for just under a quarter now. Last month's numbers:

23 pattern violations caught by design-pattern lints before merge. 14 from human-authored PRs. 9 from AI-authored PRs. The ratio surprised me. I'd expected AI to dominate the violation list. It did not.
2 architectural regressions avoided that would previously have shipped. One was a would-be duplicate-refund bug in the same area as the Friday-night incident. The lint caught what the reviewer under time pressure would have missed.
Onboarding time for a new engineer down from 2 weeks to 4 days on the local-dev side, which is a separate story, but the context layer helped here too. New hires read the ADR corpus once, then let the MCP server answer their day-to-day "does this already exist?" questions.
Zero arguments in code review about "is this the right pattern." When a disagreement happens, the question becomes "is there an ADR for this?" If yes, the lint decides. If no, we write the ADR.

That last one is the quiet win. Code review time on architectural questions dropped by roughly a third, because we stopped relitigating decisions we'd already made.

The part most teams get wrong

Two patterns I see repeatedly on teams that try to build this and don't get the leverage:

1. Context without enforcement. A beautiful ADR wiki nobody reads. Every violation still ships because there's no gate. This is where most teams stop because the wiki felt like the real deliverable. It is not. The lint is the real deliverable.

2. Enforcement without context. A forest of lint rules nobody understands. The first time someone hits a red CI gate with a rule they've never seen, they open a Slack channel and ask why. If the lint points to an ADR with a clear rationale, the question answers itself. If it points to a rule that just says "forbidden," you've built a political problem disguised as infrastructure.

Pairing them is not optional. Either one alone is worse than nothing.

What this means for "model quality" debates in 2026

Every week there's a new "is Claude 4.6 better than Opus 4.5 at code" thread. I read them. I have opinions. But in terms of what actually moved the needle on our shipping velocity this quarter — it wasn't the model.

It was the retrieval surface.

The model doesn't need to be smarter. It needs to read the right thing before it answers. And once the context layer is good enough, the difference between "good model" and "great model" collapses, because both are now looking at the same authoritative source.

For 2026, if I had to pick one place to invest a quarter of engineering time to improve AI-native development, it wouldn't be better prompts. It wouldn't be a new IDE extension. It would be this:

Write down the patterns you've actually chosen. Make them machine-readable. Serve them over MCP. Enforce them in CI. Stop relying on tribal knowledge to survive code review.

The agent isn't the bottleneck. The knowledge surface is.

I'm Arun, CTO and co-founder at Atoa — we build open banking payments for the UK. We run 15 NestJS microservices in production and I write about the things we've learned the hard way. Find me on X @mickyarun if you want to argue about any of this.

What Developers Get Wrong About PSD2 and Payment Initiation

arun rajkumar — Wed, 22 Apr 2026 06:16:57 +0000

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.

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.

DEV Community: arun rajkumar

Payment Webhooks Will Lie To You. Here's How We Built Ones That Don't (in NestJS)

The lie webhooks tell you

The four-layer pattern

1. Verify the signature before you parse the body

2. Acknowledge fast. Process slow.

3. Idempotency keys are not optional

4. State machines, not status updates

What we'd never do again

Where this gets you

I Asked Three Coding Agents to Build My Son's Cricket Coach a Website. The Result Wasn't Decided by the Model — It Was Decided by Taste.

The setup

What I got back, in five outputs

1. Claude Opus 4.7, low effort

2. Claude Opus 4.7, medium effort

3. Codex GPT-5.5, medium effort

4. Gemini 3.1 Pro, low effort

5. Gemini 3.1 Pro, high effort

What actually decided it

The thing I wasn't expecting

Sidebar: Two paths to a Cloudflare token

What this means for picking a coding agent in 2026

Coda — what actually shipped

The closer

Your Agent Doesn't Need a Better Model — It Needs a Context Layer

The 1,200-line PR

The realisation

What "context layer" actually means

The three files that made it work

1. adr/*.mdx — architectural decisions, machine-readable

2. lint-rules/no-direct-http-client.ts — the actual enforcement

3. context.mcp.json — what we expose to every tool

What happened in the last 30 days

The part most teams get wrong

What this means for "model quality" debates in 2026

What Developers Get Wrong About PSD2 and Payment Initiation

1. PSD2 is not OAuth

2. "Just hit the bank API" is not a real architecture

3. SCA is not a checkbox

4. The webhook is the source of truth, not the redirect

5. Open banking is not "Stripe but cheaper"

TL;DR for developers shipping in 2026

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

What They Built

Architecture at a Glance

The Tech Stack

Features That Matter

Why Open Source?

Getting Started

What's Next

The Bigger Lesson

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

The Problem With Cards and AI Agents

What Open Banking Consent Actually Looks Like

Why the Consent Model Fits AI Agents

The Real Engineering Challenge: Consent Lifecycle for Agents

What We're Thinking About at Atoa

The Question Every Open Banking Developer Should Be Asking

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

The Architecture in 30 Seconds

The Payment Initiation Flow (PISP)

Step 1: Create a Payment Consent

Step 2: Redirect for Strong Customer Authentication (SCA)

Step 3: Execute the Payment

Why This Matters (The Developer Economics)

The Even Simpler Path: Using a Payment API

What's Coming: Variable Recurring Payments

The TL;DR for Developers

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

The Tax You Don't See

How Open Banking Actually Works (Developer Edition)

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

What Developers Get Wrong About Open Banking

The Numbers That Changed My Mind

So Why Hasn't Everyone Switched?

Getting Started

The Bottom Line

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

Why NestJS for Payments

The 15-Service Architecture

1. `adr/*.mdx` — architectural decisions, machine-readable

2. `lint-rules/no-direct-http-client.ts` — the actual enforcement

3. `context.mcp.json` — what we expose to every tool