x402 Protocol Architecture: How to Diagram AI Agent Stablecoin Payments (2026)

x402 architecture diagrams are showing up in a growing share of agentic-commerce design docs in 2026 as AI agents move from browsing the web to transacting on it. x402 revives the long-dormant HTTP 402 Payment Required status code as a machine-native payment handshake: an API or MCP server can respond “this costs $0.001, pay here” and an AI agent can pay instantly with stablecoins — no account creation, no API key provisioning, no credit card on file. Originally published by Coinbase and now stewarded by the x402 Foundation, the protocol has moved quickly from spec to production, with facilitator support from Cloudflare and managed agent-payment tooling from AWS Bedrock AgentCore. This guide covers the components and flow you need to diagram an x402 integration.

Why x402 exists

• Machine-native micropayments: Traditional API monetization (API keys, subscriptions, invoiced usage) assumes a human signs up in advance. x402 lets an agent discover a paid endpoint and pay for a single call on the spot, which makes per-request pricing viable for the first time.
• No account, no card: Payment happens via a crypto wallet the agent controls, settled in stablecoins (commonly USDC) on a low-fee chain like Base. There is no OAuth app registration or PCI scope to manage on the resource-server side.
• Near-zero fees at scale: Gas costs on Base are fractions of a cent, which is what makes sub-cent, per-call pricing for APIs and MCP tool calls economically sensible — something credit-card interchange fees make impossible.
• Chain-agnostic by design: The payment header describes a network, token, amount, and recipient rather than assuming one blockchain, so the same protocol can settle across different chains as facilitator support expands.

Core components of an x402 architecture diagram

• Client / agent: The AI agent (or an agent framework like a coding agent, browser agent, or Bedrock AgentCore-hosted agent) that wants a paid resource and controls a wallet capable of signing payments.
• Resource server: The API or MCP server gating a paid endpoint. On an unauthenticated request it returns HTTP 402 Payment Required with a JSON body describing accepted payment requirements (network, asset, amount, recipient address, scheme).
• Payment header: The agent constructs and signs a payment payload and resubmits the original request with an X-PAYMENT header attached — no separate checkout redirect or session required.
• Facilitator: A third-party service (Coinbase, Cloudflare, or a self-hosted facilitator) that verifies the payment payload is valid and settles it on-chain on the resource server's behalf, so the API provider doesn't need to run its own blockchain node or wallet infrastructure.
• Settlement network: The blockchain (commonly Base) and stablecoin (commonly USDC) that actually move value. Show this as the underlying settlement layer beneath the facilitator.
• Wallet + spend policy: The agent's wallet, plus any policy-based spending controls (per-call caps, daily budgets, allow-listed recipients) that bound how much an autonomous agent can spend without human sign-off.

The x402 request flow

1. Agent sends a normal HTTP request to a paid endpoint.
2. Resource server responds 402 Payment Required with accepted payment requirements (asset, amount, network, recipient).
3. Agent evaluates the price against its spend policy, signs a payment payload with its wallet, and resends the original request with the X-PAYMENT header set.
4. Resource server forwards the payment payload to a facilitator for verification and settlement.
5. Facilitator confirms the on-chain payment and returns a settlement confirmation to the resource server.
6. Resource server fulfills the original request and returns the paid resource.

Draw this as a single sequence diagram with the facilitator as a side call between steps 4 and 5 — it's easy to accidentally draw the facilitator as a payment gateway the agent talks to directly, when in most integrations it's the resource server that verifies with the facilitator.

x402 vs AP2 vs the Agentic Commerce Protocol

These aren't mutually exclusive — a shopping agent might use AP2 or ACP to complete a purchase from a merchant while using x402 to pay per-call for the pricing, inventory, or search APIs it queries along the way. Show them as separate protocol boxes on an agent-payments diagram rather than collapsing them into one “payments” node.

Prompt examples for x402 architecture diagrams

Paid MCP server with x402

Agent-to-agent API marketplace with x402 billing

x402 alongside AP2 in a shopping agent

What to annotate on an x402 diagram

• Price and asset: The amount and token (typically USDC) required per request, since this is what makes per-call pricing visible at a glance.
• Facilitator identity: Which facilitator verifies and settles payments — a managed provider or a self-hosted one — since it's a trust boundary the resource server depends on.
• Settlement network: The chain (Base, or others as facilitator support expands) so the diagram doesn't imply a single universal ledger.
• Spend policy boundary: Per-call caps, daily budgets, and allow-listed endpoints that bound autonomous spend — this is the control most reviewers will ask about first.
• Retry semantics: Whether the client automatically resubmits with the payment header on 402 or requires an explicit signing step, since that affects how “autonomous” the payment really is.

Related guides: AP2 protocol architecture, Agentic Commerce Protocol architecture, agent payment protocols, and the AI agent protocol stack.