x402 vs UCP vs ACP vs MPP: Agent Commerce Protocols Explained
x402, UCP, ACP and MPP are often grouped under “agent commerce,” but they do not solve the same problem.
Some coordinate a retail checkout. Some let software pay for an API request. One describes a broad commerce lifecycle; another focuses on machine-native payment. Treating them as interchangeable creates bad architecture—and publishing empty protocol metadata creates a false capability signal.
The first decision is not which acronym to implement. It is whether your website has a real transaction that an external agent should be allowed to complete.
The Short Comparison
| Protocol | Primary job | Best-fit transaction | Discovery or interface | Not a substitute for |
|---|---|---|---|---|
| x402 | Charge for an HTTP resource | Paid API, tool call, data or content request | HTTP 402 Payment Required plus payment headers | Product catalog or retail checkout |
| MPP | Coordinate machine-to-machine payment | API request, MCP tool call, recurring or per-use service | HTTP payment challenge and authorization | Product discovery or merchant operations |
| ACP | Run an agent-assisted seller checkout | Cart, fulfillment, tax, credentials and completion | Merchant checkout API and extensions | Search visibility or product-data quality |
| UCP | Connect the wider commerce lifecycle | Catalog, cart, identity, checkout and orders | /.well-known/ucp, capability negotiation, REST/MCP/A2A/embedded | A deployed commerce backend |
| AP2 | Prove user intent and payment authority | Human-present or autonomous authorized purchase | Signed mandates and verifiable credentials | Checkout, payment processing or catalog data |
AP2 is included because it is an adjacent authorization layer, even though the P3 comparison centers on x402, UCP, ACP and MPP.
x402: Pay For An HTTP Resource
The official x402 documentation defines an HTTP-native payment flow for APIs and content. A client requests a resource; the server replies with 402 Payment Required and payment instructions; the client authorizes payment and retries; the server verifies or settles the payment and returns the resource.
x402 is a practical fit when the sellable unit is already an HTTP request:
- One API call
- One data lookup
- One model or tool invocation
- One paid content response
- A metered machine-to-machine service
The current x402 documentation describes crypto-native payments and V2 headers such as PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE. That makes it different from a normal retail checkout with inventory, shipping choices, tax, returns and customer support.
Do not add a fake 402 response or payment document merely to look “agent ready.” A real implementation needs pricing, supported assets and networks, idempotency, settlement verification, receipts, refunds, rate limits and abuse controls.
MPP: Machine Payments Across HTTP Services
MPP is the Machine Payments Protocol designed by Tempo and Stripe. Its stated scope is machine-to-machine payment for API requests, tool calls or content in the HTTP interaction. Stripe’s MPP announcement also describes microtransactions and recurring payments, with Stripe implementations able to use existing PaymentIntents and several payment methods.
MPP and x402 overlap because both can gate an HTTP-addressable resource behind payment. Their wire formats, authentication models, payment-method support and infrastructure choices are not identical. Do not choose between them from a logo list.
Evaluate:
- Which protocol your buyers or agent platforms actually support
- Required payment methods and currencies
- Settlement, refund and dispute requirements
- Recurring versus single-request charging
- Existing payment-processor integration
- SDK maturity, observability and failure recovery
For a free editorial site with no paid API or callable tool, MPP has no immediate job.
ACP: A Programmatic Checkout For Agent Surfaces
The Agentic Commerce Protocol defines an exchange between buyers, AI agents and sellers to complete a purchase. Its checkout interface covers session state, cart changes, fulfillment options, payment processing and seller-authoritative totals.
ACP is relevant when a merchant wants an agent surface—such as ChatGPT—to conduct a deterministic checkout without browser automation. The seller still owns inventory, pricing, tax, fulfillment rules, order state and payment processing.
That means ACP readiness begins in the commerce backend, not in an SEO meta tag. Before integration, a merchant needs:
- Authoritative product identifiers and live availability
- Deterministic price and tax calculations
- Explicit fulfillment and return rules
- Authenticated, signed API traffic
- Idempotent checkout completion
- Webhooks, reconciliation and support workflows
ACP does not make weak product pages rank, and it does not replace Product structured data.
UCP: A Broader Commerce Capability Layer
The Universal Commerce Protocol describes building blocks from discovery and catalog lookup through cart, identity linking, checkout and order management. Its official specification defines a business profile at /.well-known/ucp, where a platform can discover versioned services and capabilities.
UCP supports multiple transport bindings, including REST, MCP, A2A and embedded flows. A business and platform negotiate the intersection of capabilities rather than assuming every integration behaves identically.
This makes UCP broader than a single payment method. A published profile is useful only when its endpoints, schemas, capability versions and business behavior are real. If /.well-known/ucp advertises checkout but the endpoint cannot calculate stock, totals, fulfillment or errors consistently, the metadata is misleading.
UCP is most relevant to merchants or platforms building interoperable agent-commerce journeys. A normal blog, brochure site or publisher without transactional APIs should not publish it.
AP2: Authorization Is A Separate Layer
The Agent Payments Protocol focuses on verifiable user intent, authorization and accountability. It uses signed mandates to bind a user’s constraints or approval to checkout and payment details, including human-present and human-not-present flows.
This distinction matters:
- Commerce protocols describe what is being bought and how the transaction progresses.
- Payment protocols coordinate how value is authorized and transferred.
- Authorization protocols prove what the user allowed the agent to do.
A production system may combine layers. For example, UCP can use AP2 for autonomous payment authorization; AP2 examples can use x402 as a payment rail. None of these combinations removes the need for fraud controls, legal review, consent, audit logs and human escalation.
Run A Fit Check Before You Implement
Score each condition 0 or 1:
| Condition | 0 | 1 |
|---|---|---|
| Real agent transaction | No external agent should transact | A supported agent use case exists |
| Authoritative backend | Data or totals require manual repair | APIs return reliable state and errors |
| Buyer/platform demand | No confirmed consumer | A named integration requires the protocol |
| Payment operations | Refunds, disputes or reconciliation are undefined | Owners and controls are documented |
| Security and consent | Authorization boundary is unclear | Scope, audit and escalation are tested |
| Maintenance capacity | No version or incident owner | Owners monitor specs and production behavior |
Interpret the score:
- 0–2: Do not implement. Fix ordinary site and commerce foundations.
- 3–4: Run a contained technical proof of concept with no public capability claim.
- 5–6: Select the protocol required by the real transaction and complete security review.
This is an implementation gate, not a maturity badge. A high score does not mean every protocol is needed.
Choose By The Transaction, Not The Trend
| Your actual product | First protocol to evaluate | Why |
|---|---|---|
| Editorial content site | None | Crawlability, useful content and internal links solve the current job |
| Store improving agent discovery | None initially | Product data, schema, feeds, policies and checkout reliability come first |
| Merchant integrating an agent checkout | ACP or UCP | The required agent platform and lifecycle determine the interface |
| Paid API or metered tool | x402 or MPP | The sellable unit is an HTTP request or tool call |
| Autonomous purchase with delegated authority | AP2 plus a commerce/payment layer | User intent and payment authority must be explicit |
Protocol support is not an SEO ranking signal. It can make a real service interoperable with compatible clients, but it does not guarantee discovery, traffic, citations or revenue.
The Foundation Checklist Comes First
Before agent commerce, validate:
- Public pages return the intended status, canonical and rendered content.
- Product names, identifiers, prices and availability agree across page, schema, feed and API.
- Shipping, returns, subscriptions and cancellation policies are explicit.
- API documentation and schemas match production behavior.
- Authentication, authorization and consent have clear owners.
- Checkout actions are idempotent and observable.
- Failures can escalate safely to a human.
Use the Agent SEO audit to check the public surface, then validate rendering with the Bot Simulator and ordinary technical SEO checks. If the product exposes APIs, start with the API Catalog guide and OAuth metadata workflow. Add an A2A Agent Card only when a real A2A service exists.
Takeaway
x402, UCP, ACP and MPP are not four versions of the same “AI commerce tag.”
- x402 and MPP focus on machine payment for HTTP-addressable resources.
- ACP focuses on agent-assisted seller checkout.
- UCP spans broader commerce discovery, capability negotiation and lifecycle operations.
- AP2 adds verifiable intent and payment authorization.
Implement only the layer required by a real transaction and supported buyer. For most content websites—and many stores—the highest-value next step is still accurate product data, reliable APIs, secure authorization and a checkout that works before an agent arrives.
Sources
- x402 official documentation
- Universal Commerce Protocol
- UCP official specification
- Agentic Commerce Protocol documentation
- Machine Payments Protocol
- Stripe: Introducing MPP
- Agent Payments Protocol
Q&A
Does every ecommerce or content website need x402, UCP, ACP or MPP?
No. Content-only sites do not need an agent payment protocol. Most stores should first make product data, price, availability, policies, authentication and checkout behavior reliable before evaluating protocol-specific integrations.
What is the main difference between UCP and ACP?
Both support agent-assisted commerce, but UCP describes a broader commerce lifecycle and capability-discovery model, while ACP focuses on a programmatic checkout exchange between buyers, agents and sellers. Implement against the platform and specification your business actually supports.
Are x402 and MPP SEO ranking signals?
No. They are machine-payment protocols for paid resources, APIs, tools or content. Publishing or supporting them does not guarantee crawling, indexing, rankings, AI citations or agent adoption.
