Search the AP2 protocol for AI agent payments and you will get a confident, consistent answer. AP2 is Google's protocol, it uses three mandates called Intent, Cart and Payment, and it chains them into an audit trail.

Every part of that sentence is now out of date.

Google gave AP2 away. It donated the protocol to the FIDO Alliance and released v0.2 on GitHub at the same time, adding Human Not Present payments so an agent can execute a purchase autonomously against instructions the user pre-authorised. And v0.2 does not have three mandates. It defines two mandate types, Checkout and Payment, each existing in an open and a closed stage.

The lag is not just a blog problem. Third-party explainers still describe the v0.1 model, and some AP2 sample code and related specs still reference the retired CartMandate artefact. If your engineering team built a mental model from a search result last quarter, it is describing a version that no longer exists.

So here is the current protocol, from the specification rather than from the launch coverage. And then the part none of those pages reach: what a signed mandate proves when a payment goes wrong in the UK, which is a smaller thing than the word "mandate" makes it sound.

What AP2 is actually for

Card systems assume a person is at a screen clicking buy. An agent breaks that assumption, which leaves three open questions: whether the user gave the agent authority for this particular purchase, whether the merchant can trust that the request reflects the user's real intent rather than a hallucination, and who is accountable when a transaction turns out to be wrong.

AP2 answers those with signed credentials rather than with rails. It is deliberately payment agnostic, works across cards, bank transfers and stablecoins, and can be used as an extension of the Agent2Agent protocol and of MCP. It moves no money at all.

That is worth stating flatly because the most common mistake in this space is comparing AP2 to something it does not compete with. An agent payment has four layers: identity asks whether the agent is who it claims to be, authorization asks whether a human approved this and within what limits, checkout completes an order with a merchant, and settlement is how the money moves. AP2 owns the second one. If you want the buyer's view of how those stack, we set it out in the three layers of agent payment infrastructure, and the bottom layer specifically in where x402 and stablecoin settlement fit.

The two mandates in AP2 v0.2

The Checkout Mandate proves what was bought

The merchant assembles the order and signs it as a JWT. The Checkout Mandate gives the merchant cryptographic proof that the shopping agent was authorised to buy the checkout it assembled, and the closed mandate is bound to that merchant-signed JWT by a cryptographic hash. The merchant verifies it, then must return a signed Checkout Receipt either way.

The Payment Mandate proves what was paid

The Payment Mandate proves to the credential provider, the network and the merchant payment processor that the agent was authorised to pay for one specific checkout. Its transaction_id field is the hash of that same checkout JWT, it carries the payee, the payment instrument and an amount in ISO 4217 minor units, and an optional execution date.

That shared hash is the quiet piece of design in the whole protocol. The cart itself is selectively disclosable while the hash is not, so the agent can withhold the line items from a payment processor that has no business knowing what you bought, and the digest still binds the payment to that exact cart. One shared value lets a dispute adjudicator later reunite two credentials that were deliberately shown to different parties.

Open and closed is the distinction that matters

Each mandate type exists twice. The open form captures the user's constraints and goals before a specific cart is finalised, for autonomous execution. The closed form captures authorisation for a specific, finalised transaction.

Open is where the delegation lives. Closed is where the delegation is spent. Almost every practical question about agent spending is really a question about what the open mandate said.

Human present and human not present

In the direct flow, the agent hands the finalised checkout to a Trusted Surface, the user sees the closed checkout and signs it. In the autonomous flow, the user approves a set of constraints instead, and the agent then assembles and signs the closed mandate itself using its own key. Open mandates in this mode must include the agent's public key as a cnf claim, and the specification recommends setting expiry to the smallest value that lets the agent finish the assigned task. Verifiers always receive a closed mandate either way; only the basis of verification changes. An agent must not present a further open mandate until it has a rejection receipt for the previous one, which stops one delegation being spent on several carts.

