Protocols · AP2 & UCP

What are AP2 & UCP?

Two Google-backed protocols that ship as a pair — one authorizes the payment, the other runs the purchase around it. This is one of the four payment rails this site covers as peers, on the same template at the same depth. Side by side with the others: the comparison matrix.

What is it?

AP2 (Agent Payments Protocol) is a permission system for agent spending: a Google-backed open protocol that authorizes agent payments through mandates. It sits above the movement of money — it defines who may pay and under what permission, while payment rails move the funds. Its first version supports card payments; its published roadmap adds e-wallets, real-time bank transfers such as UPI and PIX, and digital currencies.

UCP is a Google-backed commerce protocol for the broader shopping flow — discovery, offers, checkout — rather than the payment step alone. The name expands to Universal Commerce Protocol. Merchants adopt it to sell inside AI surfaces, and the merchant stays the merchant of record — the customer relationship and data remain theirs.

The two are designed to click together, which is why this site covers them on one page. A UCP checkout can activate AP2 as its trust layer: the merchant signs the checkout state, and the payment is authorized by mandates bound to that exact cart. AP2 also works as an extension of A2A, the agent-to-agent protocol.

The central object is the mandate — a tamper-evident, cryptographically signed digital credential. AP2 v0.2 defines two: a Checkout Mandate for the agreed purchase, shared with the merchant, and a Payment Mandate authorizing payment from a specific instrument, shared with the payment side. Each comes in two stages — open, standing constraints approved in advance, and closed, a specific finalized purchase.

Who is behind it?

Google announced AP2 on 2025-09-16, developed with a group of payments and technology companies. On 2026-04-28, Google donated the protocol to the FIDO Alliance, an industry association focused on open standards. Standardization now continues in two FIDO working groups: Agentic Authentication Technical and Payments Technical.

UCP is published as open source and co-designed with industry partners. Its specification lives at ucp.dev and on GitHub; Google documents merchant adoption in its own developer guide.

Both specifications are open standards under the Apache 2.0 license.

How does a payment flow?

The numbered flow below is the human-present case — you are there to approve. It is a plain-language rendering of the specification's own flow examples.

1. You shop through your agent. It assembles a cart with the merchant; the merchant signs the checkout and requires a mandate to continue.
2. The agent prepares the Checkout and Payment Mandates and hands them to a trusted surface — a display the agent cannot alter — for your approval.
3. You authenticate (a fingerprint, say) and consent. That signs both mandates, cryptographically linked so neither can be swapped later.
4. The Payment Mandate goes to your credential provider — the party holding your payment instruments — which verifies it and returns a payment token scoped to this purchase.
5. The agent sends the token and the Checkout Mandate to the merchant. The merchant checks the mandate against the cart as it stands, then initiates the payment.
6. The merchant's payment processor verifies the mandates and their bindings. Two signed receipts come back: a payment receipt and a checkout receipt.

The human-not-present case moves your approval earlier. You approve open mandates up front — the constraints inside which the agent may act alone: what to buy, from which instrument, within what budget. The agent then signs a closed mandate for each purchase it makes inside those constraints. A purchase that falls outside them can be refused and sent back for your approval — a built-in human-in-the-loop.

OTTO, our example agent, makes that concrete. Its operator approves one open pair: buy OCR processing at $0.01 per page, up to a set budget. Every page OTTO buys after that is a closed mandate signed inside that permission — and every one traces back to it.

Note what AP2 does not do: it moves no money. The mandate authorizes; the payment method underneath — a card network, in the current version — moves the funds. What the mandates add is a non-repudiable cryptographic audit trail, built to aid dispute resolution for purchases no human watched.

Where does it stand today?

AP2 is a published specification, currently v0.2, released 2026-04-28 alongside the FIDO donation. v0.2 introduced human-not-present payments — the autonomous case described above. Per Google's donation announcement, Verifiable Intent & Agent Pay — a peer rail on this site — is AP2-compatible and co-developed with Mastercard. The AP2 repository's sample scenarios pair the protocol with card payments and with x402.

UCP checkout is live on AI Mode in Google Search and on Gemini on the web, with the Gemini app listed as coming soon. Merchant onboarding is by waitlist. The published roadmap adds multi-item carts, account linking for loyalty programs, and post-purchase support.

What we cannot verify: no public settlement data is published by Google. AP2 payments settle on whatever payment method the mandate names — card networks today, which are private. So this page carries no usage numbers; the bar a number must clear is in the methodology.

Where are the primary sources?

• Read the AP2 specification — the mandate model and flow examples live here.
• Visit the AP2 repository — specification, samples, Apache 2.0.
• Read Google's AP2 announcement — 2025-09-16.
• Read the FIDO donation announcement — 2026-04-28.
• Read the UCP specification — including the UCP-and-AP2 integration guide.
• Visit the UCP repository — specification and documentation, Apache 2.0.
• Read Google's UCP merchant guide — adoption, surfaces, and roadmap.