Your Payment API Wasn't Built for AI Agents. Open Banking Might Be the Fix.

Stripe just shipped an Agentic Commerce Suite. PayPal launched Agent Ready. Visa predicts millions of consumers will use AI agents to complete purchases by the 2026 holiday season. Mastercard introduced Agent Pay with its own verification layer. Google launched the Agent Payments Protocol with 60+ partners.

Everyone is scrambling to make payments work for AI agents.

And I keep looking at all of it thinking: you're bolting agent support onto a stack that was designed for a human staring at a checkout page. That's not an integration. That's a retrofit.

I run payments infrastructure. Our platform processes open banking payments for UK merchants — the kind where money moves directly from the customer's bank account, no card network in between. And from where I sit, the agentic payments conversation has a blind spot the size of Visa's interchange fee.

Let me explain.

The card stack assumes a human is present

Here's what happens when you process a card payment today:

1. User types card number into a form (or taps a saved card)
2. Your frontend collects PAN data, sends it to a tokenisation layer
3. The token goes to an acquirer, who talks to the card network, who talks to the issuing bank
4. 3D Secure kicks in — the user gets a push notification or SMS OTP
5. The issuing bank authorises (or declines)
6. Settlement happens days later

That flow was designed around one assumption: a human is sitting at a screen, ready to respond to authentication challenges.

Now replace the human with an AI agent.

The agent doesn't have eyes to read an OTP. It can't tap "approve" on a banking app push notification. It can't solve a CAPTCHA. It can't parse a 3DS iframe that renders differently on every issuing bank's domain.

So what do the card networks do? They build workarounds. Stripe's agentic suite generates virtual cards. Mastercard's Agent Pay pre-registers agents and skips some auth steps. Everyone is finding clever ways to route around the authentication wall that they built.

That's the tell. When your entire ecosystem is engineering around its own security layer, the architecture has a problem.

Open banking was built for machines talking to machines

Open banking works differently. There's no card number. No PAN. No tokenisation vault. No 3DS iframe.

Here's the flow:

1. Your app (or agent) calls a payment initiation API
2. The API returns a redirect URL to the customer's bank
3. The customer authenticates directly with their bank (biometrics, app-based SCA)
4. The bank confirms the payment
5. Money moves. Settlement is instant or same-day.

Notice what's different. The payment API is a clean, stateless request-response interface. The authentication happens on the bank's side, not inside your checkout flow. Your code never sees a card number, never handles an OTP, never renders an auth challenge.

For a human using a checkout page, this is a nice UX improvement. For an AI agent calling a payment API, this is a structural advantage.

The agent makes an API call. It gets back a payment URL. It hands that URL to the human for one-time bank authentication. Done. The agent doesn't need to handle auth. The bank does. The separation of concerns is clean.

And with VRPs (Variable Recurring Payments) now live in the UK, it gets even better. The human authenticates once, sets spending limits, and the agent can initiate payments within those limits without any further human interaction. No virtual cards. No pre-registered agent identities. Just an API call against a mandate.

That's not a workaround. That's the architecture actually working as designed.

What breaks when agents use card APIs

I've been watching developers try to build agentic payment flows on card rails. Here's what keeps going wrong:

PCI scope explosion. If your agent is generating virtual cards, storing card tokens, or managing card-on-file relationships, your PCI compliance surface just grew. AI agents that handle card data need the same compliance posture as any system that touches PANs. That's not a small thing. That's SOC2 scope, penetration testing, quarterly scans — all for an agent that could've made a bank-to-bank API call instead.

Authentication is the bottleneck. 3D Secure was designed as a human-in-the-loop check. Every attempt to skip it for agents either weakens security (bad) or creates a parallel auth system (complex and fragile). Open banking's approach — SCA happens at the bank, not at your checkout — means the agent never needs to authenticate. It just calls the API.

Settlement lag creates state management nightmares. Card payments settle in days. When an agent is orchestrating a multi-step workflow (compare prices → select vendor → pay → confirm delivery), it needs to know whether payment actually landed. With cards, you get an authorisation that might reverse, a settlement that arrives Tuesday, and a chargeback window that stays open for months. With open banking, payment confirmation is real-time. The state machine is simpler because the money actually moved.

Micro-payments don't work on card rails. AI agents generate hundreds of micro-transactions per session. The interchange fee floor on card payments makes sub-pound transactions economically absurd. Open banking's fee structure is flat or percentage-based without the card network's minimum — which is why it actually works for the agentic pattern of many small, frequent payments.

What I'd actually build

If I were starting an agentic commerce integration today for UK customers, here's the architecture I'd reach for:

For one-off agent-initiated purchases: Open banking payment initiation. The agent creates a payment request via API, gets a consent URL, passes it to the user. One SCA event, then the money moves. No card data anywhere in the stack.

Agent → Payment API (create payment request)
      → User gets bank auth link
      → User approves in banking app (biometrics)
      → Webhook confirms payment
      → Agent continues workflow

For recurring agent-managed spending: VRP mandates. User sets up a mandate once — monthly cap, per-transaction cap, approved merchant. The agent calls the payment API within those bounds. No re-authentication. No virtual cards. No 3DS.

User → Sets up VRP mandate (one-time SCA)
Agent → Calls payment API within mandate limits
      → Instant confirmation via webhook
      → No further user interaction needed

For the auth layer: Don't build one. Seriously. The bank handles it. Your agent's job is to orchestrate the payment flow, not to authenticate the user. That's separation of concerns, and it's the right call whether you're building for agents or humans.

The real question no one's asking

Everyone is asking "how do we make card payments work for AI agents?"

I think that's the wrong question.

The right question is: why are we starting with the payment rail that requires the most human interaction, then engineering the human out?

Open banking was built on the premise that software talks to bank APIs. The authentication layer lives at the bank. The payment instruction is a clean API call. Settlement is immediate. There's no card number to protect, no 3DS challenge to render, no interchange fee eating your margin on micro-transactions.

It wasn't designed for AI agents. But its architecture fits the agentic pattern better than anything the card networks are retrofitting.

Sometimes the future doesn't come from the company with the biggest R&D budget. Sometimes it comes from the infrastructure that was built on the right abstraction in the first place.

The UK has live open banking rails, live VRPs, and an FCA that's actively building the regulatory framework for what comes next. If you're a developer building agentic commerce for UK customers, you have a head start. Use it.

I'm Arun, CTO at Atoa. We build open banking payment infrastructure for UK merchants. If you want to see what the API looks like: docs.atoa.me

Try the sandbox → docs.atoa.me