x402 and AP2 Explained: How Agent Payment Protocols Divide the Work

More than 100 payment providers and technology companies have already aligned behind AP2. Coinbase's x402 has processed over 119 million transactions on Base. If you're building payment infrastructure for agents, these are the two protocols you need to understand.

x402 is an HTTP-based payment primitive developed by Coinbase. When a server returns an HTTP 402 status ("Payment Required"), the agent reads the payment instructions embedded in the response, signs a stablecoin transaction, attaches the proof, and retries the request. No user session, no login flow. Settlement happens on-chain in seconds.

AP2 (Agent Payments Protocol) is Google's open standard for agent-initiated commerce. Its job is trust and authorization at the session level: before an agent can spend anything, the user must issue a cryptographically-signed Mandate that proves intent. AP2 includes an x402 extension, co-developed with Coinbase, Ethereum Foundation, and MetaMask, that makes x402 the crypto/stablecoin payment method inside AP2.

They are not competing. They solve different layers of the same problem.

What x402 is and how it works

x402 is a payment protocol for machine-to-machine API calls. The design is deliberately minimal. It reactivates the HTTP 402 status code that has existed in the spec since 1991 but was never standardized until now.

The flow:

1. An agent calls an API endpoint.
2. The server returns HTTP 402 with a payment payload: amount, currency, destination address, accepted stablecoin(s), network.
3. The agent's wallet signs a stablecoin transaction meeting those terms.
4. The agent re-sends the original request with the payment proof attached in the header.
5. The server verifies the proof and fulfills the request.

No login. No credit card. No OAuth token. The payment is the credential.

As of March 2026, x402 had zero protocol fees and roughly $600M in annualized volume across Base and Solana. Coinbase subsequently moved x402 to the Linux Foundation with backing from Google, Stripe, and Visa. That move matters operationally: governance is now neutral, and protocol risk is lower than it would be under a single corporate sponsor.

If your API serves agents directly and you want metered, frictionless payment without building a subscription or session management layer, x402 is the mechanism. It does not manage trust across sessions, does not verify user intent, and does not know whether the agent acting is authorized by the end user. That is intentionally out of scope.

What AP2 is and how it works

Google's AP2 launch included Coinbase, Mastercard, PayPal, American Express, Revolut, Shopee, Salesforce, Worldpay, Adyen, Etsy, JCB, and UnionPay among its 60+ founding partners. Within six weeks, the coalition had passed 100 partners. The spec is publicly available here.

AP2's central concept is the Mandate: a cryptographically-signed digital contract that records what the user has authorized an agent to do before any transaction can be initiated. A Mandate can specify spending limits, approved merchants, valid time windows, and payment methods. Without a valid Mandate, the agent cannot initiate a payment under AP2.

The trust model works like this:

1. The user or enterprise configures a Mandate: scope, limit, expiry.
2. The Mandate is signed and issued to the agent.
3. The agent presents the Mandate when initiating a payment.
4. The payment provider verifies the Mandate cryptographically before processing.

AP2 works across traditional payment rails (cards, bank transfers) and, via the AP2 x402 extension, stablecoins and on-chain settlement. That extension is where the two protocols meet directly.

AP2 is your authorization and trust layer for agent commerce at scale. If you are building infrastructure that agents will use to buy goods or services, call paid APIs, or execute recurring payments on behalf of users, you need the Mandate framework. x402 payments can operate inside that framework as the settlement method.

How x402 and AP2 fit together

The clearest way to see the relationship is through the protocol stack.

AP2 operates at the session and authorization layer: it answers "is this agent allowed to spend, on behalf of whom, under what constraints?" x402 operates at the call layer: it answers "how does the agent pay for this specific API call right now?"

The AP2 x402 extension fuses both. When an agent operating under an AP2 Mandate needs to pay for an API call using stablecoins, the x402 mechanism handles the per-call settlement. The Mandate gives AP2 the authorization context. x402 handles the settlement mechanics.

