AP2 vs x402 vs ACP: three protocols, one transaction.

TL;DR

Authorization, payment, and credential — three different problems, three protocols.

• • AP2 (Google + Coinbase): WHO is allowed to spend, and HOW MUCH. Cryptographic mandate chain. Rail-agnostic.
• • x402 (Coinbase): HOW the API server tells the agent the price (HTTP 402 + inline payment). USDC-on-Base-native, can wrap others.
• • ACP (Stripe): WHAT credential the agent presents at the merchant. Cart-bound Shared Payment Token.
• • They compose. A typical agent-to-merchant transaction uses all three: AP2 authorizes, ACP credentialed, x402 handles per-call API legs.
• • All three are in production at AgentWallet today.

The three protocols, in one paragraph each.

AP2 — Agent Payments Protocol. Authored by Google Cloud + Coinbase, published September 2025. Defines a cryptographic authorization envelope: IntentMandate (payer signs intent), CartMandate (merchant signs the cart), PaymentMandate (payer signs the payment). The chain proves a specific human authorized a specific agent to spend a specific amount at a specific merchant. Money moves on whatever rail you want; AP2 just produces the signed authorization trail.

x402 — HTTP Payment Required. Authored by Coinbase, published 2025. Defines a way for any HTTP server to demand inline payment: respond with HTTP 402 + a price quote; client pays inline (USDC on Base by default) and retries with payment proof; server returns the resource. Designed for true micropayments where a subscription would be overkill. Solves the "how does the agent pay $0.002 for one API call without a Stripe relationship" problem.

ACP — Agentic Commerce Protocol. Authored by Stripe, published Q1 2026. Defines a merchant-discovery and payment-credential format for agent-to-merchant commerce. The agent discovers an ACP-capable merchant via a well-known URL, generates a Shared Payment Token (Stripe SPT) bound to one cart + one merchant + one cap, and presents the SPT at checkout. The merchant charges the SPT; settlement happens on whatever underlying rail the SPT wraps.

AP2: authorization.

AP2 produces three nested JWS objects. The IntentMandate says "agent X may spend up to $Y on category Z, before time T." It's signed by the payer's DID — typically a did:web bound to a WebAuthn key the human controls. The CartMandate is signed by the merchant's DID and describes the actual cart: line items, total, currency, payment options. The PaymentMandate is signed by the payer's DID again, references the cart, and authorizes the specific payment for the specific cart.

The trust property: any verifier with internet access can fetch the two DIDs' JWKS (via /.well-known/did.json) and independently verify the full chain without trusting anyone. The mandate chain is the audit trail; the rail underneath is independent. Card refusal, ACH return, USDC failure — all are settlement-layer concerns. AP2 is the authorization layer.

We covered AP2 implementation in detail in our deep-dive — the 400-line verifier, the eight spec gaps, the did:web SSRF hardening, the role confusion between Intent/Cart/Payment signers.

x402: inline payment.

x402 reuses HTTP 402 (Payment Required) — a status code reserved since RFC 2616 in 1999 but never standardized. An API server responds with 402 + a payment quote (recipient address, amount, currency, expiry). The client pays — most commonly USDC on Base via an EIP-3009 signed transfer — and retries the request with payment proof in the X-Payment header. The server verifies the proof on-chain and returns the resource.

The big idea: turn payment into a transport-layer concern, like TLS. No accounts, no API keys, no subscription contracts. The agent walks up to an API, gets quoted, pays, gets the data. Total round-trip: 200–500ms on USDC on Base. For per-call use cases (geocoding, one-shot LLM judging, ephemeral data lookups), this is the difference between "build an account management layer" and "make the call."

x402 composes with AP2: the agent's wallet can be configured to only honor x402 quotes that match an active IntentMandate (e.g., "per-call payments only up to $5, only for the duration of this task"). AgentWallet ships this composition as policy-cascade rules.

ACP: merchant credential.

ACP solves the "how does the agent pay at this specific merchant" problem. The agent discovers an ACP-capable merchant (via a well-known URL on the merchant's domain: https://merchant.com/.well-known/agentic-commerce). The discovery response advertises the merchant's accepted token formats. The agent generates a Stripe SPT — a cart-bound, merchant-bound, cap-bound token — and presents it at checkout. The merchant charges it via Stripe; settlement happens on the underlying card.

The wins vs raw card-on-file: tokens are single-use and cart-bound (can't be replayed against a different cart), the merchant's discovery surface is well-known (no bespoke per-merchant integration), and the credential is short-lived (typically 15 minutes), so leaked tokens have small blast radius.

AgentWallet ships ACP buyer-side in production: agent discovers ACP merchants, issues SPTs against VGS-aliased PAN through the Stripe Forward proxy, persists the merchant's discovery cache with TTL invalidation. ACP live-mode requires VGS forward-proxy enabled; test mode short-circuits without it.

How they compose in one transaction.

Realistic agent transaction: "find me a flight from SFO to NRT under $1,200, book it."

1. Setup (AP2): Human signs an IntentMandate: "agent may spend up to $1,200 on flights, before tonight." Mandate is bound to the agent's DID and a cap.
2. Search (x402): Agent calls a flight-search API. API responds 402 with a 0.01 USDC quote. Agent's wallet auto-pays (within IntentMandate scope); retries; gets the flight list.
3. Discovery (ACP): Agent picks the best flight on United.com. Agent fetches https://united.com/.well-known/agentic-commerce. United is ACP-capable. Agent generates an SPT bound to the cart ($1,150) and the merchant.
4. Checkout (ACP + AP2): Agent submits the cart with the SPT and a signed CartMandate (United signs CartMandate; agent signs PaymentMandate). United charges the SPT via Stripe; settlement happens on a VGS-aliased PAN under the AgentWallet umbrella. Receipt comes back with the cart hash for audit.
5. Audit: AgentWallet's ledger row contains the AP2 mandate chain hash, the ACP SPT id, the Stripe charge id, the trace id. End-to-end verifiable. Total tx time: under 8 seconds for the user-facing latency.

No single protocol does this. The three together do.

Decision matrix.

Which to implement when.

If your agent pays at known merchants with cards: ACP is the must-have. AP2 adds the audit posture. x402 is optional unless your agent also calls per-call APIs.

If your agent calls a lot of per-call APIs: x402 is the must-have. AP2 underneath gives you spend caps the agent can't bypass. ACP is moot if you're not paying merchants.

If your agent transacts at any dollar amount where audit matters: AP2 is the must-have, regardless of rail. Without AP2 your audit trail is "we trust our database;" with AP2 it's "any third party can verify the chain."

Most production agents: need all three. Especially if they cross between card flows (vendor payments), API calls (per-call services), and audit-sensitive amounts (> $1k).

Production status (May 2026).

AP2: v0.1 published. Production at AgentWallet. Pilots at Stripe (limited), Google internal demos. Crossmint, Cobo, Ramp, Circle, Coinbase AgentKit: not yet implemented as of writing.

x402: Coinbase production (cdp.coinbase.com supports it). AgentWallet buyer-side in production. Several open-source clients exist. Server-side adoption growing — most adopters are AI/ML inference APIs and crypto-native data providers.

ACP: Stripe production. AgentWallet buyer-side in production. Stripe-adjacent merchants are the early adopters. Discovery surface (well-known URL) growing month-over-month; we're seeing 5–10 new ACP-capable merchants per week as of May 2026.

If you want the most agent-payments-protocol coverage available today, AgentWallet is the only platform implementing all three in production. See /protocols for the side-by-side.