// POST 061 / 085

x402 vs AP2 vs MPP: Where Agent Identity Fits

April 20, 2026 /

x402 vs AP2 vs MPP is not a winner-take-all comparison. x402 and MPP focus on programmatic payment exchange over HTTP. AP2 focuses on authorization evidence for agent-led checkout. Agent identity fits before those payment flows, because the merchant, processor, user, and agent all benefit from knowing which agent is asking to spend, what endpoint the agent controls, and which records can be verified before value moves.

Payments move value; identity helps decide whether value should move. For HeadlessDomains.com, the practical pattern is to publish a persistent identity, machine-readable manifest, trusted endpoints, and payment metadata so payment protocols can evaluate a named agent rather than an anonymous request.

Quick Comparison

Protocol	Primary job	Best fit	What identity adds
x402	Uses HTTP 402 to let a server request payment and let a client retry with a payment payload.	Paid APIs, content, MCP tools, and pay-per-request services.	A stable agent profile, operator proof, allowed endpoints, and policy context before the paid request.
AP2	Uses signed checkout and payment mandates, receipts, and verification duties for agent-performed payments.	Agentic commerce where a user authorizes an agent to buy under specific constraints.	A durable agent key, public manifest, proof of control, and discovery record for verifiers.
MPP	Standardizes machine-to-machine payments via HTTP 402 with challenges, credentials, receipts, and multiple payment methods.	Agents and apps paying for API requests, tool calls, content, sessions, or recurring access.	A canonical place to discover who the paying agent is, which methods the agent supports, and which surfaces are trusted.

Read the Protocols by Layer

x402 describes a direct HTTP pattern: a client requests a resource, the server returns 402 Payment Required with payment instructions, the client submits a payment payload, and the server verifies or settles before returning the resource. The x402 docs frame buyers as human developers, AI agents, or programmatic services, while sellers can use the protocol for paid APIs, content, and other HTTP-accessible resources.

AP2 addresses a different question: how can an agent prove that a user authorized a purchase? The AP2 v0.2 specification defines roles such as Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor, and Trusted Surface. The protocol uses checkout mandates, payment mandates, receipts, and verification rules so parties can evaluate what was authorized and what was completed.

MPP also uses HTTP 402, but MPP presents a broader challenge, credential, and receipt model for machine payments. MPP documentation describes payment-gated API requests, tool calls, content, sessions, subscriptions, multiple methods, and OpenAPI-based discovery so agents can inspect payment options before making requests.

Where Identity Fits

Identity should sit upstream from payment execution. Before an agent pays with x402 or MPP, the service can inspect a public identity record for the agent name, operator, manifest, endpoint list, policy URL, and proof links. Before a merchant or processor evaluates AP2 mandates, a public identity record can help correlate the agent key, mandate context, and trusted surface back to a stable namespace.

That identity layer does not replace the payment protocol. x402 still handles HTTP-native payment exchange. AP2 still handles authorization evidence and verification duties. MPP still handles challenge, credential, receipt, and method negotiation. The identity layer gives those flows a named, inspectable actor.

Implementation Checklist

Publish an agent identity record with operator, purpose, public keys, endpoints, support contact, and proof links.
Link agent.json, SKILL.md, OpenAPI, MCP, and payment metadata from the same persistent identity.
For x402 or MPP, expose the paid endpoint, accepted methods, settlement expectations, and receipt handling in machine-readable form.
For AP2, keep agent keys, mandate constraints, receipts, and dispute evidence traceable to a stable agent record.
Separate value movement from identity verification in logs so payment success does not imply agent trust.
Use deterministic server-side checks for authorization, payment, and policy enforcement.

Example Identity Record

{"name":"atlas.agent","operator":"Atlas Research","manifest":"https://atlas.agent/.well-known/agent.json","payment":{"x402":"https://api.atlas.agent/x402","mpp":"https://api.atlas.agent/.well-known/mpp","ap2":{"agent_key_id":"did:key:z6Mk...","mandate_policy":"https://atlas.agent/policies/ap2"}},"proof":{"dns_txt":"_agent.atlas TXT","https":"https://atlas.agent/proof"}}

Where HeadlessDomains.com Fits

HeadlessDomains.com gives agents a persistent identity anchor for manifests, permissions, discovery, endpoints, and payment metadata. A .agent identity can point verifiers to the same canonical record before an x402 request, an AP2 mandate evaluation, or an MPP challenge response.

For merchants preparing agent-readable commerce, pair payment support with discoverability. The next useful read is how to make a store discoverable to AI shopping agents, which connects catalog visibility, agent-readable records, and commerce readiness.

Internal Reading Path

Sources

FAQ

Is x402 the same as MPP?

No. Both use HTTP 402 patterns for programmatic payment, but x402 documentation centers on HTTP-native payment exchange for APIs and content, while MPP documentation describes a broader challenge, credential, receipt, method, session, and discovery model for machine payments.

Does AP2 move money?

AP2 secures authorization and evidence for agent-performed payment transactions. The AP2 specification treats the payment instrument and commerce protocol as separate extension points, while mandates and receipts help verifiers evaluate the agent-performed checkout.

Can a site use more than one protocol?

Yes. A merchant could use AP2 for user authorization evidence and x402 or MPP for paid resource access. The right mix depends on whether the flow is API access, checkout authorization, tool usage, content access, or recurring service usage.

Why add a persistent identity layer?

Payment protocols can prove that a payment payload, mandate, credential, or receipt satisfies a protocol rule. A persistent identity layer helps the receiving party evaluate the named agent, operator, endpoints, public keys, and policies before accepting the flow.

What should Headless Domains users publish first?

Publish the public agent identity record first, then connect manifests, API contracts, tool metadata, payment metadata, and proof links. That order gives agents and verifiers one canonical place to inspect the actor before value moves.

[← ALL POSTS] [GET YOUR .AGENT →]