Building Agentic Commerce #1: Multi-Protocol Checkout with 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 end up maintaining three integrations.

Trusteed 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, so 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, so it is 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 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.

Multi-merchant orders are where the bridge earns its keep. 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 and Merchant B can be routed to different rails in the same checkout — one to Stripe, another to the x402 adapter — because the split is per-merchant. Which of those rails can actually settle is a separate question, and the answer today is only the ones a merchant has a payment processor configured for: the x402 rail returns `x402_not_configured` for every merchant, so this shape is what the bridge supports, not something running in production. 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 MCP checkout flow right now against our demo store. The demo store at trusteed.xyz/demo-store has 18 products across multiple categories. Discovery tools (search_products, get_product_details, browse_categories, get_merchant_profile) work without authentication. Every checkout tool (create_cart, get_shipping_rates, select_shipping_option, apply_discount, preview_checkout, complete_checkout) needs a sandbox key, create_cart included, and the checkout tools that spend or settle need an X-Payment-Mandate header; the other checkout tools create_cart and attach_agent_identity and verify_age_over_n and verify_residence_country and verify_legal_person_authorization and apply_discount and get_shipping_rates and select_shipping_option and create_payment_mandate and update_payment_mandate and cancel_payment_mandate and ucp_create_checkout and ucp_update_checkout and ucp_add_items_to_checkout and ucp_get_checkout and ucp_cancel_checkout and get_checkout_state and quote_checkout and get_trust_receipt and verify_trust_receipt don't need it. The Playground at trusteed.xyz/demo-store/playground provides a built-in MCP client with all of that pre-configured.

Trust Score v4.1 combines three weighted dimensions with an optional external-assurance bonus and confidence-tier caps. Each response identifies the engine used; some responses fall back to legacy v2. A legacy v2 component breakdown does not explain an overall score produced by v4.1.