Agentic Payments Open Banking: What B2B Teams Need Now

Agentic payments open banking is the shift from human checkout forms to AI agents that search, compare, and pay on a customer's behalf — using bank rails that were built for API-native authorisation, not sixteen-digit card fields. When your product roadmap includes shopping agents, voice assistants, or embedded AI copilots, the payment method must confirm instantly, expose clear consent boundaries, and reconcile through webhooks your ledger already understands. The FCA Supercharged Sandbox cohort that launched on 13 July 2026 is testing exactly that pattern: firms including TrueLayer and Ubyx (partnering with Amazon) are experimenting with agent-led commerce in a regulated sandbox before it reaches mainstream checkout.

Agentic payments open banking: Payment flows where an AI agent initiates or completes a bank transfer on behalf of a customer — after explicit consent — using open banking payment initiation APIs instead of card checkout forms. The customer still approves in their banking app when required; your platform receives status through webhooks and can store a Bank on File mandate for repeat agent purchases within agreed limits.

What changes when an AI agent handles checkout instead of a person?

Checkout stops being a web form and becomes an API conversation between your agent, a licensed payment provider, and the customer's bank. A human shopper clicks buttons; an agent needs machine-readable payment instructions, deterministic success/failure signals, and consent scopes it can reference on the next purchase. Card-on-file was designed for recurring human merchants — not autonomous software that may initiate payment while the customer is offline.

That is why pay by bank fits agentic commerce structurally. Payment initiation through open banking returns structured status, supports strong customer authentication in the bank app, and avoids sharing card PANs with an agent layer that did not exist when PCI-DSS was written. TrueLayer's Supercharged Sandbox announcement describes a working prototype: a human-in-the-loop payment inside an AI shopping agent, plus Bank on File for streamlined repeat purchases — both on pay-by-bank rails.

If you are still scoping how bank payments work today, start with pay by bank explained before layering agent orchestration on top.

Why do agentic payments need open banking rather than cards?

Cards assume a human typing into a hosted field; agents need tokenised, scope-limited bank authorisation. Three practical gaps make card checkout a poor default for agentic flows:

Requirement	Card checkout	Pay by bank / open banking
Agent-readable initiation	Hosted fields, 3DS browser steps	API create-payment with redirect or app-to-app
Repeat purchase without re-entry	Card-on-file (chargeback-prone)	Bank on File / mandate within consent limits
Final status for ledger	Acquirer webhooks + delayed settlement	Bank-confirmed initiation + scheme webhooks
Customer control	Cancel at issuer	Revoke mandate in banking app

Agents that compare prices across merchants and pay the lowest offer need one payment credential the customer trusts — not a card number pasted into every agent session. Bank on File, explained in bank on file vs card on file, gives agents a mandate bounded by amount caps and merchant categories, closer to how regulators expect delegated payment to work.

The FCA's second Supercharged Sandbox cohort explicitly lists safer agent-led payments and commerce as a use-case theme, with 21 firms selected from 199 applications. That regulatory attention signals buyer teams should treat agentic checkout as a compliance-aware integration — not a marketing experiment you bolt onto existing card acquiring.

How does an agentic pay-by-bank flow work in practice?

The agent creates a payment instruction; the customer authorises in their bank app; your backend confirms via webhook. A production-shaped v1 usually looks like this:

1. Intent capture — the agent identifies product, price, and merchant from structured catalog data (not scraped card forms).
2. Payment request — your backend calls the provider API with amount, reference, and idempotency key.
3. Customer authorisation — redirect or app-to-app handoff to the payer's bank for strong authentication.
4. Webhook confirmation — success, failure, or pending status updates your order and agent memory.
5. Optional mandate — for repeat agent purchases, store Bank on File consent with per-transaction or periodic caps.

Human-in-the-loop is the sensible v1 control: the agent prepares the basket and payment request, but the customer approves in the banking app before funds move. Fully delegated agent payment — where the agent pays without per-transaction approval — requires tighter mandate design, fraud monitoring, and clear revocation UX. Sandbox participants are testing both patterns under FCA oversight through December 2026.

Engineering teams should mirror the same webhook and idempotency rules from open banking API integration: agents multiply request volume; duplicate payment creation becomes a real risk without keys and deduplication.

What consent and fraud controls should B2B teams design upfront?

Treat every agent payment as delegated authority with explicit limits — amount caps, merchant allowlists, expiry dates, and instant revocation paths. Customers must understand what the agent can do before they link a bank mandate, and support teams need runbooks when an agent misfires (wrong SKU, wrong merchant, duplicate attempt).

Design controls in four layers:

• Session scope — what this agent conversation can request (single payment vs mandate setup)
• Mandate limits — maximum amount per pull, daily aggregate, and eligible payee categories
• Step-up authentication — when to force bank-app approval even if a mandate exists (new merchant, price spike)
• Audit trail — immutable log tying agent decision, payment reference, and webhook outcome for disputes

