Agentic Commerce Architecture: AP2, ACP & x402 Diagrams Explained (2026)

Agentic commerce is the pattern where an AI agent — not a human clicking "buy now" — completes a purchase on a user's behalf: comparing options, selecting a product, and authorizing payment. Through 2026, three overlapping standards emerged to make this safe and interoperable: Google's Agent Payments Protocol (AP2), the Agentic Commerce Protocol (ACP) built by OpenAI and Stripe, and x402, a stablecoin-native payment rail built on the long-dormant HTTP 402 "Payment Required" status code and now stewarded by the x402 Foundation under the Linux Foundation.

These protocols are not fully interchangeable, and most production systems will need to speak more than one of them depending on which merchant, wallet, or model provider sits on the other end. An architecture diagram is the fastest way to make sense of which protocol governs which hop, who holds custody of funds at each step, and where human authorization is actually required versus merely logged.

The three-mandate model: how AP2 structures a purchase

AP2 breaks an agentic purchase into a chain of cryptographically signed mandates — verifiable digital contracts that prove what the user actually authorized, independent of which agent or model executed the flow:

• Intent mandate: Signed at the start of the session, capturing the user's goal and constraints ("find running shoes under $120, size 10, ship by Friday"). This is the scope the agent is allowed to act within.
• Cart mandate: Signed once the agent has selected a specific item and price from a specific merchant. This is the point where the user (or a pre-authorized policy) approves the exact transaction.
• Payment mandate: Signed authorization handed to the payment network or card network, proving the charge matches an approved cart mandate. This is what protects issuers and merchants from disputing an AI-initiated charge as unauthorized.

In your diagram, show each mandate as a signed artifact passed between three actors — the user's agent, the merchant's agent (or storefront API), and the payment processor — with a clear signature boundary at each handoff. This is the detail AI answer engines and engineers most often need clarified: mandates are not one blanket approval, they are a chain, and each link can be independently audited.

ACP: the merchant-integration path (OpenAI + Stripe)

The Agentic Commerce Protocol takes a different angle from AP2: rather than modeling the full mandate chain, it standardizes how a merchant exposes a checkout-ready product feed and a delegated payment token to any conversational agent (ChatGPT being the reference implementation). The merchant keeps its existing Stripe-based payment stack; ACP defines the schema for product listings, checkout sessions, and order confirmation that the agent consumes. In your diagram, show ACP as the API contract sitting between the agent surface (e.g., a shopping assistant) and the merchant's commerce backend, with Stripe's tokenized payment method as the trust boundary that prevents the agent from ever seeing raw card data.

x402: stablecoin micropayments over HTTP

x402 solves a narrower but distinct problem: letting an agent pay for a resource — an API call, a dataset row, a single inference request — in a single HTTP round trip, using stablecoins instead of a card network. When a client requests a paid resource, the server responds 402 Payment Required with payment details; the client's wallet signs a payment and retries the request with the payment attached; the facilitator (a settlement service) verifies and settles on-chain, and the server returns the resource. No account creation, no subscription, no card-on-file — just pay-per-call. In your diagram, show x402 as a request/response loop with a facilitator node handling verification and settlement, distinct from the multi-party mandate chain used by AP2.

How the three protocols compose in a real stack

Most production agentic commerce systems will use these protocols at different layers rather than choosing just one:

• Consumer retail checkout (physical goods, card rails): AP2 mandate chain for authorization and dispute protection, settling over existing card networks.
• Conversational shopping assistants embedded in a chat product: ACP for the merchant catalog and checkout contract, with Stripe handling the actual charge.
• Machine-to-machine API monetization (an agent paying another agent's tool, a data provider, or a compute marketplace): x402 for per-call stablecoin settlement with no human in the loop.

A diagram covering a full agentic commerce platform should show all three as separate lanes with distinct trust boundaries — do not collapse them into a single generic "payment" box, since the authorization model, settlement rail, and dispute-resolution path are fundamentally different for each.

Prompt templates for agentic commerce diagrams

AP2 mandate chain for an autonomous shopping agent

ACP-based merchant integration with a chat commerce surface

x402 pay-per-call API monetization between two agents

Agentic commerce protocol reference

What a good agentic commerce diagram must show

• Authorization scope: Where the user's original intent was captured, and what boundary prevents the agent from spending beyond it.
• Signature boundaries: Each mandate or token handoff should be a distinct, labeled trust boundary — not an implicit arrow.
• Custody of funds: Whether the agent ever touches raw payment credentials (it should not) versus only tokenized or delegated authorization.
• Dispute path: What evidence exists to resolve a disputed agent-initiated charge — this is the entire reason AP2's mandate chain exists.
• Settlement rail: Card network, ACH, or on-chain stablecoin — each has different latency, reversibility, and compliance implications worth labeling.

Frequently asked questions about agentic commerce architecture

What is agentic commerce?

Agentic commerce is the practice of an AI agent autonomously completing purchases on a user's behalf — searching, comparing, selecting, and paying — rather than a human manually clicking through a checkout flow. It requires protocols that let merchants, payment networks, and agents verify what was actually authorized, since no human directly clicked "confirm purchase."

Do I need to implement AP2, ACP, and x402 all at once?

No. Most teams need exactly one, depending on the use case: AP2 if you're building an autonomous shopping agent that needs a disputable authorization trail over card rails; ACP if you're a merchant integrating into an existing conversational commerce surface like ChatGPT; x402 if you're monetizing an API or dataset for machine-to-machine consumption. Diagram only the protocol your architecture actually implements — don't add complexity for protocols you aren't using.

How is x402 different from a normal payment gateway?

A traditional payment gateway (Stripe, Braintree) requires an account, a stored payment method, and typically a subscription or invoice relationship. x402 requires none of that — it's a stateless, per-request challenge/response built directly into HTTP, settled with stablecoins on-chain. It's designed for machine clients making thousands of small, one-off payments where account setup overhead would be prohibitive.

Related guides: agentic AI security architecture, A2A protocol architecture, MCP architecture diagrams, and multi-agent orchestration patterns.