Read that last clause as an operator, not as a cryptographer. A short expiry and a one-use rule are blast radius controls. They are the protocol admitting that the agent is the part of the system most likely to be wrong or compromised.

The constraints are the actual control surface

An open mandate is only as good as what it bounds, and the spec is specific rather than aspirational about that. On the checkout side there are two constraint types: allowed merchants, and line items defining which SKUs in what quantities. On the payment side there are eight: allowed payees, allowed payment instruments, allowed payment initiation service providers, an amount range in minor units, a cumulative budget, agent recurrence, an execution date window, and a reference tying the payment to one open Checkout Mandate.

Those are the limits worth caring about, because they are evaluated by verifying parties outside the model. A constraint checked by a merchant or a credential provider is a limit that survives a prompt injection. A limit written into an agent's system prompt is a suggestion, and a model can be talked out of a suggestion.

This is the same reasoning that decides the rails an agent payment eventually lands on: put the enforcement where the attacker is not.

Where AP2 lives now, and why the handover matters

AP2 launched in September 2025 with backing from more than 60 merchants and financial institutions, which was always the interesting number. A payment standard with one owner is a product decision. A payment standard with the networks in the room is infrastructure.

That transition is now formal. On 28 April 2026 the FIDO Alliance announced an Agentic Authentication Technical Working Group chaired by members from CVS Health, Google and OpenAI and vice-chaired by members from Amazon, Google and Okta, with agent-initiated commerce specification work running in its Payments Technical Working Group, chaired by members from Mastercard and Visa. Google contributed AP2 and Mastercard contributed its Verifiable Intent framework as the initial foundation. Google's own FAQ confirms the core specification work continues in FIDO.

For a buyer that cuts both ways, and it is worth being honest about both. Committee governance makes the spec less likely to be withdrawn or bent to one vendor's roadmap. It also makes it slower, and it means the version you integrate against this year is unlikely to be the version that settles. Budget for a migration, because the v0.1 to v0.2 change already forced one.

What a mandate proves, and what it does not

Here is where the coverage stops and the useful question starts.

AP2's own claim about accountability is carefully worded, and the wording is the point. In a dispute, a network adjudicator can use the user-signed Checkout Mandate to compare what was agreed between the agent and the consumer against the details of the dispute, to help determine transaction accountability. Help determine. Not determine. The protocol produces evidence, and it produces unusually good evidence, but evidence is an input to a decision that a different rulebook makes.

In the UK that rulebook is the Payment Services Regulations 2017, and its central provision is short. A payment transaction is regarded as authorised only if the payer has given consent to the execution of that transaction, or of a series of transactions of which it forms part, in the form and in accordance with the procedure agreed between the payer and its payment service provider.

Notice what that does not say. It does not say a cryptographic signature settles it. It asks whether the payer consented, in the agreed form and procedure, and that is a question about the contract between a customer and a provider rather than about a credential format.

The consequences are specific. The burden of proving authentication sits with the provider where a payer denies authorising a transaction, and recorded use of an instrument is not in itself necessarily sufficient. The refund duty in regulation 76 arises where a transaction was not authorised in accordance with regulation 67, so how the failure is characterised decides the outcome. Where a customer set the limits too loosely the payment usually falls inside the consent, because the agent did what the delegation permitted, while a payment produced by prompt injection may be unauthorised depending on the agreed consent procedure and the scope of the mandate. Regulation 63(5) lets a payer that is not a consumer, micro-enterprise or charity agree to disapply regulations 75 and 77, but regulation 76 is not in that list, so the provider's duty to refund an unauthorised transaction survives even a business agreement. And configured parameters are not the same thing as the payer's legal consent.

That last sentence is the one to take into a vendor meeting. An AP2 open mandate is a very good record of configured parameters. Whether those parameters amounted to consent is fact-specific, and no amount of signing changes which question is being asked.

