--- title: "ACP vs UCP vs AP2 vs x402: agentic commerce explained" description: Comparison of the four agentic-commerce protocols. ACP, UCP, AP2, and x402 each answer a different question — agent-surface checkout, merchant interoperability, delegated authorization, machine-to-machine payment. last_updated: 2026-05-13 canonical_url: https://agent-ready.dev/acp-vs-ucp-vs-ap2-vs-x402 --- # ACP vs UCP vs AP2 vs x402: agentic commerce explained > Four agentic-commerce protocols. Each answers a different question. Which combination you need depends on what your agent is buying, from whom, with whose money. ## At a glance | Criterion | ACP | UCP | AP2 | x402 | |---|---|---|---|---| | Question it answers | How does the agent hand off a purchase to a merchant? | How does an agent understand and use a merchant's full commercial system? | How does the agent prove it was allowed to act? | How does software pay other software for a single request? | | Maintainers | OpenAI + Stripe | Shopify + Google | Google | Coinbase (open spec) | | Primary buyer | Consumer (via an assistant) | Consumer (across surfaces) | Any — user or business | Software (agent, service, model) | | Settles in | Cards / wallets | Whatever the merchant accepts | N/A — authorization, not payment | Stablecoins (typically USDC) | | Status | Five dated releases since 2025-09; product scaled back | Active; Shopify supports alongside ACP | Active spec | Active spec; in use | | Responsibility layer it owns | Payment Credential, Settlement | Discovery, Merchant Relationship | Authorization | Settlement (machine-to-machine) | The last row maps each protocol to one of six layers a complete agentic-commerce stack has to address: discovery, authorisation, payment credential, settlement, merchant relationship, and governance. The six-layer split is from [Nate B Jones' May 2026 analysis](https://natesnewsletter.substack.com/p/agentic-commerce-protocol-war). ## What is ACP? The Agentic Commerce Protocol is an open spec for handing a structured purchase from an agent surface to a merchant's checkout. Co-maintained by OpenAI and Stripe. Launched alongside [Instant Checkout in ChatGPT on 2025-09-29](https://openai.com/index/buy-it-in-chatgpt/). In the launch configuration, Stripe processed the payment, OpenAI hosted the agent surface, and the supported merchant retained merchant-of-record status — responsible for fulfillment, returns, and customer support. Roughly five months after launch, OpenAI [scaled Instant Checkout back](https://www.wired.com/story/ai-lab-walmart-openai-shaking-up-agentic-shopping-deal/). Walmart told *Wired* in March 2026 that conversion on items sold directly inside ChatGPT ran three times lower than on the same items reached via click-out to the merchant site; OpenAI pivoted to letting merchants embed their own chatbots inside ChatGPT instead (Walmart's Sparky launched first). The spec itself kept iterating — ACP uses date-based versioning and has shipped five dated releases since launch (latest 2026-04-17); [PayPal joined as a second compliant payment provider on 2025-10-28](https://newsroom.paypal-corp.com/2025-10-28-OpenAI-and-PayPal-Team-Up-to-Power-Instant-Checkout-and-Agentic-Commerce-in-ChatGPT); and Shopify ships support for both ACP and UCP. Practical positioning today: ACP defines the data contract for an agent-to-merchant purchase exchange, independent of where the final checkout completes. ## What is UCP? The Universal Commerce Protocol is a broader agent-commerce spec than ACP. Instead of just the checkout handoff, UCP defines structured representations for the parts of a merchant's commercial system that ACP leaves implicit — catalogue and variant data, inventory state, cart construction, shipping rules, promotions, loyalty accounts, subscriptions, return and refund handling, post-purchase messaging. Backed by Shopify and Google. Spec at [ucp.dev](https://ucp.dev). The design assumption is that an agent transacting against a merchant needs more interface than a product feed plus a checkout URL. Returns, loyalty status, subscription terms, shipping eligibility, and post-purchase obligations all shape what a purchase actually means — and a protocol that completes a transaction without exposing those structures leaves the merchant unable to model its own business. UCP fits merchants that need agents to act on their conditions, not just their inventory. ## What is AP2? Google's [Agent Payments Protocol](https://ap2-protocol.org) specifies a *mandate*: a structured, verifiable record of the permission a principal (user or business) gave an agent. Each mandate carries scope (what the agent is allowed to do), constraints (limits, conditions, expiry), and an approval signature. AP2 sits above payment — a mandate doesn't move money; it records the authority under which money was moved. The separation matters because agent purchases decouple consent from execution. A mandate can be issued before the merchant or price is determined, then settled against minutes or days later under shifting context. Disputes have to be resolved against a record richer than a transaction receipt: which mandate authorised this action, did the parameters fit, was the agent acting within scope at the moment of execution. AP2 defines the data shape of that record. Stripe shipped a consumer-side product implementing the same idea in April 2026. [Link's wallet for agents](https://stripe.com/blog/giving-agents-the-ability-to-pay) accepts an OAuth grant from the user, takes per-purchase spend requests (merchant, amount, line items, purpose) from the agent, and returns a one-time-use card or Shared Payment Token scoped to that single transaction. AP2 is the protocol contract; Link's agent wallet is one product surface for it. ## What is x402? [x402](https://www.x402.org) is an HTTP-native machine-payment protocol from Coinbase. A client requests a paid resource; the server responds with `402 Payment Required` and a payment-instruction document; the client pays (typically USDC over a supported chain) and retries with proof of payment; the server returns the resource. Payment is encoded into the request/response cycle rather than handed off to a separate checkout surface. The target is per-request commerce at sub-cent to single-dollar granularity — an agent paying for one API call, a tool billing per invocation, a model service charging per generated token, a research agent buying per-document access. [Stripe's Machine Payments Protocol (MPP)](https://mpp.dev) and [Circle's Arc](https://www.circle.com/blog/introducing-arc-an-open-layer-1-blockchain-purpose-built-for-stablecoin-finance) serve the adjacent market with different settlement models. None of the three target consumer checkout: card networks remain the better fit there because they ship fraud monitoring, chargebacks, and dispute infrastructure that stablecoin rails don't replicate yet. ## How do ACP, UCP, AP2, and x402 differ? Four dimensions separate them cleanly: - **Scope.** ACP standardises one event — the agent-to-merchant checkout. UCP standardises the surrounding system — catalogue, cart, fulfillment, returns. AP2 standardises the authorisation that lets the agent act at all. x402 standardises the request-level payment exchange between machines. - **Counterparties.** ACP and UCP describe agent ↔ merchant interactions. AP2 describes principal ↔ agent authorisation. x402 describes software ↔ software resource exchange. - **Payment rail.** ACP and UCP are rail-agnostic but route through whatever instrument the merchant accepts — cards in practice. x402 is stablecoin-native (typically USDC). AP2 is not a payment protocol at all; it sits above whichever rail handles settlement. - **Human in the loop.** ACP assumes the buyer is engaged through an assistant surface. UCP makes no assumption about where the buyer is. AP2 explicitly handles the delegated case — agent acts later, against a stored mandate. x402 is designed for interactions with no human present. ## When should I use ACP? Implement ACP if you operate a merchant checkout and want ChatGPT-style assistants to be able to drive structured purchases against it. ACP gives the agent surface a typed request format and the merchant a typed response format for cart, totals, taxes, and confirmation. The payment side wires through Stripe, PayPal, or another supported provider; the merchant stays merchant of record. Post-walk-back, ACP's more durable use is the data contract itself — where the checkout UI lives (assistant, embedded merchant app, merchant site) is a product decision the protocol no longer forces. ## When should I use UCP? Implement UCP if your merchant surface depends on more than SKU-and-price — if returns, loyalty status, subscription terms, configurable bundles, region-conditional shipping, or warranty handling are part of how the purchase is defined. UCP gives agents a structured way to see those conditions and to act on them. The natural fit is merchants on Shopify or other full-stack commerce platforms whose business logic already lives in those structures. For a merchant whose offer is genuinely just SKU + price, ACP alone may be enough. ## When should I use AP2? Implement AP2 (or an AP2-compatible product like Stripe Link's agent wallet) when an agent is acting on behalf of a principal whose authority needs to be reconstructable after the fact. Enterprise procurement is the clearest case: finance and legal need to see, for any agent purchase, which mandate applied, what its limits were, who approved it, and whether the agent stayed inside scope. Consumer delegated-purchase flows ("book a hotel under $300 if you find one near the venue, by 5pm") fit the same pattern. If your agent transacts and a dispute is plausible, the mandate is the evidence artefact. ## When should I use x402? Implement x402 (or MPP or Arc) when the buyer is software and the unit of purchase is a single resource — an API response, a tool invocation, a generation, a document fetch. The protocol fits per-call billing models, agent-owned wallets with per-task budgets, and any service that wants to charge software clients without standing up a merchant checkout surface. For purchases initiated by a human, card-network rails remain the better fit because they carry the fraud, chargeback, and consumer-protection infrastructure that stablecoin rails do not yet replicate. ## Can I use more than one? Yes, and a complete agentic-commerce implementation usually composes several. A retailer might expose a UCP interface for agents to read its catalogue, accept ACP-formatted purchase requests at checkout, require an AP2 mandate as the evidence that the agent has authority to transact, settle most consumer purchases against tokenised card credentials, and bill any embedded API surface via x402. The four protocols target different layers and don't conflict. Autonomy should be tiered along the same axis as authorisation evidence. Low-value, easily reversible actions can execute against a standing mandate without re-confirmation. Higher stakes (large amounts, irreversible commitments, sensitive vendors) should trigger explicit re-approval before the agent transacts. Nate B Jones calls this pattern [graduated autonomy](https://natesnewsletter.substack.com/p/agentic-commerce-protocol-war); AP2's mandate structure is the place to encode the gradations. ## Frequently asked questions ### Are ACP, UCP, AP2, and x402 competing protocols? No. They answer different questions. ACP standardises how an agent and a merchant exchange structured purchase data at checkout. UCP standardises the whole shopping journey across merchants and agents — discovery, cart, identity, loyalty, returns. AP2 standardises delegated authorization so the agent can prove the user permitted the action. x402 standardises pay-per-request payments between software systems. A real-world retailer ends up touching several of them. ### Did OpenAI kill ACP when it scaled back Instant Checkout? No. OpenAI retired the product hypothesis that checkout itself should happen inside ChatGPT. The protocol kept iterating — PayPal joined as a second compliant payment provider on 2025-10-28, Shopify supports both ACP and UCP, and ACP has shipped five dated releases since launch (latest 2026-04-17, using date-based versioning rather than numbered revisions). What got cut back was the assistant owning the moment of transaction, not the data contract between agent and merchant. ### What's the difference between AP2 and Stripe's Link wallet for agents? AP2 is a protocol Google designed for the authorization record itself — a structured 'mandate' showing what a user permitted an agent to do. Stripe Link's wallet for agents, launched April 2026, is a product that ships an equivalent record. The user grants the agent OAuth access; the agent submits a spend request with merchant, amount, and line items; Link returns a one-time-use card or a Shared Payment Token scoped to that purchase. Same problem, different layer: protocol vs implementation. ### Should I use x402 instead of cards? Use x402 when the buyer is software — an agent paying an API, a tool charging per invocation, a model service billing per generated token. Consumer purchases initiated by a human are better served by card networks: cards ship fraud monitoring, chargeback handling, and dispute infrastructure that stablecoin rails haven't replicated. The decision is about transaction shape, not which technology is newer. --- Read the full guide on the web: Related tools: - UCP readiness: - x402 endpoint check: - Agent permissions: - Discovery protocols comparison: ## Sitemap See the full [sitemap](https://agent-ready.dev/sitemap.md) for all pages on agent-ready.dev.