AP2 and x402: How AI Agents Actually Pay for Things Now

If you’ve wired an AI agent up to browse, compare, and buy things on a user’s behalf, or built an API you’d like agents to pay for automatically instead of provisioning API keys by hand, there’s now an actual standard for the payment step instead of everyone inventing their own. Two pieces make it work: Google’s AP2 for the purchase itself, and x402 for settling machine-to-machine micropayments in stablecoins. Here’s what each one does and where they fit.

The problem neither party could solve alone

An agent that can browse and reason its way to a purchase decision still hits the same wall every time: how does it actually pay, in a way the merchant can trust and the user can audit? Handing an agent a stored credit card and hoping for the best doesn’t give a merchant any way to verify the charge matches what the user actually wanted, and it doesn’t give the user a clean record to dispute a mistake. That trust gap is what kept “agents that shop for you” a demo rather than a production feature.

AP2: mandates, not blind trust

AP2, Google’s Agent Payments Protocol, launched with more than 60 partners including Mastercard, PayPal, Coinbase, American Express, and Salesforce. Its core idea is straightforward: every agent-initiated purchase gets represented as three separate signed records, called Mandates.

Mandate	What it captures	Who signs it
Intent Mandate	What the user actually asked for (“book a flight to Austin under $400”)	The user
Cart Mandate	What the agent assembled to fulfill that intent (the specific flight, price, seller)	The agent
Payment Mandate	What the merchant or payment network will actually charge	The payment processor

A merchant or card network can check that all three line up before money moves, and if a dispute happens later, there’s a cryptographically verifiable trail showing exactly what was authorized versus what the agent decided on its own. That’s the piece that was missing before: not the ability for an agent to transact, but a paper trail a human, a merchant, and a bank can all trust after the fact.

x402: reviving a 30-year-old HTTP status code

HTTP status code 402, “Payment Required,” has been sitting in the HTTP specification since 1997 as a placeholder for a micropayment layer the web never actually built. x402, developed with Coinbase, the Ethereum Foundation, and MetaMask as an extension to AP2, is what finally uses it.

The flow is simple enough to implement directly:

1. Agent requests a resource
   GET /api/weather?city=austin

2. Server responds 402, with machine-readable payment terms
   HTTP/1.1 402 Payment Required
   X-Payment-Required: {
     "amount": "0.001",
     "asset": "USDC",
     "network": "base",
     "payTo": "0xExampleRecipientAddress"
   }

3. Agent signs a payment authorization and retries the same request
   GET /api/weather?city=austin
   X-Payment: <signed EIP-3009 authorization>

4. A facilitator service verifies the payment onchain,
   the server returns the resource
   HTTP/1.1 200 OK

No signup flow, no provisioned API key, no invoice sitting in someone’s inbox. An agent that needs a weather lookup, a dataset, or a single inference call pays a fraction of a cent and gets the resource, in the same request cycle. For API providers, this turns “who’s calling my API and are they paying for it” into something the payment layer answers automatically, instead of a billing system bolted on afterward.

Where each one actually fits

AP2 is the broader contract layer for agent-initiated purchases across whatever rail makes sense, cards, bank transfers, real-time payment systems like FedNow or UPI, or stablecoins. x402 is one settlement rail built specifically for the case AP2 alone doesn’t optimize for well: fast, tiny, machine-to-machine payments where setting up a traditional merchant account per API call would be absurd. If you’re building an agent that books travel or shops for a user, you’re in AP2’s territory. If you’re building or consuming an API that should charge per call without an account system, x402 is the more direct fit.

Both plug into the same agent tooling ecosystem your team may already be using. If you’re building agents on MCP or orchestrating multiple agents that need to transact independently, payment capability is the next layer on top of the coordination layer you’ve likely already built.

The honest caution

Treat both as early. AP2’s reference SDK only reached v0.2.0 in April 2026, and reference implementations across languages are still maturing. The protocols themselves are designed around verifiability, mandates that can be checked and audited, but that doesn’t substitute for your own operational discipline. Before letting an agent transact with real money in production, put hard spending caps at the mandate level, scope exactly what each agent is authorized to buy, and log every Mandate somewhere you can actually audit later. The standard gives you the receipt. It doesn’t give you the judgment call on how much autonomy to hand an agent in the first place, that’s still on your team.

If your product roadmap includes agents that need to transact, whether that’s paying for third-party API calls or completing purchases on a user’s behalf, this is worth prototyping now while the ecosystem is still small enough to reason about end to end. Teams that wait until it’s a mainstream expectation will be retrofitting mandate logic into an agent architecture that wasn’t built for it. If you want a second set of eyes on that architecture before you commit to it, that’s exactly the kind of design review our AI integration work covers.