AI agent payments are transactions that software initiates and completes on its own, inside limits defined in advance. Moving the money is the easy part. The rails already do that well. The hard part is proving, at the moment of payment, that someone with authority said yes. Google put it plainly when it launched AP2: today's payment systems assume a human is clicking buy.
Every agent payment system on the market answers one question: how does an agent get permission to spend? This guide sets the four answers side by side, shows what UK law already counts as consent, and ends with a checklist for a business about to let an agent spend its money. Where a topic deserves more depth, we link to the dedicated guide.
What AI agent payments actually are
The phrase covers two very different things.
Two shapes: proxy purchases and machine native micropayments
Proxy purchases. An agent buys what a person would have bought: a flight, a software seat, a supplier reorder. The ticket is familiar, the merchant is familiar, and the payment usually runs over cards or bank transfer.
Machine native micropayments. A report published by Visa describes the cycle: an agent calls an API, receives an HTTP 402 "Payment Required" response, evaluates the price, pays, and consumes the resource. That takes milliseconds and needs no checkout page, saved card or browsing session. The same report frames the difference in three dimensions. Human commerce is low frequency, medium to high value, and happens between parties with an existing relationship. Agent micropayments are high frequency, low value, and happen between parties who have never met.
The second shape is already measurable. Keyrock's 2026 report, summarised by OpenZeppelin, found agents settled over 73 million USD across 176 million blockchain transactions between May 2025 and April 2026, with 98.6 percent of it in USDC. Divide one figure by the other and the average payment is roughly 41 US cents. That is not a checkout. That is a meter.
The four layers of every agent payment
Whatever the shape, an agent payment passes through four layers: identity, authorization, checkout and settlement. Most of the confusion in this market comes from comparing protocols that sit on different layers.
| Layer | The question it answers | Examples |
|---|---|---|
| Identity | Is this a real, known agent? | Web Bot Auth, Visa Trusted Agent Protocol |
| Authorization | Did someone with authority approve this spend? | Agentic card tokens, AP2 mandates |
| Checkout | What exactly is being bought, at what price? | Agentic Commerce Protocol, HTTP 402 challenges |
| Settlement | How does the money actually move? | Cards, bank transfer, stablecoins |
Permission lives in the authorization layer, and that is where the four models below differ. Settlement is a separate choice, covered in our guide to AI agent payment rails.
How an agent gets permission to spend: four models
1. Agentic card tokens
Mastercard's approach starts with identity. Under its Agent Pay Acceptance Framework, agents are registered and verified before they can transact on the network, then pay with agentic tokens. The framework also carries purchase intent data: cart contents, transaction limits and validity windows, which gives the merchant an audit trail for disputes. Each time an agent acts, it does so with the permissions and limits you define, and every transaction is tied to a specific Agent Pay interaction, so you can see which agent acted.
Visa's equivalent is Visa Intelligent Commerce. The Visa report linked above dates its announcement to April 2026 and describes it as protocol agnostic, with tokenisation, passkey authentication and programmable spend controls that let users set dollar limits, restrict merchant categories or require real time approval.
The strength of this model is inheritance: card networks bring decades of KYC, fraud tooling and dispute handling. The same report is clear that cards are being extended, not replaced, and treats the new micropayment protocols as architecture that expands commerce above the card layer.
2. Signed mandates
AP2 moves permission out of the card and into a document. Mandates are tamper proof, cryptographically signed verifiable credentials that record what the human approved. The protocol is built around three questions, authorization, authenticity and accountability, and supports both Human Present and Human Not Present flows.
The practical value is evidence. A token proves an agent was allowed to pay. A signed mandate proves what it was allowed to buy, which is the question that matters when a payment is disputed. AP2 is also payment agnostic, so the same mandate can sit over cards, stablecoins or bank transfers. The mechanics of the mandate chain are in our guide to AP2 mandates.
3. Pay per request over HTTP 402
For APIs, data and compute, permission is often just a wallet and a price. The flow Cloudflare documents is short: request, 402 challenge, payment, retry with credential, verification, receipt. The x402 "Upto" payment type, described in the Visa report, lets an agent authorise a maximum and pay only for what it consumes, which caps exposure on any single request.
The large platforms are building it in. AWS made AgentCore payments generally available in August 2026, letting agents discover, access and pay for paid APIs, MCP servers and content on their own.
The weakness is identity. The Visa report notes that most agents authenticate with API keys or wallet addresses, which verify access but say nothing about history or reliability. Most of this traffic settles in stablecoins; the trade offs are in our guide to stablecoin payments for AI agents.
4. A funded account with hard limits
The last model is not a protocol. It is the backstop under all of them. Every token, mandate and wallet draws on money held somewhere. The Visa report describes programmable spend controls on both sides of the market: wallet policy layers that encode allowlists, spend caps and merchant routing, and tokenised card credentials with issuer defined spending rules.
A dedicated account funded with only the agent's budget caps the worst case at its balance, whatever the protocol above it does. It is the least clever control on this list and the one that still works when the others fail. What to require from the provider holding that money is covered in AI agent payment infrastructure.
The four models side by side
| Model | Where permission lives | Best fit | Human step up |
|---|---|---|---|
| Agentic card token | Token scope and limits set at issuance | Proxy purchases at existing merchants | Passkey confirmation on unusual spend |
| Signed mandate | Signed credential carried with the payment | Purchases that need provable intent | Human Present flow |
| HTTP 402 pay per request | Wallet balance and a per request cap | APIs, data, compute | Rarely, per call |
| Funded account with limits | Balance plus your own policy rules | Every model, as the backstop | Approval above your threshold |
These are not rivals. A mature setup uses several: a mandate to prove intent, a token or wallet to pay, and a ring fenced account so the damage from any failure has a ceiling.
What UK law treats as consent
Protocols describe permission technically. The law defines it. Under regulation 67 of the Payment Services Regulations 2017, a payment transaction is authorised only if the payer has consented to that transaction, or to a series of transactions of which it forms part. That "series" wording is why a mandate given in advance is the natural legal shape for agent spending. Whether a particular setup fits it is a question for your lawyers and your provider.
The gap sits elsewhere. Strong customer authentication assumes a human exercising judgment at the moment of authorisation. An agent that is deceived can still produce a payment that is formally authorised.
Government knows this. On 14 July 2026 HM Treasury published the Financial Services AI Adoption Plan and the Modernising Payment Services Regulation consultation, which asks how existing regulation should adapt for agentic payments. One proposal discussed by lawyers is staged authorisation: an initial mandate, then a check of each transaction against its parameters. That is close to what well designed agent setups already do.
This is general information, not legal advice. For the liability picture in full, read our analysis of whether AI agent payments are safe.
A permission checklist before you let an agent pay
- •Match the model to the job. Proxy purchases suit tokens or mandates. Metered API spend suits a capped wallet. Do not force one model onto both.
- •One credential per agent. When every transaction is tied to a specific agent, you can see which one acted and revoke one without touching the rest.
- •Write the limits down. Amount per transaction, amount per period, allowed merchants or categories, and a validity window. These are the parameters the card networks and AP2 already carry, so use them.
- •Keep a human above a threshold. Visa describes agents that ask you to confirm a purchase that is high value or unusual with a passkey. Set your own threshold before the first payment, not after the first surprise.
- •Keep the evidence. Mandates, intent data and receipts are your record of what was approved. In a dispute, the record is the argument.
- •Ring fence the money. Fund a separate account or balance with the agent's budget only, never the operating account.
- •Test revocation. Revoke a credential in a test run and confirm payments actually stop before you rely on it.
Where EX FI fits today
A straight answer, because this is a regulated topic.
EX FI today provides multi-currency business payment accounts with dedicated IBANs and access to SWIFT, SEPA, FPS, BACS and CHAPS. In the terms of this guide, that is the funded account layer: the balance an agent's card, mandate or wallet ultimately draws on, held apart from operating cash. The agent native primitives shown on the site (agent wallets, signed spending limits, programmable compliance) and the USD and EUR stablecoin rails are announced for selected partners later in 2026. They are not live, and nothing here should be read as saying they are.
The regulatory position, stated exactly: EXFI is a trading name of EX Financial Solutions Ltd (company number 17105188), which is not itself authorised or regulated by the FCA. It acts as a distributor of payment services provided by Gemba Finance Limited, which is authorised and regulated by the Financial Conduct Authority as a payment institution (FRN 804853). EXFI accounts are payment accounts, not bank accounts. Funds are not covered by the FSCS; they are safeguarded in segregated accounts under the Payment Services Regulations 2017. Services are for business customers, and the live site states UK customers only.
FAQ
Can an AI agent pay without a human approving every transaction?
Yes, within permissions set in advance. AP2 defines Human Not Present flows, and agentic card tokens carry the limits you define. The usual design is to let the agent act alone below a threshold and ask a human to confirm above it.
Who is responsible if an AI agent makes a payment I did not want?
In the UK it depends on what you consented to. If the payment falls within a series you approved, it may count as authorised even if the outcome was wrong. The rules are under consultation, so take legal advice for your own setup.
Do AI agents need crypto to make payments?
No. Agentic card tokens and AP2 work over existing rails, and AP2 is payment agnostic. Stablecoins dominate on chain agent volume, which is mostly very small, very frequent payments, but that is one shape of agent payment, not all of them.
What is the difference between agentic commerce and AI agent payments?
Agentic commerce is the whole journey: an agent searches, compares, applies your preferences and buys. The payment is the step where money moves, and the step where permission has to be proven rather than assumed.