AP2 vs Agentic Commerce Protocol: authorization evidence and checkout

AP2 (Agent Payments Protocol) is for proving what a user authorized an agent to buy and how to pay, with signed mandates that a merchant, a payment processor and a credential provider can each verify. The Agentic Commerce Protocol is for running the checkout itself between an AI agent and a merchant: creating a checkout session, updating it, completing it, and handing over a payment token limited to that purchase.

They overlap less than their names suggest. AP2 says outright that it is a security feature inside a commerce protocol, and it leaves catalogs and checkout APIs out of scope. The Agentic Commerce Protocol is a commerce protocol: it defines the checkout endpoints and its own way to delegate a payment credential.

Status as of September 26, 2026.

• AP2: created by Google. v0.1.0 was released on September 16, 2025. v0.2.0 was released on April 28, 2026, and on the same day Google announced that it is donating AP2 to the FIDO Alliance. The specification and code are still published from Google’s google-agentic-commerce GitHub organization, under Apache 2.0.
• Agentic Commerce Protocol: announced by OpenAI on September 29, 2025, together with Instant Checkout in ChatGPT, and maintained by OpenAI and Stripe. The repository marks it as beta, under Apache 2.0. It uses date-based versions; the latest release is 2026-04-17, which deprecated 2026-01-30.

The Agentic Commerce Protocol is sometimes shortened to “ACP”, which collides with IBM’s Agent Communication Protocol. That one merged into A2A; see A2A vs ACP.

What AP2 is for

AP2 v0.2 defines five roles. The Shopping Agent finds products, builds the checkout and executes the purchase. The Credential Provider holds the user’s payment credentials and scopes them. The Merchant provides the checkout and vouches for items and prices. The Merchant Payment Processor checks that the credential it receives was authorized for this checkout. The Trusted Surface is a user interface that collects the user’s consent before a mandate is signed, and the specification requires it to be non-agentic.

The evidence is carried in two mandates, which replaced v0.1’s Intent and Cart Mandates:

• A Checkout Mandate covers what is bought. It is bound by hash to a checkout the merchant has signed.
• A Payment Mandate covers how that checkout is paid. It is bound by hash to the same checkout.

Each mandate comes in two forms. A closed mandate is bound to one specific transaction, and the user approves it directly when present. An open mandate carries constraints the user approved in advance. In a human-not-present flow, the Shopping Agent later signs closed mandates within those constraints, using a key the open mandate names in its cnf claim. The specification uses SD-JWT verifiable credentials with key binding. The mandates can later serve as evidence in a dispute, and the specification defines a receipt for each.

The AP2 documentation says AP2 is available as an extension for A2A and for the Universal Commerce Protocol, and its samples show card and x402 payments.

What the Agentic Commerce Protocol is for

The core is the Agentic Checkout API, which the merchant implements and the agent calls:

Operation	Purpose
POST /checkout_sessions	Create a checkout from items and buyer details
POST /checkout_sessions/{checkout_session_id}	Update items, fulfillment or buyer details
GET /checkout_sessions/{checkout_session_id}	Read the current state
POST /checkout_sessions/{checkout_session_id}/complete	Complete the purchase with a payment token
POST /checkout_sessions/{checkout_session_id}/cancel	Cancel the checkout

Requests carry a bearer API key, an API-Version header and an Idempotency-Key, and can be signed with Signature and Timestamp headers. The merchant sends order events back to the agent through webhooks. OpenAI’s announcement says the merchant remains the merchant of record.

Payment credentials move through the Delegate Payment API, which issues a delegated vault token for a card. The token can only be used within an allowance, and one_time is currently the only usage pattern. Illustrative allowance, following the 2026-04-17 schema:

{
  "allowance": {
    "reason": "one_time",
    "max_amount": 4500,
    "currency": "cad",
    "checkout_session_id": "cs_illustrative_001",
    "merchant_id": "merchant_illustrative_001",
    "expires_at": "2026-09-26T18:00:00Z"
  }
}

Stripe’s implementation uses its Shared Payment Tokens. Version 2026-04-17 also added a discovery document at /.well-known/acp.json, cart and product feed APIs, and an MCP binding that exposes the checkout operations as MCP tools alongside REST.

Side by side

	AP2 (v0.2)	Agentic Commerce Protocol (2026-04-17)
Purpose	Verifiable evidence of what a user authorized an agent to buy and pay	A checkout flow between an AI agent and a merchant, with a scoped payment token
Layer	Authorization and evidence layer inside a commerce protocol	Commerce protocol: checkout, cart, feeds, orders, delegated payment
Who talks to whom	Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor, Trusted Surface	Agent platform and merchant; payment provider for delegated tokens
Transport	Carried by the host protocol; documented as an extension for A2A and UCP	REST (OpenAPI 3.1), with an MCP binding added in 2026-04-17
Discovery	Not defined by AP2; inherited from the host protocol	/.well-known/acp.json capability document
Auth and evidence	User-signed mandates (SD-JWT with key binding); agent-signed closed mandates in autonomous flows	Bearer API key; optional request signatures; allowance-limited vault token
State	Mandate chain from open to closed, plus receipts	Checkout session state, completed into an order
Governance and status	Created by Google; v0.2 (April 28, 2026); being donated to the FIDO Alliance	Maintained by OpenAI and Stripe; beta; technical steering committee of up to seven organizations, founding maintainers keep a last-resort veto

When to use AP2

Use AP2 when you need to show, later and to a third party, that the user approved this purchase. That matters most when the user is not present: an agent buying within a budget, or at a price trigger. AP2 is also the fit when your commerce flow already runs over A2A or the Universal Commerce Protocol, since its documentation targets both.

When to use the Agentic Commerce Protocol

Use it when you are a merchant that wants to sell through agent platforms that implement it, or an agent platform that wants a documented checkout to call. It gives you concrete endpoints, schemas, examples and reference implementations from OpenAI and Stripe, and a token model that limits what a delegated credential can be used for.

Using both

The two answer different questions: the Agentic Commerce Protocol answers “how does this checkout happen”, and AP2 answers “what did the user approve”. A merchant can support both surfaces. Keep the limits of today’s specifications in view:

• Neither specification defines how to attach AP2 mandates to an Agentic Commerce Protocol checkout. Any such combination is a bilateral design that other parties will not understand.
• The allowance on a delegated token limits amount, merchant, checkout session and expiry. It is not a user-signed record of intent, and an AP2 mandate is not a payment token. Do not treat one as a substitute for the other.
• Both are young and still changing: AP2 is at v0.2 and changing hands, and the Agentic Commerce Protocol is labelled beta and ships dated versions.

For how AP2 relates to HTTP-level payments, see the AP2 and x402 glossary entries.

Common misconceptions

“They are competing payment protocols.” AP2 is an authorization and evidence layer. The Agentic Commerce Protocol is a checkout protocol with a token handoff. They meet at the payment credential, but they are built for different jobs.

“AP2 moves money.” AP2 defines mandates and receipts that other parties verify. Settlement happens on existing rails, such as card networks or x402.

“The Agentic Commerce Protocol only works in ChatGPT.” It launched with Instant Checkout in ChatGPT, but the specification is open under Apache 2.0, and its README describes it as a standard for connecting buyers, their agents and businesses.

“A delegated token proves the user agreed to the purchase.” It proves the agent platform tokenized a credential with limits. What the user saw and approved is outside the token, which is the gap AP2’s mandates are designed to fill.