The rules are also not finished. HM Treasury's Modernising Payment Services Regulation consultation states that the PSRs were designed before the development of AI and may not fully facilitate the use of agentic AI, and its question 15 asks how existing payment services regulation needs to adapt, including whether the provisions on authentication, consent and liability for unauthorised transactions need updating. That consultation was published on 14 July 2026 alongside the Financial Services AI Adoption Plan, whose Recommendation 10 proposes an agentic payments trust framework and a Know Your Agent standard, and it closes on 6 October 2026.

An open consultation question is not a gap in the law. It means the framework applies and the government is asking whether it should be adjusted. For a business, that is a reason to keep good records now, not a reason to wait.

What to do with AP2 while the law catches up

Four things, all of which cost little and all of which matter more the earlier you do them.

  1. •Ask which version a vendor implements. If the answer mentions an Intent Mandate or a Cart Mandate, they are describing v0.1. That is a question about how current their build is, not a gotcha.
  2. •Treat the mandate chain as an evidence file, not as a log. The mandates and receipts are what a dispute is decided from months later. Retention and retrieval are deliberately left outside the spec, so they are yours to solve.
  3. •Keep every limit in constraints, never in a prompt. Allowed payees, amount range and budget are enforced by parties the agent cannot argue with.
  4. •Ask whose licence the balance sits under. The settlement layer under an AP2 flow is still an account belonging to some entity under some permission, which is the question what an authorised payment institution is permitted to do exists to answer.

For our own position, stated the way we would want a vendor to state theirs. EXFI is a trading name of EX Financial Solutions Ltd, company number 17105188, which is not itself authorised or regulated by the FCA and acts as a distributor of payment services provided by Gemba Finance Ltd, authorised and regulated by the FCA as a payment institution under FRN 804853. EXFI accounts are payment accounts, not bank accounts, they are not covered by the FSCS, and funds are safeguarded in segregated accounts in accordance with the Payment Services Regulations 2017. What runs today is multi currency payment accounts with dedicated IBANs and access to SWIFT, SEPA, FPS, BACS and CHAPS for business customers. Agent-native banking primitives are announced roadmap. They are not live, and we will not write about them as though they were.

Before any of this goes near production money, work through whether agent payments are safe yet.

This article is general information about how the AP2 protocol is structured and how UK payment rules apply to agent-initiated payments. It is not legal or financial advice.

FAQ

Is AP2 still a Google protocol? No. Google donated it to the FIDO Alliance, announced on 28 April 2026, and core specification work continues there. Agent-initiated commerce work sits in FIDO's Payments Technical Working Group, chaired by members from Mastercard and Visa, with Mastercard's Verifiable Intent framework contributed alongside AP2 as a second foundation.

What happened to the Intent Mandate and the Cart Mandate? They belonged to v0.1. Version 0.2 replaced them with two mandate types, Checkout and Payment, each existing in an open form that carries constraints and a closed form bound to one finalised transaction. Expect to translate when reading older explainers and sample code, which still reference the retired artefacts.

Does AP2 move money? No. It is the authorization layer and is payment agnostic across cards, bank transfers and stablecoins. Settlement runs on a separate rail underneath, which is why comparing AP2 to a settlement protocol like x402 is a category error rather than a competitive question. They compose.

Does a signed AP2 mandate make a payment authorised under UK law? Not by itself. Regulation 67 of the Payment Services Regulations 2017 asks whether the payer consented to that transaction, or to a series of which it forms part, in the form and procedure agreed with the provider. A mandate is strong evidence of what was approved, but whether the limits handed to an agent amounted to legal consent is fact-specific and turns on the contract.

Can a business agree to carry the loss when an agent pays the wrong party? Only partly. A payer that is not a consumer, micro-enterprise or charity may agree with its provider to disapply regulations 75 and 77 under regulation 63(5). Regulation 76 is not in that list, so the provider's duty to refund an unauthorised transaction survives the agreement, which means the characterisation question comes first and the contract question second.