Both make payment part of an HTTP request. They do not use the same proof contract. Inspect the live 402, choose a wire format your client actually supports, enforce a spend policy, and verify the delivered result.
HTTP 402x402 v2MPPAI agentspayment safety
Direct answer
Same status code, different contract.
x402 and the Machine Payments Protocol both turn 402 Payment Required into a machine-actionable exchange. x402 v2 standardizes payment metadata and proofs in dedicated payment headers. MPP builds on the HTTP Payment authentication scheme and separates the common challenge from pluggable payment methods and intents. A multi-protocol SDK can hide those differences from application code, but the wire messages remain distinct.
Protocol comparisonRead what is actually on the wire
Question
x402 v2
MPP / Payment auth
Initial signal
402 plus PAYMENT-REQUIRED
402 plus WWW-Authenticate: Payment
Paid retry
PAYMENT-SIGNATURE
Authorization: Payment
Success evidence
PAYMENT-RESPONSE
Optional Payment-Receipt
Payment model
Schemes and networks selected from payment requirements
Payment methods and intents such as charge, session, or subscription
Agent decision
Use when the live resource advertises a compatible x402 requirement
Use when the live resource advertises a compatible Payment challenge
Safe decision flow
Inspect the live 402 before choosing a protocol.
Discovery documents help an agent plan, but the current response is authoritative for price and supported payment paths. Never synthesize a proof header from a different protocol.
# 1. Send the intended request without payment proof.
# 2. If the response carries PAYMENT-REQUIRED, use an x402 v2 client.
# 3. If it carries WWW-Authenticate: Payment, use an MPP client.
# 4. Keep method, URL, and body identical on the authorized retry.
# 5. Enforce max spend and verify the result plus receipt.
Five-step buyer method
Challenge → policy → matching proof → delivery.
Make the exact request. Preserve its method, canonical URL, input body, and an idempotency key when the service supports one.
Classify the live challenge. Look for x402 v2 PAYMENT-REQUIRED, MPP WWW-Authenticate: Payment, or explicitly advertised alternatives.
Apply policy before signing. Check amount, currency or asset, network or method, recipient, resource binding, expiry, and your maximum spend.
Retry with one matching proof. Use PAYMENT-SIGNATURE for x402 v2 or Authorization: Payment for MPP. Do not translate one protocol's proof header into the other.
Verify the business outcome. Validate the output schema, artifact hash or URL, settlement/receipt evidence, and refund path. A challenge is neither revenue nor delivery.
Delx implementation note
Follow the protocol advertised by each Delx route.
Delx Commerce publishes canonical products and prices through the paid OpenAPI, x402 manifest, and product pages. The compatibility runtime can pass x402 v2 and MPP payment proofs on routes where they are advertised. Compatibility is route-specific: inspect the live challenge, do not assume every product exposes every payment method, and never send payment credentials to discovery or unrelated URLs.
Internet-Drafts are works in progress and may change. This guide records the observed contract on 2026-08-11; production clients must still parse the current challenge.
Direct answers
x402 vs MPP FAQ
01
Is MPP the same as x402?
No. They share HTTP 402, but define different challenge, proof, and receipt contracts.
02
Which should an agent choose?
Only one advertised by the live route and supported by the buyer's wallet, SDK, and risk policy.
03
Can one SDK support both?
Yes. That is client interoperability, not wire-level equivalence. The SDK must still emit the proof required by the selected protocol.
04
Is discovery authoritative?
It is useful orientation. The live 402 remains authoritative for current terms and supported payment paths.
05
Does payment prove delivery?
No. Verify the returned result, receipt or settlement evidence, and failure/refund contract separately.