Agent Commerce Signals: x402, ACP, UCP, AP2 and MPP
Agent commerce signals are protocols and metadata patterns that help AI agents discover products, authenticate, pay, and complete transactions safely.
Agent Commerce Signals
Agent commerce signals are protocols and metadata patterns that help AI agents discover products, authenticate users, pay, and complete transactions safely.
This space is moving quickly. Treat individual acronyms as evolving protocol signals, not as universal requirements for every product website.
Key Terms
- x402: a payment protocol that uses HTTP
402 Payment Requiredsemantics for machine-to-machine payments. - ACP: Agentic Commerce Protocol, an open specification for programmatic checkout between buyers, AI agents, and sellers.
- UCP: Universal Commerce Protocol, a broader commerce lifecycle and capability-negotiation specification covering catalog, cart, identity, checkout, and orders.
- AP2: Agent Payments Protocol, a Google-led protocol for agentic payments and user authorization.
- MPP: Machine Payments Protocol, designed by Tempo and Stripe for machine-to-machine payments across APIs, tools, and HTTP-addressable resources.
What Product Websites Should Do First
Before adopting any payment protocol, make the basics clean:
- Product pages are crawlable
- Product structured data is valid
- Pricing, availability, shipping, and return policy are visible
- Public APIs are documented
- Authentication and consent boundaries are explicit
- Checkout policies are clear to humans and agents
Match the Protocol to the Transaction
Do not implement every fashionable acronym. Start with the real task and the asset that makes it possible:
| Task | Foundation to verify | Protocol direction to evaluate |
|---|---|---|
| Discover products | Stable product URLs, price, inventory, returns, Product structured data | Catalog and product-discovery capabilities |
| Pay for an API call | OpenAPI, authentication, rate limits, billing unit, error responses | Machine-payment flows such as x402 or MPP |
| Let an agent build a cart | Cart state, checkout, order status, consent and revocation | ACP or UCP commerce-lifecycle capabilities |
| Authorize a payment | User intent, amount, currency, payee, expiry, receipt | Payment-authorization models such as AP2 |
Discovery, checkout, and payment are separate authority levels. Finding a product does not authorize an agent to buy it; permission to initiate payment does not automatically include permission to change an address, save credentials, or request a refund.
Security and Compliance Controls
An agent commerce implementation should preserve at least these controls:
- Least privilege: separate browse, cart, order, and payment permissions.
- Bound consent: store the approved product, quantity, currency, total, payee, and expiry so execution cannot silently drift from the user’s decision.
- Idempotency and replay protection: prevent retries from creating duplicate orders or charges.
- Auditability: record the caller, protocol version, authorization evidence, request summary, response, error, and refund state.
- Human escalation: stop automation when the price, stock, address, risk level, or policy changes materially.
Payment, legal, security, and support owners should approve the boundary before launch. An SEO team can improve discovery and documentation, but it should not define financial authorization or fraud policy alone.
Pre-Launch Verification
- Link to the protocol version actually implemented, not only its marketing homepage.
- Keep real secrets, personal data, and reusable payment credentials out of examples.
- Require renewed confirmation after a price or inventory change.
- Distinguish authentication failure, insufficient funds, price change, unavailable inventory, and temporary service failure in API responses.
- Give people a visible way to inspect, cancel, refund, and obtain the same policy information available to the agent.