What is Agent Payments Protocol?
The shift to agentic commerce
The way people shop is moving into AI. Discovery, comparison, checkout, and even post-purchase monitoring increasingly happen inside AI assistants rather than on a search results page or a brand's own site. This isn't a fringe behavior: 73% of consumers are already using AI in their shopping journey. And the money is following — Accenture estimates that by 2030, more than 30% of online commerce will run through AI agents, close to $3.1 trillion in transactions.
From scraping to brand-controlled protocols
Until now, AI assistants learned about products by scraping the open web – guessing at prices, availability, and specs from whatever pages they could read.
That era is ending.
Brands and the platforms behind these assistants are converging on agentic-commerce protocols: structured, brand-published feeds and endpoints that tell an AI exactly what you sell, what it costs, whether it's in stock, and how to complete a purchase. The difference is control – the brand, not a scraper, becomes the source of truth.
The catch is pace. Several of these protocols have emerged in just the last year, each backed by different platforms, and they ship new releases frequently. Staying compliant is an ongoing commitment, not a one-time integration. And each protocol takes a different approach.
What is AP2?
AP2 – Agent Payments Protocol – is an open source protocol, created by Google, for payments that an AI agent makes on a shopper's behalf. It is the payment layer: it defines how an agent proves it was authorized to buy something, and how a merchant and the payment parties check that proof. It is designed to work alongside commerce protocols rather than replace them, and it is designed explicitly to be compatible with the Universal Commerce Protocol (UCP).
It solves a trust problem. When an agent, not a person, completes a purchase, everyone in the chain needs evidence of what the shopper actually approved.
How it works
AP2 uses mandates, which are signed statements of what an agent is authorized to do. A Checkout Mandate gives the merchant cryptographic proof that the shopping agent may buy the exact checkout it assembled. A Payment Mandate gives the credential provider, the network, and the merchant's payment processor proof that the agent may pay for that checkout. When the shopper is not present, they can approve constraints up front in an open mandate, and the agent then signs the final mandates within those limits. Receipts come back when a mandate is accepted or rejected.
For a merchant, the discoverable part is small. AP2 appears as a UCP extension: the capability dev.ucp.common.payment.ap2_mandate in the business profile at /.well-known/ucp, extending the checkout capability, with the signing keys published in the profile's keys array. An A2A Agent Card can carry the same entry.
Who's behind it
The project was created by Google and is published as open source in the google-agentic-commerce organization on GitHub. The core specification has since been donated to FIDO, and the repository's contributing guide says contributions going forward are to the samples and the SDK only. The latest tagged version is v0.2.0.
Where it fits
AP2 is not a discovery or catalog protocol. UCP orchestrates the broader purchase, and AP2 is the specialized layer that authorizes and signs the payment, which merchants will be able to integrate as an extension within UCP for agent-driven transactions. What a website can publish ahead of time is the part this check reads: the capability, the keys, and a consistent Agent Card. The signing and verifying only happens in a live purchase, which this check never makes.
You can run a completely free check to see whether your AP2 advertisement measures up against the current AP2 spec right now. And if you would rather not hand-build and maintain that surface as the specification evolves, CorgiMaps connects to your existing data and exposes protocol-compliant endpoints for you, with no changes to your fulfillment stack.