UCP vs ACP: Agentic Commerce Protocols Compared, With AP2 and MPP

In about a year, agent commerce went from one or two experiments to a shelf of protocols with similar names. A team adding agent checkout to a store, or adding purchasing to an agent, now has to work out which ones matter, whether they compete, and what each one asks of its own systems.

Most comparisons stop at “who backs it.” That is useful for predicting adoption and useless for building. The more practical question is which layer of a purchase each protocol covers, because that tells you which decisions it makes for you and which it hands back.

This page compares five protocols, AP2, ACP, UCP, x402 and MPP, on backers, layer and the state each one assumes someone else holds. Each has its own page in this series for the detail.

UCP vs ACP: The Short Answer

UCP vs ACP: both are open standards for an AI agent to buy from a merchant. ACP, founded by OpenAI and Stripe, started as a checkout session API with a delegated payment token and added cart, catalog feed, orders and a discovery document in its 2026-04-17 release. Google’s UCP spans discovery, catalog, cart, checkout and order, with payment through pluggable handlers and an optional AP2 mandates extension. A merchant can support both.

They overlap most at checkout. ACP’s checkout RFC is a session API: create, update, retrieve, complete, cancel, with the merchant as “the system of record for all orders, payments, taxes, and compliance.” UCP’s specification starts with a business profile published at /.well-known/ucp that agents use to negotiate capabilities, and its cart converts into a checkout by cart_id. ACP’s 2026-04-17 release added a discovery document at /.well-known/acp.json and a cart, but its cart RFC defers cart-to-checkout conversion to a later proposal.

Neither defines when stock is held. In both, that is the merchant’s call. More on that below.

UCP vs ACP, Side by Side

The two specifications now cover similar ground, so the useful comparison is how each step works.

Sources: UCP announcement, UCP specification, ACP launch, ACP 2026-04-17 changelog, ACP Delegate Payment spec.

The catalog row is the difference a merchant feels first. Under UCP, the agent asks the business what it sells. Under ACP’s Feed API, the endpoints “are hosted by Agents and called by merchants,” per the changelog, so the merchant decides when its product records reach the agent. Either way, the price and availability an agent sees are only as current as the last answer or the last push.

Where MCP Fits: MCP vs UCP vs ACP

MCP comes up in the same conversations, and it isn’t a commerce protocol. Anthropic introduced it in November 2024 as “an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools.” It defines how an agent discovers and calls tools. It says nothing about carts, checkouts or payment.

UCP and ACP both use it as a transport. The UCP specification defines bindings for REST, MCP, A2A and an embedded protocol, and Google’s announcement says UCP is “compatible with existing industry protocols like Agent2Agent (A2A), Agent Payments Protocol (AP2) and Model Context Protocol (MCP).” ACP’s 2026-04-17 release added an MCP transport binding with five tools, from create_checkout_session to cancel_checkout_session, each mapped to a REST endpoint.

So the choice is never MCP or UCP. An agent can reach a UCP or ACP checkout over MCP, and the checkout rules are the same either way.

The Five Protocols at a Glance

Sources: AP2 announcement, AP2 site and FIDO donation, ACP launch and repository and governance, UCP announcement, x402 whitepaper and Linux Foundation release, MPP launch.

The Four Layers of an Agent Purchase

It helps to split a purchase into four steps and ask who owns each.

Discovery. The agent finds a seller and learns what it supports: catalog, prices, payment methods. UCP covers this with the published business profile and catalog search. ACP’s 2026-04-17 release added a discovery document at /.well-known/acp.json and a Feed API in which “merchants push product catalog metadata and product records to Agents,” per its changelog.

Checkout. Agent and merchant agree on a cart, price, tax and fulfillment. ACP and UCP both define this as a session with states.

Payment authorization. Someone decides the payment may proceed, and can prove the user allowed it. AP2 covers the proof. ACP’s delegated payment token and the card networks’ agent tokens cover the credential.

Settlement. Money moves. x402 and MPP fold this into the HTTP exchange. For card payments in ACP and UCP, it stays with the merchant’s payment provider.

Each Protocol, Briefly

AP2. The AP2 site defines two mandate types, each with an open and a closed stage: a Checkout Mandate shared with the merchant, and a Payment Mandate shared with the credential provider, networks and the merchant’s payment processor. An open Payment Mandate “Captures the user’s constraints on payment (e.g., budget, allowed instruments) for autonomous execution.” Mandates are verifiable digital credentials. Google donated AP2 to the FIDO Alliance in April 2026, and the site says standardization will continue in FIDO working groups. Google’s September 2025 announcement described “Intent” and “Cart” mandates; the current site uses Checkout and Payment.

ACP. A checkout session API plus a Delegate Payment spec whose Allowance binds a token to one checkout session and one merchant, with a max_amount and an expires_at. In Stripe’s flow the token is a Shared Payment Token. The 2026-04-17 release added cart, feed and order APIs and a discovery document. Full detail: Agentic Commerce Protocol (ACP).

