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
Top comments (0)