Fraud tooling in the Supercharged Sandbox cohort also targets AI governance and economic crime detection — relevant because agents can be prompt-injected to pay the wrong counterparty. Pair open banking initiation with payee verification and anomaly rules before you enable unattended agent checkout. For high-risk verticals, keep a human approval queue until success rates stabilise.

When you evaluate providers, ask how they support mandate lifecycle events (created, used, revoked) in webhook payloads — not only one-off payment status. Use the provider-matching form to filter on initiation, mandate support, and markets before deep sandbox testing.

How should you evaluate open banking providers for agentic payments?

Shortlist on API-native initiation, mandate support, webhook granularity, and sandbox fidelity — not on generic "AI-ready" marketing. Agentic commerce is new; provider roadmaps differ sharply. A practical scorecard:

Criterion	Why it matters for agents
Payment initiation latency	Agents time out; slow redirects kill conversion
Bank on File / mandate APIs	Repeat agent purchases without full re-auth
Webhook event taxonomy	Agent state machines need granular statuses
Idempotency support	Agents retry; duplicate charges destroy trust
Sandbox per-bank behaviour	Production success varies by institution
Human-in-the-loop UX	App-to-app flows on mobile agents

Run sandbox scenarios that mimic agent behaviour: create payment from server-side code without a browser, simulate customer cancel, test mandate creation and revocation, and replay webhooks. Developers should cross-read best open banking API providers for developers (2026) for documentation quality — this article focuses on agent-specific requirements, not vendor rankings.

According to the FCA's Anthropic sandbox announcement, cohort 2 firms receive GPU infrastructure and regulatory support to move from experiment toward commercial deployment — a signal that agentic payment standards will crystallise through 2026, not years from now.

What should your 2026 roadmap look like?

Pilot human-in-the-loop agent pay by bank in one market before you promise autonomous agent checkout. A sensible sequence for EU B2B payments and product teams:

1. Q3 2026 — Integrate one-off pay by bank if not live; validate webhooks and reconciliation
2. Q4 2026 — Add Bank on File for repeat purchases inside your agent or copilot
3. 2027 — Expand mandates across markets; monitor FCA sandbox outcomes and emerging scheme rules
4. Ongoing — Track PSD3/PSR interface KPIs via PSD3 open banking — harmonised API performance will matter when agents depend on sub-second initiation

Do not wait for "final" agentic standards to start sandbox work. Firms already in the Supercharged Sandbox are shaping those norms with regulators in the room. Your competitive risk is integrating card-only checkout into an agent product that customers will expect to pay by bank.

Frequently Asked Questions

What are agentic payments in open banking?

Agentic payments in open banking are payment flows where an AI agent initiates or completes a bank transfer on behalf of a customer using licensed payment initiation APIs. The customer grants consent — often through their banking app — and the merchant or platform receives payment status through provider webhooks rather than a traditional card checkout form.

Why is pay by bank better suited to AI agents than cards?

Pay by bank uses API-native payment initiation and bank-app authentication designed for programmatic requests, while card checkout assumes a human entering card details in a hosted field. Agents need structured payment instructions, deterministic webhook status, and mandate-based repeat purchase — patterns open banking supports more naturally than card-on-file.

What is human-in-the-loop agentic payment?

Human-in-the-loop agentic payment means the AI agent prepares the basket and payment request, but the customer must approve the transfer in their banking app before funds move. It is the recommended v1 control while firms test agent-led commerce in environments like the FCA Supercharged Sandbox.

Can an AI agent set up recurring payments through open banking?

Yes, when the provider supports Bank on File or mandate APIs within consent limits. The customer authorises a reusable mandate — capped by amount and scope — so future agent-initiated purchases can proceed without full re-authentication until the customer revokes consent in their bank app.

How does the FCA Supercharged Sandbox relate to agentic payments?

The FCA's Supercharged Sandbox cohort 2 launched on 13 July 2026 with 21 firms testing advanced AI use cases, including safer agent-led payments and commerce. Participants such as TrueLayer are prototyping pay-by-bank initiation inside AI shopping agents under regulatory oversight through December 2026.

How do I choose an open banking provider for agentic checkout?

Evaluate providers on payment initiation latency, mandate or Bank on File support, webhook event granularity, idempotency handling, and sandbox fidelity per bank. Run server-side payment tests that mirror agent retry behaviour, then compare coverage for your target markets through a structured provider evaluation rather than feature checklists alone.

Conclusion

Agentic payments open banking is moving from conference slides to sandbox prototypes — with the FCA's July 2026 Supercharged Sandbox cohort treating agent-led pay by bank as a first-class use case. B2B teams should assume future checkout includes AI intermediaries and architect for API-native bank rails, explicit consent limits, and webhook-driven reconciliation from day one. Start with human-in-the-loop pay by bank, add Bank on File for repeat agent purchases, and shortlist providers on mandate and webhook depth before you market autonomous agent checkout to customers.