Building Agentic Commerce #1: Multi-Protocol Checkout — MCP + x402 + ACP in One Flow

When an AI agent decides to buy a product, it doesn't care which payment protocol the merchant uses. It cares about: can I discover products, add them to a cart, and pay? The complexity of protocol routing, signature verification, and settlement should be invisible. This is the problem we solved with multi-protocol checkout — and in this post, we'll show you exactly how it works, with code you can run against our demo store today.

Today's agentic commerce ecosystem has multiple payment protocols, each optimized for different scenarios. MCP (Model Context Protocol) provides the tool interface — search, cart, checkout. x402 enables stablecoin payments on-chain (USDC on Base, Ethereum, Solana). ACP (Agentic Commerce Protocol) defines how agents discover merchant capabilities and negotiate payment methods. An agent shopping across merchants will encounter all three. If each requires a different integration, agent developers face a fragmentation nightmare.

AgenticMCPStores uses a Protocol Bridge that normalizes every incoming request to a unified AgentPaymentIntent, regardless of which protocol the agent speaks. The bridge detects the protocol from HTTP headers (X-Protocol: X402, X-Protocol: ACP) or request body shape, routes to the appropriate inbound adapter, and returns a protocol-specific response. Merchants configure which protocols they support — the agent never needs to know the details.

The protocol detector middleware runs on every checkout request and assigns a confidence score. X-Protocol header gets 1.0 confidence. Body shape detection (presence of 'cartId' for ACP, 'network' for x402) gets 0.9. If no protocol is detected, the request falls through to standard MCP checkout. This means existing MCP agents work without any changes — protocol awareness is additive, not breaking.

The simplest checkout flow uses MCP tools directly. An agent calls four tools in sequence: search_products to find items, create_cart to build a cart, preview_checkout to see totals and shipping, and complete_checkout to finalize the purchase. Every tool is idempotent — safe to retry on network failures.

x402 adds a payment layer for agents that hold cryptocurrency. Instead of a credit card token, the agent pays on-chain in USDC and submits proof of payment. The flow starts the same as MCP (search, cart, preview) but diverges at the payment step. When the agent sends X-Protocol: X402, the server responds with HTTP 402 Payment Required — a standard HTTP status code that was literally designed for this use case decades ago and is finally being used as intended.

Settlement is asynchronous: the server returns 202 immediately and processes the settlement in the background. Orders that aren't verified within 30 minutes auto-expire. The entire payment verification is BOLA-protected — agents can only settle orders they created.

ACP doesn't replace MCP or x402 — it sits above them as a discovery and negotiation layer. An agent fetches GET /.well-known/acp.json (public, no auth, cached 1 hour) and learns what the platform supports: which payment handlers are available (Stripe, x402, PayPal, UCP), which transports work (REST, MCP), and what capabilities the platform offers (cart persistence, agent session resume, display context negotiation).

The ACP discovery endpoint returns a JSON contract specifying: spec_version '2026-01-30', supported transports (REST and MCP), four payment handlers (Stripe for USD/EUR, x402 for USDC, PayPal for USD/EUR, UCP for USD/EUR), and capability negotiation options including webview and headless display contexts, cart persistence, and agent session resume. Authentication follows OAuth 2.1 with RFC 9728 protected resource metadata.

With this information, a smart agent can make protocol decisions automatically: use x402 if it holds USDC, fall back to Stripe if it has a card token, or use UCP if the merchant supports Shopify's Universal Commerce Protocol. The agent never needs to hard-code protocol logic — it reads the ACP contract and adapts.

The real power emerges with multi-merchant orders. When a cart contains items from different merchants, the Protocol Bridge splits the order into per-merchant intents and routes each independently via Promise.allSettled(). Merchant A might settle via Stripe while Merchant B settles via x402 — in the same checkout. One merchant's failure doesn't block others. Each gets its own ProcessedIntent with status, source/target protocol, and policy decision.

You can test the full MCP checkout flow right now against our demo store. The demo store at agenticmcpstores.com/demo-store has 18 products across multiple categories. Discovery tools (search_products, get_product_details, browse_categories) work without authentication. For checkout tools (create_cart, complete_checkout), use the Playground at agenticmcpstores.com/demo-store/playground which provides a built-in MCP client with pre-configured auth.

In Part 2, we'll cover how AI agents discover your store before they ever call an API — through NLWeb semantic search, llms.txt files, and the agent-card.json discovery protocol. In Part 3, we'll deep-dive into trust scores: the 8-component scoring system that determines how much autonomy an agent gets when shopping at your store.