TLDR;
Google introduced AP2, a protocol that records what a customer has authorised an AI agent to buy. Merchants can use those signed records to check consent. Brands still need to make sure orders, payment retries and disputes are handled properly.
What happened
Google introduced the Agent Payments Protocol (AP2), designed to let AI agents make purchases with verifiable user authorisation. The open protocol uses signed mandates to record what the buyer agreed to, giving payment providers and merchants a common foundation for transactions initiated by assistants.
Why it matters
An assistant saying it has permission to buy is insufficient evidence for an enterprise payment flow. Signed mandates can distinguish a customer’s shopping instruction from the final transaction, giving merchants a clearer record to reconcile against the order. That is a stronger foundation than allowing a browser agent to improvise its way through checkout.
The difficult part is proving that the order still matches the instruction when money changes hands. A customer might authorise a laptop below a particular price, then the available model, delivery charge or stock position could change. Those differences matter even if the assistant believes it has found a suitable substitute. For a merchant, the record needs to connect the customer's limits to the actual basket, rather than merely show that some permission existed earlier in the conversation. AP2 is therefore interesting as an accountability mechanism. It does not remove the need for a merchant to decide which changes require fresh approval, who carries the cost of a failed purchase or how support staff explain the transaction. Brands should judge it against those operational questions before treating faster checkout as a guaranteed commercial benefit.
How your brand can benefit / be affected
Treat AP2 as an integration assessment, rather than a reason to replace your payment stack. Map who issues, verifies and retains each mandate; test expiry, price changes, retries and cancellation. A mandate for one basket should not silently authorise a different product or a larger total.
Payment, commerce and security teams should agree acceptance criteria before a pilot. Measure completion rate, duplicate orders and disputed authorisation alongside conversion. The commercial benefit comes from reliable authorised purchases, not displaying another protocol logo.
Start with a tightly bounded use case, such as a repeat purchase of an identified product at an agreed maximum total. Write down the permitted product, quantity, delivery destination and validity period. Then walk through situations where one of those conditions changes. The point is to define what your own systems must reject or send back for approval; this is a proposed merchant acceptance policy, not a claim that every AP2 integration already handles those cases. Give customer service a usable explanation of the authorisation so a disputed order does not become a technical investigation that the buyer has to wait for.
Keep payment success and order success separate in reporting. An authorised payment can still lead to an unavailable item, a duplicate fulfilment request or an incorrect delivery promise. Reconcile the agent instruction, payment reference and merchant order identifier, and check what happens when a response is lost after a successful transaction. Compare the pilot with the existing checkout on completed, correctly fulfilled orders and support cost, rather than the number of payment attempts. If the protocol improves the evidence trail without improving those outcomes, it may still reduce risk, but that is a different investment case from increasing sales.
News date: 16 September 2025. Editorial review: 16 September 2026. Analysis includes subsequent developments where stated.