Guide

x402 vs MPP vs ACP vs AP2 vs UCP: What Each Agent Commerce Protocol Actually Does

5 min readReviewed
  • x402
  • MPP
  • ACP
  • AP2
  • UCP
  • Payments

x402, MPP, ACP, AP2 and UCP are often presented as rival labels. That comparison is misleading because the protocols do not all own the same part of a purchase. Some describe how money moves, some structure the conversation with a merchant, and one focuses on evidence that an agent was allowed to act.

The useful question is not “which acronym wins?” It is “which layer of this transaction needs a standard?”

Protocols by responsibility
Discovery & interactionMCP · ACP · UCPHow an agent finds and requests a capability
Authorization & paymentAP2 · x402 · MPPWho may buy and how value moves
Merchant transactionState · replay · execution · receiptWhat the business must still make reliable
These standards can coexist because they answer different questions in the same transaction.

x402 and MPP move payment closer to the request

x402

x402 turns HTTP 402 Payment Required into a practical machine payment flow. A resource can return payment terms; the client obtains or authorizes payment and submits proof with the request. It fits naturally around paid HTTP resources, including API calls an agent discovers at runtime.

MPP

Machine Payments Protocol is also aimed at programmatic buyers and sellers. Its protocol model and payment ecosystem differ from x402, and it can represent payment for resources such as HTTP endpoints or MCP tools. A merchant may support either rail or both without changing the underlying business capability.

Neither rail defines the merchant’s complete transaction. Pricing policy, authorization, replay protection, execution and delivery still need an owner.

ACP and UCP structure the commerce conversation

ACP

Agentic Commerce Protocol describes an agent-to-merchant interaction around discovery, checkout and related commerce state. Its scope is broader than a payment challenge. The specification is evolving, so an implementation should name the revision and profile it supports rather than rely on a generic badge.

UCP

Universal Commerce Protocol addresses a broad merchant journey that can include discovery, checkout, orders and payment handlers. UCP can advertise how a merchant wants to be paid, while leaving the actual payment mechanism separable from the commerce workflow.

ACP and UCP overlap in territory, but they are separate specifications with different data models and ecosystem owners. Treat them as adapters into merchant capabilities, not as reasons to rebuild the capabilities.

AP2 carries authorization evidence

Agent Payments Protocol focuses on the question behind an autonomous purchase: what evidence shows that the user authorized this agent to make this payment under these terms? Its mandate model can cover a human-present approval or a delegated policy for autonomous action.

AP2 is payment-instrument agnostic. It can sit above different payment methods rather than becoming the rail itself. In an architecture, that makes it an authorization profile beside the payment path.

MCP is a channel, not a commerce system

Model Context Protocol gives AI applications a standard way to discover and invoke tools and resources. It can expose a paid capability, but it does not make that capability commercially complete. A merchant still needs terms, payment, replay handling, execution state and a receipt.

One capability can use several standards

An MCP tool may expose the operation, AP2 may carry authorization, and x402 may handle payment. The merchant backend can remain the same through all three.

Choose by layer and buyer

Start with the buyer ecosystem and the job it needs to complete. If an agent needs a paid HTTP resource, a machine payment rail may be enough. If the task includes product selection, checkout and order state, a commerce protocol matters. If autonomous authority is the hard problem, the authorization evidence matters.

Then pin an exact revision, document what must be persisted and decide what a retry means after payment. Protocol compatibility is only useful when the merchant can explain the resulting transaction from discovery through delivery.

Keep the merchant core stable

The multi-protocol ecosystem is already real, but it does not require a multi-backend architecture. Put protocol-specific mapping at the edge, normalize the request into one commerce core and call a stable business interface behind it. New standards can then arrive as adapters instead of new execution paths.

Frequently asked questions

Is x402 a competitor to ACP?

They can overlap in a commerce system but their core roles differ. x402 centers payment for HTTP resources. ACP defines a broader agent-to-merchant commerce interaction.

Is AP2 a payment rail?

AP2 is focused on authorization and evidence through mandates. It is designed to work with payment instruments instead of replacing all of them.

Are ACP and UCP the same thing?

No. Both address agentic commerce but they are separate specifications with different data models and ecosystem owners.

Can one merchant support x402 and MPP?

Yes. The merchant can expose more than one payment rail. The transaction system should know which rail the buyer selected and should avoid silent fallback after an uncertain payment result.

Does MCP replace ACP or UCP?

No. MCP exposes tools and data to AI applications. ACP and UCP are commerce-focused protocols. They can meet at the same merchant capability.

Sources and further reading

All guides