# x402 vs MPP for AI agent payments

Canonical URL: https://commerce.delx.ai/guides/x402-vs-mpp-for-ai-agent-payments

Published and reviewed: 2026-08-11

## The short answer

x402 and MPP both make payment part of an HTTP request, but they are not
interchangeable wire contracts.

- **x402 v2** returns `402 Payment Required` with `PAYMENT-REQUIRED`; the
  client retries with `PAYMENT-SIGNATURE`; settlement feedback arrives in
  `PAYMENT-RESPONSE`.
- **MPP / Payment HTTP authentication** returns `402 Payment Required` with
  `WWW-Authenticate: Payment`; the client retries with
  `Authorization: Payment`; a successful response may include
  `Payment-Receipt`.

A client library may support both and choose from the methods advertised by a
request. That makes the client interoperable. It does not make the protocols
identical.

## Comparison

| Question | x402 v2 | MPP / Payment auth |
| --- | --- | --- |
| Initial signal | `402` + `PAYMENT-REQUIRED` | `402` + `WWW-Authenticate: Payment` |
| Paid retry | `PAYMENT-SIGNATURE` | `Authorization: Payment` |
| Success evidence | `PAYMENT-RESPONSE` | Optional `Payment-Receipt` |
| Payment model | Schemes and networks in payment requirements | Pluggable methods and intents |
| Buyer rule | Select a compatible advertised x402 requirement | Select a compatible advertised Payment challenge |

## Safe five-step agent flow

1. Send the exact intended request without payment proof. Preserve its method,
   canonical URL, input body, and an idempotency key where supported.
2. Inspect the live 402. Identify `PAYMENT-REQUIRED`,
   `WWW-Authenticate: Payment`, or explicitly advertised alternatives.
3. Apply buyer policy before signing: validate resource binding, amount,
   currency or asset, network or payment method, recipient, expiry, and maximum
   authorized spend.
4. Retry with the proof required by the selected protocol. Do not translate one protocol's proof header into the other.
5. Verify the output contract, artifact or structured result, receipt or
   settlement evidence, and failure/refund path before marking delivery
   complete.

Discovery helps an agent plan. The live challenge is authoritative for current
terms. A challenge is not a sale, and a payment alone does not prove delivery.

## Delx Commerce

Delx publishes canonical paid routes through:

- Paid OpenAPI: https://api.delx.ai/openapi.x402.json
- x402 manifest: https://api.delx.ai/.well-known/x402
- Buyer method: https://commerce.delx.ai/discovery-center#buyer-method
- Reliability passport: https://commerce.delx.ai/agent-reliability-passport.json

The Delx compatibility runtime passes x402 v2 and MPP proofs on routes where
they are advertised. Support is route-specific. Inspect the live 402 and never
send payment credentials to a discovery URL or an unrelated resource.

## Primary sources

- x402 HTTP 402 and v2 headers: https://docs.x402.org/core-concepts/http-402
- x402 Foundation specifications: https://github.com/x402-foundation/x402/tree/main/specs
- Payment HTTP Authentication Scheme: https://paymentauth.org/draft-httpauth-payment-00
- Payment service discovery: https://paymentauth.org/draft-payment-discovery-00.html
- MPP EVM and x402 client support: https://mpp.dev/blog/evm-x402-support

The Payment specifications are Internet-Drafts and may change. This reference
records the observed contract on 2026-08-11; production clients must parse the
current challenge.

## FAQ

### Is MPP the same as x402?

No. They share the HTTP 402 status code but define different wire contracts.

### Which protocol should an AI agent choose?

Choose one advertised by the live resource and supported by the agent's wallet,
client, and risk policy.

### Can one SDK support both?

Yes. The SDK must still emit the challenge response required by the protocol it
selects.

### Is a discovery document authoritative?

It is orientation. The live 402 is authoritative for current payment terms.

### Does successful payment prove delivery?

No. Validate the returned result, receipt or settlement evidence, and the
service's failure/refund contract.