Skip to content
Guideintermediate

x402 vs ACP vs AP2: Which Agent Payment Protocol Should You Build On in 2026?

The short version

x402 meters API calls in stablecoin, ACP runs agent checkout at a merchant, AP2 proves a human said yes. A decision-first comparison with the October 2026 status of all three, the code each one needs, and which to pick for your build.

Published October 7, 2026by Pondero Labs
Table of Contents

x402 vs ACP vs AP2: Which Agent Payment Protocol Should You Build On in 2026?

Build on x402 if software is paying you per call, don't hand-roll a checkout spec if humans are buying products through an agent (let Stripe or Shopify carry it), and add AP2 underneath either one when you have to prove a person actually authorized the spend. Those three protocols get compared as rivals, but they answer different questions. x402 moves money inside an HTTP request. ACP (the Agentic Commerce Protocol from OpenAI and Stripe) structures a checkout between an agent and a merchant. AP2 (Google's Agent Payments Protocol) moves no money at all; it produces signed evidence of what the user agreed to. Pick by the job, and most teams end up needing one of them, occasionally two.

One naming trap before anything else. If you found us through our MCP vs A2A guide, you met a different "ACP" there: IBM Research's Agent Communication Protocol, an agent-to-agent messaging spec that folded into A2A in August 2025. Same three letters, unrelated project. Every "ACP" below means the Agentic Commerce Protocol, the checkout standard. And if you want the x402 request flow walked through header by header, our July x402 explainer covers it; this piece stays at the decision level and catches up on what changed since.

Three protocols, three different jobs

