x402 vs AP2 vs MPP: How AI Agent Payments Compare

An agent paying for a search result and an agent buying equipment for your company face different problems. The first needs a way to pay for access. The second also needs to prove that you approved the purchase.

x402 and MPP provide programmatic payment flows. AP2 secures agent-led purchases with authorization mandates and receipts. They can work together, but you don't need to adopt all three for every transaction.

The comparison has also moved beyond “payments versus identity.” x402 documents wallet authentication and discovery extensions. MPP's SDK supports signed agent identity. AP2 already binds autonomous purchasing authority to an agent key. A public agent name has a useful role alongside those mechanisms, without being a requirement for using them.

x402 vs AP2 vs MPP at a glance

These are starting points for choosing an implementation. Available payment methods, extensions and client support determine what your service can actually offer.

x402: charge for a resource over HTTP

With x402, a client requests a resource and the server can respond with 402 Payment Required and payment requirements. The client supplies a payment payload, which the server checks through the configured payment scheme. The x402 introduction describes uses including paid APIs and content.

If you're implementing it now, use the current version's contract. x402 v2 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE and PAYMENT-RESPONSE headers. Older examples using X-PAYMENT need updating; the v1-to-v2 migration guide explains the changes.

Don't assume every paid request settles in the same way. The current documentation includes exact, upto and batch-settlement schemes. Batch settlement can authorize access before later redemption, so a successful resource response isn't a universal promise of immediate onchain settlement. Check the documented payment flow for the scheme you're using.

x402 also has optional capabilities beyond payment exchange. Its Bazaar extension supports discovery of paid resources. Sign-In-With-X lets a client prove wallet control, including for repeat access to a purchased resource or an authentication-only route. Those features need implementation support; they aren't automatically enabled on every x402 service.

MPP: choose the payment method and interaction your service needs

MPP, the Machine Payments Protocol, organizes payment around a challenge, a credential and a receipt. Its HTTP flow uses a payment challenge to tell the client what the service accepts. A compatible client responds with the appropriate credential.

The current MPP documentation covers payment methods and intents for charges, sessions and subscriptions, as well as transports beyond HTTP. Support varies by method and SDK. Before selecting it for a recurring or session-based service, check that the particular combination you need is implemented on both sides.

MPP and x402 aren't completely separate implementation choices anymore. MPP's June 8, 2026 EVM and x402 announcement documents support in mppx for compatible x402 exact flows alongside MPP charges. A configured server can advertise both. That is a specific compatibility path, not a claim that every x402 extension works with every MPP client.

There is a newer identity capability, too. The August 12, 2026 mppx identity update adds Web Bot Auth and Trusted Agent Protocol support. When configured, the SDK signs the initial request and paid retries, and the server verifies those signatures for its access policies. This is SDK support that applications choose to configure, rather than a universal requirement of MPP.

AP2: prove what the agent was allowed to buy

AP2 becomes relevant when an agent acts on a buyer's authority. Suppose you allow an agent to buy a replacement monitor within an approved budget. The merchant and payment provider need evidence connecting the purchase to that permission.

The current AP2 v0.2 specification uses checkout mandates and linked payment mandates, with receipts for the resulting transaction. It supports direct, human-present purchases and autonomous flows. In the autonomous flow, an open mandate includes the agent's public key, constraining who can use the authority.

AP2 leaves the payment instrument extensible and operates within a commerce system. It doesn't supply the whole catalog or checkout API. Its mandates give the participating systems authorization evidence they must verify.

One naming trap: AP2's specification also abbreviates “Merchant Payment Processor” as MPP. That role is different from the Machine Payments Protocol discussed here.

Choose for the transaction you actually have

For a paid lookup or tool call, compare x402 and MPP against the clients you expect to serve. Look at supported payment methods, pricing models, settlement behavior and the work required to operate the service. A protocol your customers' agents can complete is more useful than a longer feature list they can't use.

For an agent shopping under a user's instructions, evaluate AP2's authorization model alongside your commerce and payment systems. The official AP2 project includes x402 samples for human-present and human-not-present flows. There are documented ways to combine them; integration still requires compatible implementations.

Once you've chosen a flow, test its failure cases as well as a successful purchase. Our pre-payment API checklist covers the operational checks. The separate identity, authorization and receipts guide looks at the evidence around a transaction.

Where a public agent name helps

None of these protocols requires a Headless Domains name. Wallet signatures, agent keys and request attestations already serve specific authentication or authorization purposes. A public name helps someone recognize the agent across its services and find the records its operator maintains.

For example, a research agent might offer a paid API, publish reports elsewhere and appear in a directory. A maintained identity can point to its official interfaces and machine-readable information. If an endpoint changes, the operator can update the record while retaining the name.

That record supplies references to inspect. It doesn't prove every claim in the profile, grant spending permission or configure a payment integration. Connecting a public identity to a signing key requires evidence the relying system can verify. The Agent Identity Stack explains those boundaries.

Your existing website can stay where it is. We cover that question separately in whether conventional domains can use MPP and x402.

Choose payment software that fits the transaction. When your agent also needs a public name connecting its services, give it the Headless Domains skill file and ask it to explain the current registration options before taking action.

Documentation checked September 10, 2026. Protocol and SDK capabilities described here depend on the versions and configuration used by each implementation.