Neither protocol is an execution layer. They define the interface, the message format, the verification logic. They specify what the payment request looks like and what a valid response must contain. Executing the transaction requires the work beneath the protocol: holding the keys, signing with an auditable trail, screening the destination address, dispatching funds. All of it happens in the wallet infrastructure that lives beneath both.

The scenario without and with the right infrastructure

Consider an AI agent that has been authorized by a business to call a data API and pay per query. The agent is operating under an AP2 Mandate and issues an x402 payment for each call.

Without adequate wallet infrastructure: The agent generates a payment proof and submits it. Your backend receives a signed stablecoin transaction request. If your withdrawal pipeline doesn't have automated signing, configurable approval thresholds, and real-time KYT screening, you face a choice between manual review (which breaks the latency model entirely) and blind execution (which is a compliance and fraud exposure).

With WaaS plumbing underneath: The request hits CoinSend, which routes the transaction to CoinSign for RSA/HMAC-SHA256 authorization before dispatch. CoinGet's automatic KYT screens the destination address before funds move. The signing, the screening, and the dispatch all happen in the infrastructure layer, under the protocol layer, without breaking the sub-second latency model that x402 is designed for.

That is the execution layer distinction. x402 and AP2 describe the interface. CoinGet, CoinSend, and CoinSign are the plumbing.

CoinsDo WaaS is non-custodial: private keys stay with the operator, not with CoinsDo. CoinSign's RSA/HMAC-SHA256 signatures provide an unforgeable authorization trail per transaction. The platform supports agent-deployed wallet use cases across ETH/ERC-20, TRX/TRC-20, BNB/BEP-20, Polygon, Solana, and a range of other chains, with client-requested chain integrations running on approximately a one-month cadence.

If your agents are operating cross-chain, that coverage matters. x402 began on Base and Solana. AP2 is chain-agnostic at the framework level. Your infrastructure needs to match the chains your agents will actually use.

For a closer look at how this works in a WaaS context, read more here

For the infrastructure decisions that follow from these protocols (key custody, approval flows, compliance automation, and chain coverage), read more here

FAQ

Do I need to implement both x402 and AP2?

Not necessarily, and not at the same time. If your use case is API monetization where agents pay per call and you don't need session-level authorization, x402 alone may be sufficient. If you are building agent-to-merchant commerce where user intent and spending limits must be cryptographically verifiable across multiple transactions, AP2 gives you the Mandate framework. For stablecoin-settled agent commerce at any meaningful scale, you'll likely end up implementing both: AP2 for trust and authorization, x402 (via the AP2 x402 extension) for settlement mechanics.

Where does wallet infrastructure fit in the stack?

Above the blockchain, below the protocol. x402 and AP2 define the message format and verification logic. They don't hold keys, they don't sign transactions, and they don't screen counterparties. That work belongs to the wallet layer: deposit address generation, transaction signing, KYT screening, and automated dispatch. Neither protocol specifies what that layer looks like. You bring your own.

Is x402 stable enough to build on now?

The move to the Linux Foundation with Stripe, Google, and Visa as backers is a strong signal of protocol stability. The x402 GitHub and the 119M+ transaction track record on Base suggest the core mechanism is past the experimental stage. The governance model is now neutral. That said, you should expect the AP2 x402 extension to evolve as AP2 itself matures, so build with the spec, not against a specific vendor's implementation.

How do AP2 Mandates prevent unauthorized agent spending?

Mandates are cryptographically signed, not just token-gated. The agent must present a valid Mandate to initiate any AP2-compliant payment, and the payment provider verifies the cryptographic signature before processing. Spending limits, merchant restrictions, and expiry windows are embedded in the Mandate itself, not enforced at the application layer. An agent cannot spend outside the Mandate's scope, even if the agent is compromised, because the provider-side verification will reject any transaction that exceeds the authorized parameters.