Google AP2 + x402: what the agent payment stack means for API providers

The week the agent payment stack went live

Two things happened in early July 2026 that make this worth writing about now. First, at the Visa Payments Forum, Visa executed its first live agentic commerce payments across several European merchant sites — real transactions carried out by AI agents on behalf of customers, not a controlled demo. Second, fresh data put Base, Coinbase's Layer 2, at roughly 169 million agentic payments cumulatively, with more than 20 million in a single 90-day window. A category that barely existed a year ago is now measured in the hundreds of millions of transactions.

Underneath both headlines sits the same emerging plumbing: Google's Agent Payments Protocol (AP2) to authorize what an agent is allowed to buy, and x402 to actually settle the money. If you run an API, a data feed, or any paid endpoint, this is the part that matters — because the payer is increasingly a machine, and the unit of commerce is shrinking from a checkout to a single request.

What Google's AP2 actually is

Google Cloud and Coinbase introduced AP2 in September 2025 with more than 60 launch partners — Mastercard, PayPal, American Express, Coinbase, Adyen, Worldpay, Revolut, Salesforce and others. The problem it solves is deceptively simple: today's payment rails assume a human is sitting at the checkout. Once an agent can search, negotiate and buy on its own, that assumption breaks. Who authorized the purchase? Does the request faithfully reflect the user's intent? And if something goes wrong, who's accountable?

AP2's answer is mandates — tamper-proof, cryptographically signed records carried as W3C Verifiable Credentials. There are three in the flow: an Intent Mandate (the user's instruction and its limits — "book a hotel under $200"), a Cart Mandate (the exact items and final price the user approved), and a Payment Mandate (the authorization to charge a specific method for that cart). A merchant facing a dispute can point to a signed mandate proving the agent had authority for exactly that purchase. Crucially, AP2 is rail-agnostic: it defines authorization and accountability, not one particular way to move money. Cards, bank transfers and stablecoins are all first-class citizens.

Where x402 fits — and why stablecoins

That last point is where x402 enters. To bring crypto into AP2, Google — with Coinbase, the Ethereum Foundation and MetaMask — built the A2A x402 extension, described by Coinbase as the only stablecoin facilitator in AP2. x402 revives the long-dormant HTTP 402 "Payment Required" status code: a client requests a paid resource, the server replies 402 with the price and a destination, the client signs a stablecoin payment, attaches it to the request header, and gets the resource. No accounts, no sessions, no API keys.

The economics are the whole reason stablecoins are treated as first-class here. Card interchange runs roughly $0.30–$0.80 per transaction — uneconomic for a sub-dollar API call an agent might make thousands of times an hour. Stablecoin settlement on chains like Base or Solana costs a fraction of a cent and finalizes in seconds. So the division of labor is clean: agents that speak AP2 use it to prove authorization, then reach for x402 to settle the actual micropayment — most commonly in USDC on Base.

The stack, from the top down

It helps to see the whole picture as layers, because the industry has (deliberately) split the job across several open protocols rather than one monolith. From an agent's point of view a purchase touches four of them:

• A2A (Agent-to-Agent) — discovery and messaging. It's how an agent finds and talks to another agent or a merchant's agent. It handles no money.
• MCP (Model Context Protocol) — connects an agent to tools and resources (an API, a database, a document store).
• AP2 — the authorization layer. Signed mandates prove the user consented to this purchase, at this price, with these limits.
• x402 — the settlement layer. The stablecoin actually moves, over HTTP, in seconds.

The reason this matters to you: an API provider only has to live at the bottom of that stack. You don't have to implement A2A, or issue verifiable credentials, or understand mandate schemas. You have to be able to answer a request with a 402 and a price, and accept the signed payment that comes back. Everything above that is the agent's problem, handled by its wallet and its AP2 client.

Why the giants converged on the same rails

The striking thing about 2026 isn't that any one company built agent payments — it's that they all landed on the same open pieces. In April 2026, Coinbase donated the x402 specification to the Linux Foundation, where the x402 Foundation now governs it with a board that includes Cloudflare, Stripe and Visa. Amazon wired x402 into its Bedrock AgentCore payments and CloudFront. Cloudflare launched a Monetization Gateway built on x402. Stripe and Tempo shipped the Machine Payments Protocol for recurring agent payments. Visa's Trusted Agent Protocol handles the "is this a real agent or a bot" trust question and explicitly interoperates with x402. And Google's AP2 slotted x402 in as its stablecoin rail.

Convergence, not a format war. That's good news if you sell access to something, because it means you don't have to bet on a winner. The trap is assuming you must pick a camp — Base or Solana, USDC or another coin, AP2 or MPP. You don't. The endpoint you expose speaks the one layer they all share: an HTTP 402 and a stablecoin payment.

How to get paid by agents — step by step

Here's the honest version of "how hard is this." Building the full stack yourself means running an x402 server, managing a wallet, wiring a settlement facilitator, and keeping up with mandate and credential formats. With Payzum, the same result is a dashboard configuration — because Payzum sits in front of your API as middleware, not something you rebuild your service around.

1. Point Payzum at your existing endpoint. You give it the URL of the API you already run, plus your own API key or bearer token — no new backend, no protocol code.
2. Set a price per call. Flat per-request, or per route. Payzum publishes an x402-payable URL for it.
3. Agents hit the URL and get a 402. Payzum returns the price and destination, an external facilitator (currently Coinbase's) settles the USDC payment on Base, and the funds land in your wallet.
4. Payzum proxies the paid call. Once payment clears, Payzum forwards the request to your real endpoint with your key and returns the response. The agent got its data; you got paid; you never touched a private key custodied by anyone else.

To be precise about roles, because it's easy to get wrong: Payzum is the middleware/proxy in front of your API — not the facilitator. The facilitator that clears the on-chain payment is external (today, Coinbase's). Your API provider starts serving agents the same day, with zero code and zero protocol to implement.

Who this is for

The agent economy isn't hypothetical demand anymore — it's the shift Chainalysis tracked from meme-farming toward real utility, with transactions of $1 or more growing from about half of Base's agentic volume to the large majority. Concretely, x402-payable endpoints are already earning from:

• Data and API providers — pricing, weather, enrichment, search, scraping, geocoding. Agents pay per query instead of you managing keys, quotas and invoices for buyers you'll never meet.
• Tools and compute — inference endpoints, document parsing, image or audio processing, automation actions an agent triggers on demand.
• Content and knowledge — paywalled articles, datasets, research and reference feeds an AI assistant needs mid-task and will pay a fraction of a cent to read.

DIY stack vs. Payzum

Common objections

Isn't AP2 just a card-payments framework from Google?

No. AP2 is deliberately rail-agnostic — it standardizes authorization and accountability, not one payment method. Cards, bank transfers and stablecoins all plug in. The A2A x402 extension is what makes stablecoins first-class, and Coinbase describes it as the only stablecoin facilitator path in AP2. So "AP2" and "stablecoins over x402" aren't alternatives; the second is a settlement option inside the first.

Do I have to implement AP2 to get paid by agents?

No. Authorization (AP2 mandates) lives on the agent's side — its wallet and client prove consent. Your job as an API provider is only to answer a paid request with a 402 and accept the settlement. With Payzum that's a config step: expose the x402-payable URL and let agents' AP2/x402 clients do the rest.