AP2 vs x402: Authorization Layer vs Payment Settlement Layer
May 8, 2026
AP2 vs x402: Authorization Layer vs Payment Settlement Layer#
AP2 and x402 are complementary more than they are direct substitutes. AP2 answers whether an agent was authorized to make a payment. x402 answers how a protected HTTP resource can request and verify payment. A serious agent commerce stack may need both.
The confusion comes from the word “payment.” AP2 is about permission, proof, and accountability. x402 is about settlement and access.
The short version#
| Criterion | AP2 | x402 |
|---|---|---|
| Main function | Proves authorization and user intent | Requests and verifies payment over HTTP |
| Main artifact | Mandates and cryptographic proof | HTTP 402 payment request and payment proof |
| Best fit | Agent checkout, delegated commerce, auditability | Paid APIs, MCP tools, data access, microtransactions |
| Payment rail | Payment method agnostic | Often stablecoin based, expanding through ecosystem support |
| Core risk addressed | Was this agent allowed to buy this? | Has this resource been paid for? |
What AP2 is designed to solve#
Google introduced AP2 to make agent led payments safer across platforms. The core issue is not just payment execution. It is authorization.
A merchant, issuer, or payment processor needs evidence that a human gave an agent authority to act. The evidence also needs to match the final cart. If the user asked for running shoes under $120, the agent should not silently buy a $230 jacket.
AP2 addresses this through mandate concepts. The protocol records user intent and payment context in a way that can be verified later. Google’s later AP2 update also introduced work around autonomous transactions where the human may not be present at the exact moment of payment, based on prior authorization.
That is a trust layer.
What x402 is designed to solve#
x402 solves a narrower and very practical problem: how can a server request payment before granting access to a resource?
A client asks for a resource. The server responds with HTTP 402 Payment Required and payment details. The client pays or attaches payment proof. The server verifies and returns the resource.
This pattern is especially useful for agents because small, automated transactions are awkward in traditional checkout systems. An agent should not create an account and negotiate a subscription just to buy one API response.
Why AP2 and x402 can be combined#
In a hybrid stack, AP2 can prove authorization while x402 handles settlement.
Example flow:
- A user authorizes an agent to buy premium market data up to a defined budget.
- AP2 captures the user intent and authorization boundaries.
- The agent calls a protected data endpoint.
- The endpoint returns an x402 payment requirement.
- The agent settles through x402 within the authorized limits.
- The merchant or service keeps proof of both authorization and payment.
That stack is stronger than either layer alone.
Where AP2 is stronger#
AP2 is stronger when the transaction has legal, compliance, fraud, or accountability risk.
Good AP2 use cases include:
- Retail purchases made by an assistant
- Agent based procurement
- Travel booking
- Insurance policy servicing
- High value purchases with pre authorized constraints
- Agent to agent payments where responsibility matters
Where x402 is stronger#
x402 is stronger where the transaction is small, digital, and directly tied to resource access.
Good x402 use cases include:
- Paid API calls
- MCP tool invocation
- Premium web content for agents
- Data packets
- Per request inference
- Machine readable research files
AEO implications#
AEO teams should expose both payment and authorization requirements in machine readable form.
For each payable action, document:
- Whether the action requires user authorization
- Whether autonomous execution is allowed
- Which payment protocols are supported
- Whether x402 payment is accepted
- Which mandate or credential proof is required
- How errors and refunds are handled
- How an agent verifies completion
This documentation should be linked from llms.txt, the protocol hub, and relevant action pages.
FAQ#
Is AP2 better than x402? AP2 is better for authorization and accountability. x402 is better for direct HTTP payment settlement. They solve different layers.
Does AP2 use x402? AP2 is payment method agnostic and can work with different rails. x402 can be used as a settlement mechanism in AP2 compatible flows.
Should API providers implement AP2? Most API providers should look at x402 or MPP first. AP2 becomes more important when the API action has delegated authority, high risk, or a purchase mandate.
Should ecommerce merchants implement x402? Not as the first protocol in most cases. Ecommerce merchants usually need commerce and authorization layers before raw per request settlement.
Sources#
Primary references: Google Cloud AP2 announcement, Google AP2 FIDO Alliance update, x402 documentation, and Linux Foundation x402 Foundation announcement.