Agent Payment Protocols Architecture: AP2, x402, and ACP Compared (2026)

How to diagram agent payment protocol architectures. Compares AP2 (authorization/trust layer), x402 (HTTP-native stablecoin settlement), and ACP, and shows how they combine in production autonomous-purchasing systems — with prompt templates.

Ryan·Senior AI Engineer

·Last updated July 8, 2026

As AI agents move from answering questions to taking actions, a new protocol layer has emerged to let them spend money on a user's or business's behalf — safely, auditably, and with clear authorization boundaries. The three protocols defining this space in 2026 are AP2 (Agent Payments Protocol, from Google Cloud and Coinbase), x402 (Coinbase's HTTP-native stablecoin settlement scheme), and ACP (Agentic Commerce Protocol). Together they form the payment layer of the broader agentic protocol stack, sitting alongside MCP (tool calling) and A2A (agent-to-agent delegation).

Diagramming these systems correctly matters more than most architecture work — a misconfigured spend policy or missing audit trail has direct financial consequences. This guide breaks down what each protocol does, how they compose, and gives prompt templates for generating accurate agent payment architecture diagrams.

Why agent payments need a dedicated protocol layer

A conventional payment flow assumes a human is present to click "confirm purchase" — that click is the authorization. When an autonomous agent initiates a purchase, that human checkpoint is gone, so the authorization has to be encoded elsewhere: as a spend policy (how much, for what, until when), a cryptographic mandate the agent carries, and an audit trail that lets a business prove after the fact exactly what was authorized. AP2, x402, and ACP each solve a different piece of this problem.

AP2, x402, and ACP compared

Dimension	AP2	x402	ACP
What it standardizes	Authorization and trust: spend limits, mandates, audit trails	Settlement: HTTP-native stablecoin payment per request	Commerce checkout: agent-initiated purchase flow with merchants
Originated by	Google Cloud & Coinbase (2025)	Coinbase (2025)	Industry consortium, ongoing
Core mechanism	Signed mandates define what an agent may spend and on what	HTTP 402 response → signed payment token → on-chain receipt	Structured checkout API merchants implement for agent buyers
Settlement rail	Rail-agnostic (cards, bank rails, stablecoins)	Stablecoins (on-chain)	Existing payment processors via merchant integration
Typical use	Enterprise authorizing a procurement agent's spend cap	Agent paying per-API-call for data or compute	Shopping agent completing checkout on a retailer's site

Core components to diagram

AP2 mandate

An AP2 mandate is a signed, verifiable credential that encodes what an agent is authorized to spend: a maximum amount, a category or merchant allowlist, an expiration, and often a reference back to the human or business that granted it. The agent presents the mandate at time of purchase; anything that falls outside its scope should be rejected before settlement is attempted. In a diagram, show the mandate as a credential issued once (by the user or an enterprise policy engine) and referenced by every downstream purchase.

x402 payment flow

x402 reuses the long-dormant HTTP 402 "Payment Required" status code: a client requests a paid resource, the server responds 402 with accepted payment schemes and a price, the client constructs a signed stablecoin payment token and retries the request with an X-Payment header, a smart contract validates and settles the token, and the server verifies the on-chain receipt before serving the resource. This is designed for machine-to-machine micropayments — no account signup, no redirect flow, no human in the loop.

ACP checkout

ACP defines how a merchant exposes a structured checkout endpoint that an agent can call directly — cart contents, shipping, and payment method — instead of the agent driving a human-oriented web checkout UI. Merchants that implement ACP become directly "agent- purchasable," similar in spirit to how WebMCP makes a site's actions agent-callable more generally.

Spend policy engine and audit log

Production deployments add a policy engine that evaluates every purchase attempt against business rules (budget remaining, approved vendor list, dual-authorization thresholds) before a mandate is issued or a payment is released, plus an immutable audit log recording every attempted and completed transaction. These are the components security and finance reviewers will look for first — make sure your diagram shows where policy is enforced and where the audit trail is written.

Prompt templates for agent payment architecture diagrams

Enterprise procurement agent with AP2 spend policy

"An enterprise procurement agent is granted an AP2 mandate by a Spend Policy Engine: $5,000/month cap, restricted to an approved vendor allowlist, expires in 30 days. When the agent identifies a needed purchase (e.g., renewing a SaaS subscription), it checks the mandate's remaining budget and vendor allowlist before proceeding. If within scope, it presents the AP2 mandate to the vendor's payment endpoint. The vendor validates the mandate signature and settles via existing card rails. Every attempted and completed transaction is written to an immutable Audit Log in a compliance data store. If the agent attempts a purchase outside the mandate scope, the Spend Policy Engine blocks it and logs the rejection. Show the mandate issuance, the pre-purchase policy check, the vendor settlement call, and the audit log write as four distinct steps."

Autonomous agent paying per API call via x402

"A research agent needs data from a paid API. It sends a GET request to the API; the API responds HTTP 402 Payment Required with a price of $0.02 USDC and accepted payment schemes. The agent's wallet (holding a stablecoin balance pre-funded by the user, bounded by an AP2 mandate capping total spend at $10/day) constructs a signed payment token and retries the request with an X-Payment header. A smart contract validates the token and settles the stablecoin transfer on-chain, returning a receipt. The API verifies the receipt and returns the requested data. This repeats per call, with the AP2 mandate enforced client-side before each x402 payment is attempted. Show the 402 response, the token construction, on-chain settlement, and the AP2 spend check as a labeled sequence."

Shopping agent completing ACP checkout

"A consumer shopping agent, authorized by an AP2 mandate limited to $200 per purchase and a category allowlist of 'electronics accessories,' finds a matching product on a retailer that implements ACP. The agent calls the retailer's ACP checkout endpoint directly with cart contents and shipping address, presenting the AP2 mandate as proof of authorization. The retailer's checkout service validates the mandate, charges the user's stored payment method via its existing processor, and returns an order confirmation. The agent writes the completed order to the user's purchase history and notifies the user. Show the ACP checkout call as replacing a traditional multi-page checkout UI, with the AP2 mandate as the authorization artifact carried through the request."

What a good agent payment diagram must show

Mandate issuance and scope: Where the AP2 mandate is created, who grants it, and its spend limits — this is the primary authorization boundary
Policy enforcement point: The exact step where a purchase is checked against policy before money moves, not after
Settlement rail: Whether payment settles via existing processors (ACP), on-chain stablecoins (x402), or both
Audit trail: Every transaction — approved, rejected, or completed — written to an immutable log for post-hoc review
Human escalation path: What happens when a purchase exceeds mandate scope — reject, or escalate to a human for approval

Frequently asked questions about agent payment protocols

What is the difference between AP2 and x402?

AP2 is an authorization and trust layer — it defines what an agent is allowed to spend, on what, and provides an audit trail, independent of how the money actually moves. x402 is a settlement mechanism — it defines how an agent pays for an HTTP resource using stablecoins, reusing the HTTP 402 status code. In practice they're used together: AP2 governs the "may this agent spend $X here," and x402 governs the actual on-chain transfer.

Do I need blockchain infrastructure to use these protocols?

Only for x402, which settles via stablecoins on-chain. AP2 is rail-agnostic and can authorize spend that settles through conventional card or bank rails, and ACP checkout typically integrates with a merchant's existing payment processor. Most enterprise deployments today use AP2 for authorization with conventional settlement rails, adopting x402 selectively for machine-to-machine micropayments where per-request stablecoin settlement makes sense.

Where does this fit alongside MCP and A2A in the agentic stack?

MCP standardizes how an agent calls tools, A2A standardizes how agents delegate tasks to other agents, and the payment protocols standardize how an agent transacts money. A single production system might use all three: an orchestrator agent calls tools over MCP, delegates a purchasing subtask to a specialist agent over A2A, and that specialist completes the transaction using an AP2 mandate settled via ACP or x402.

Ready to try it yourself?

Start Creating - Free