UCP. Capabilities for catalog, cart, checkout, identity linking and order, plus a draft lodging booking capability. Checkout moves through incomplete, requires_escalation, ready_for_complete, complete_in_progress, completed and canceled. Payment comes through handlers; the spec includes an autonomous-agent scenario using AP2 mandates. Full detail: Universal Commerce Protocol (UCP).

x402. The server answers 402 with a price; the client retries with a signed payment, typically a stablecoin transfer; the server verifies and settles it onchain, usually through a facilitator. No account or API key. Full detail: x402.

MPP. Per the MPP protocol overview, the server returns “402 Payment Required with WWW-Authenticate: Payment header,” the client retries “with Authorization: Payment,” and the server delivers “200 OK with Payment-Receipt header.” It defines payment intents including charge, session and subscription, and it is payment-method agnostic: the docs list stablecoins on Tempo, cards through Stripe, Lightning and others. The docs point to an IETF specification for the normative core protocol.

The card networks run their own agent programs alongside these: Visa Intelligent Commerce together with Visa’s Trusted Agent Protocol, and Mastercard Agent Pay, with Verifiable Intent. Visa’s Intelligent Commerce Connect accepts payments initiated via “Trusted Agent Protocol, Machine Payments Protocol (MPP), Agentic Commerce Protocol (ACP), and Universal Commerce Protocol (UCP).” These protocols are being built to coexist.

What State Each Protocol Assumes You Hold

Every protocol here moves a request correctly. Each also assumes some decision was made correctly before the request was sent, using state the protocol doesn’t carry.

One AP2 detail shows the pattern. The specification says “Shopping Agents MUST NOT present any subsequent open Payment or Checkout Mandates without receiving a rejection receipt from the previous one,” to “prevent an Agent approving multiple different Checkouts using the same open Mandate.” That rule is about one agent and one mandate. A platform running twenty agents against one household or one company budget has to track the total itself.

Call it authorization-time context: everything the decision to sign, submit or confirm has to read, at the moment it runs. On the merchant side it is stock net of open holds. On the agent side it is remaining budget net of purchases in flight, per-agent limits and policy. Pick any protocol and this state is still yours.

A Worked Example Across Protocols

The numbers below are illustrative, built to show the mechanism.

A company’s procurement agents share a monthly software and data budget of USD 5,000.00. They buy SaaS seats through ACP checkouts, pay for API calls with x402, and use MPP sessions for a metered data feed. Each protocol path logs receipts to its own table, and a reporting job sums the three every hour into the total the agents check.

On the 28th, the last run shows USD 2,900.00 (ACP), USD 1,100.00 (x402) and USD 800.00 (MPP): USD 4,800.00 spent, USD 200.00 left. Within ten minutes the agents buy a USD 140.00 seat upgrade, make USD 90.00 of API calls and open a USD 150.00 MPP session. Each purchase fits the USD 200.00 the agent read. Every protocol completes correctly. The budget ends at USD 5,180.00.

The fix isn’t a better protocol. It’s one ledger that all three paths reserve against before they pay, in one transaction:

UPDATE budgets
SET    reserved = reserved + :amount
WHERE  budget_id = :budget_id
  AND  spent + reserved + :amount <= cap
RETURNING budget_id;     -- zero rows: do not pay, on any rail

Under READ COMMITTED, concurrent updates to the same row re-check the WHERE clause after waiting, so reservations from different rails cannot jointly pass the cap. For the general shape, see race conditions between AI agents.

Which Protocols Should You Implement?

If you sell goods and want to be bought by agents: ACP and UCP are the checkout protocols. Both are open; supporting both is a matter of exposing your checkout twice. Your stock and holds are the shared state underneath.

If you sell an API or data by the request: x402 and MPP. Both use HTTP 402. MPP’s site announced in June 2026 that its SDK supports “x402 exact flows,” so the two are not exclusive.

If you run agents that buy: you’ll meet all of them. Your agents need one budget and limit ledger across rails, and an AP2 or Verifiable Intent mandate is a constraint you check yourself as well as one the verifier checks.

Where Tacnode Fits

The protocols carry the request. The Tacnode Context Lake™ holds the decision context on either side of it: what the merchant reads before it says “ready,” what an agent reads before it pays, and what each one decided.

Budgets, reservations, per-agent limits, holds and purchase intents are state the merchant or the agent platform owns. Held in Tacnode, they are covered by full ACID transactions across every rail at once: reservations from ACP, x402 and MPP paths cannot jointly pass one cap, because each is a committed write against the same row. Stock and order data from the systems you already run arrive by change data capture, and derived reads such as spend per agent today or holds per SKU are computed on demand against the latest committed data. Each result is written back and becomes context for the next decision. Authorization, settlement and disputes run where they run today; Tacnode enforces nothing inside a card network’s, issuer’s, chain’s or merchant’s ledger.

That closes the context gap the protocols leave open by design: the decision behind each request reads accurate, shared state.

FAQ