x402 revives HTTP's long-dormant 402 status code. Per the x402 Foundation's spec README, a resource server answers an unpaid request with 402 Payment Required and a Base64 PAYMENT-REQUIRED header, the client signs a payment payload and retries with a PAYMENT-SIGNATURE header, and the server (usually through a facilitator's /verify and /settle endpoints) settles on-chain before returning 200 with a PAYMENT-RESPONSE receipt. The buyer needs a funded wallet and nothing else, so it can be a script nobody ever underwrote or signed a contract with.

ACP is a merchant-facing REST contract. The ACP repo defines checkout_sessions endpoints (create, update, complete, cancel) that an agent surface calls on the merchant's backend, plus a delegate-payment spec. Payment rides on Stripe's Shared Payment Token, which, per Stripe's launch announcement, lets the agent initiate a charge without ever seeing the buyer's card, scoped to one merchant and one basket total. The merchant stays merchant of record and keeps tax, fulfillment, and returns.

AP2 is an authorization layer. Google's AP2 announcement describes "Mandates," cryptographically signed records of what the user instructed, usable as an extension of A2A and MCP, and payment-method agnostic (cards, stablecoins, real-time bank transfers). The current spec in the AP2 repo splits these into closed mandates the user signs on a finished cart (mandate.checkout.1) and open mandates that pre-authorize future purchases inside constraints (mandate.checkout.open.1, mandate.payment.open.1), all carried as SD-JWT verifiable credentials.

Because they sit at different layers, one purchase can touch all of them. Coincub's layering has a checkout spec handling the session, AP2 carrying the user's signed consent, and x402 or a card network doing settlement. Stripe's own agentic commerce docs already split it the same way when we read them on October 7: UCP or ACP for selling through agents, and MPP or x402 for accepting machine payments.

Side by side, as of October 7, 2026

x402ACP (Agentic Commerce Protocol)AP2 (Agent Payments Protocol)
What it solvesPaying for a single HTTP request, machine to machineAgent-driven checkout at a human-facing merchantProving a human authorized a specific purchase or spending envelope
Moves money?Yes, typically USDC on-chain via a facilitatorYes, via a Shared Payment Token on the merchant's processorNo, it produces evidence that rides alongside a payment
Built byCoinbase, launched May 2025 (CoinDesk)OpenAI and Stripe, launched September 29, 2025 (Stripe)Google, launched September 16, 2025 with 60+ organizations (Google Cloud)
Governance nowx402 Foundation at the Linux Foundation since July 14, 2026, 40 members (Linux Foundation)Beta, founding-maintainer control by OpenAI and Stripe, foundation listed as a future path (ACP repo)Donated to the FIDO Alliance with v0.2 on April 28, 2026 (Google)
Main documented caveatEarly volume inflated by self-dealing and wash trading (CoinDesk)Flagship ChatGPT Instant Checkout wound down in March 2026 (Coincub)Spec leaves key issuance and binding liability unsolved (Coincub)
Use it whenSoftware pays you per call for an API, tool, or datasetYou sell physical or digital goods into agent surfaces like ChatGPTAn auditor, issuer, or network needs proof of user intent
Sourcex402 specACP specAP2 spec

What changed since our July x402 guide

Four things moved: two governance handoffs, one retreat, and a new competitor.

The x402 Foundation went operational on July 14, 2026. Per the Linux Foundation release, 40 organizations joined after the April intent-to-launch, and the premier tier reads like a payments conference keynote: Adyen, AWS, American Express, Circle, Cloudflare, Coinbase, Fiserv, Google, Mastercard, Shopify, Stripe, Visa, and several chain foundations. Coinbase's contribution of the protocol is complete. For a builder, that means x402 no longer depends on one company's roadmap.

AP2 went to the FIDO Alliance on April 28, 2026. Google's post pairs the donation with AP2 v0.2, which adds "Human Not Present" payments (the agent buys the concert tickets the second they drop, under rules you signed earlier), and with Verifiable Intent, a companion standard co-developed with Mastercard that also moved to FIDO. The repo's v0.2.0 release is stamped the same day.

ACP lost its showcase. Instant Checkout in ChatGPT launched alongside ACP on September 29, 2025, starting with US Etsy sellers. Coincub's timeline dates the retreat to March 4, 2026, and notes that roughly a dozen Shopify merchants had gone live; Storyboard18, summarizing TechCrunch, reported OpenAI deprioritizing standalone checkout in favor of product discovery and merchant-hosted checkout. The spec itself kept shipping. Its dated releases run from 2025-09-29 through 2026-04-17, and that last one added cart, product feed, orders, authentication, and MCP support, which moves ACP up the funnel toward discovery.

A fourth spec took the merchants. Google and Shopify published the Universal Commerce Protocol in January 2026, and Coincub lists Etsy, Target, Walmart, and Wayfair behind it. UCP handles discovery and checkout negotiation, and AP2's current checkout-mandate doc says that when AP2 runs alongside UCP, the merchant-signed checkout object must be UCP's Checkout object. Google is wiring its own specs together.

The x402 volume number, with the discount applied

You'll see one figure quoted everywhere: x402 settled about $24 million across roughly 75 million transactions in the 30 days to mid-July 2026, an average near 32 cents, per CoinDesk's July 15 report. Discount it before you quote it: on-chain analysts at Artemis had earlier found roughly half of observed x402 transactions were artificial, split between self-dealing and wash trading, so do not read the headline as clean commercial demand.

Chainalysis adds the other half of the story. Its x402 adoption analysis attributes much of the surge past 100 million cumulative transactions on Base to PING, a pay-to-mint meme coin where users hit a URL, got a 402, and paid 1 USDC to mint, over and over. The same report shows the mix maturing: transactions of $1 or more went from 49% of volume in early 2025 to 95% by early 2026, per Chainalysis.

What the number does show is a rail handling volume at price points card networks cannot serve profitably. CoinDesk puts the month in context against Visa's $14.2 trillion in fiscal 2025, about $40 billion a day. x402 works; the agent economy it was built for is still small.

What each one looks like in code

The shape of the integration tells you a lot about who each protocol is for.

x402 on the seller side is middleware. From the @x402/express README, install and wrap a route:

pnpm install @x402/core @x402/express @x402/evm
import express from "express";
import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

const facilitator = new HTTPFacilitatorClient({ url: "https://x402.org/facilitator" });
const server = new x402ResourceServer(facilitator)
  .register("eip155:84532", new ExactEvmScheme()); // Base Sepolia testnet

const app = express();
app.use(
  paymentMiddleware(
    {
      "GET /v1/enrich": {
        accepts: [{ scheme: "exact", price: "$0.01", network: "eip155:84532", payTo: "<YOUR_WALLET_ADDRESS>" }],
        description: "One company-enrichment lookup",
      },
    },
    server,
  ),
);
app.get("/v1/enrich", (req, res) => res.json({ ok: true }));
app.listen(3000);

That is the whole seller integration for a testnet route. The README is explicit that the public x402.org facilitator is a testnet convenience, so pick a production facilitator (or self-facilitate) before mainnet.

ACP's center of gravity is the delegated-payment allowance. In the 2026-04-17 spec, the agent surface asks the payment provider to vault a card with an allowance attached, and the Allowance schema is what bounds the agent:

{
  "allowance": {
    "reason": "one_time",
    "max_amount": 2000,
    "currency": "usd",
    "checkout_session_id": "csn_01HV3P3XYZ789",
    "merchant_id": "acme",
    "expires_at": "2026-10-08T18:30:00Z"
  }
}

max_amount is in minor units (cents), and one_time is currently the only allowed reason. The token is good for that merchant and that session, up to the ceiling, until expires_at passes.

AP2 ships as a signed credential your agent carries. An open payment mandate for a human-not-present purchase lists constraints the agent must stay inside. The constraint types below come straight from the AP2 repo's open_payment_mandate.json schema:

{
  "vct": "mandate.payment.open.1",
  "constraints": [
    { "type": "payment.amount_range", "currency": "USD", "max": 15000 },
    { "type": "payment.allowed_payees", "allowed": ["<MERCHANT_OBJECT>"] },
    { "type": "payment.execution_date", "not_before": "<ISO_TIMESTAMP>", "not_after": "<ISO_TIMESTAMP>" }
  ],
  "cnf": { "jwk": "<AGENT_PUBLIC_KEY>" }
}

The user signs that once on a trusted device; the agent presents it, key-bound through cnf, when it finally checks out. Notice what's missing: any instruction to move money. AP2 needs a rail underneath it, which is exactly why Google shipped an A2A x402 extension alongside the launch.

Where each one bites

No chargebacks: x402 settlement is final, so a buggy agent that pays for 4,000 calls it didn't need has spent that money. Your spending policy (per-call cap, daily cap, payee allowlist) is the only brake, and it lives in your client code, not the protocol. The facilitator is also a trust point the docs make you choose deliberately.

The governance gap matters less for ACP than the commercial one. The spec is beta and still run by its two founding maintainers, but the agent surface it was built around stepped back from in-chat checkout, and per Coincub the original Instant Checkout never supported multi-item carts or promo codes. If you hand-integrate the spec today, you are tracking dated releases with no foundation behind them yet.

AP2 has the subtlest gap. Coincub's read of the spec points out that its liability table is labeled a guide rather than a binding contract, and that issuing trusted public keys (the root of the whole signature chain) is listed as unsolved, with near-term trust running on manually curated allowlists. A mandate proves a signature. Who vouches for the key, and who eats the loss when an agent buys the wrong thing inside a valid mandate, is still up to issuers and networks.

Which one to build on

On a real project this week, we'd route it like this.

  • If you run a paid API, tool, MCP server, or dataset and want agents to pay per call, use x402, starting now. It is the only one of the three built for an unknown buyer at sub-dollar prices, the governance risk is gone since the Linux Foundation move, and the upto scheme in the spec covers metered billing where the final charge isn't known until the call finishes.
  • If you sell products to consumers and want to be buyable from inside AI assistants, do not hand-roll ACP. If you're on Stripe or Shopify, let the platform do the protocol work (Stripe's agentic commerce docs list UCP or ACP for selling through agents, still in private preview as of October 7, and Shopify co-developed UCP); spend your own engineering on clean product feeds and accurate inventory, which pay off whichever checkout spec wins.
  • When your agent spends money while the user is away, or a compliance team, issuer, or card network has to see proof of consent, add AP2 mandates on top of whatever rail you use. Use the open payment mandate's amount range, payee, and date constraints as your spending policy, so the policy and the evidence are the same signed object.
  • Building the buying agent instead of the seller? Ship an x402 client for machine purchases now, and treat card purchases as AP2 plus your processor's agent tooling. Don't build a payment path that only works inside one assistant.

What you'd build this on

The agent, its wallet signer, and its spend logs still need a home. For workflow glue, an n8n instance can branch on a 402, call your policy check, and keep an audit trail of every payment decision. For a persistent host that holds signing keys properly, a managed cloud server beats a short-lived serverless function. And if the thing your agent is paying for is web data, Firecrawl turns pages into model-ready markdown on the fetching side.

The field is still splitting

UCP is already in Google's own AP2 docs, and ATXP's March 2026 roundup counts six agent-payment systems (its own included), among them Mastercard Agent Pay and Visa Intelligent Commerce. Expect another entrant before your integration ships. The choice that survives that churn is the one above: x402 for per-call API revenue today, platform-managed checkout for consumer goods, AP2 when consent has to be provable. Re-check the governance column of the table before you commit, because two of these three changed owners in the last six months.