I used both machine-payment protocols with real money in July. One retained run made 111 MPP purchase attempts over Tempo. Eight days later, another made 242 x402 attempts over Base.
The shortest honest answer is that both made a paid API feel like an ordinary HTTP request. In these runs, x402 was the cleaner fit for sampling many fixed-price endpoints once. MPP exposed a broader commercial envelope: several payment methods, metered sessions, subscriptions, and products that extended beyond narrow data calls.
The endpoint still mattered more than the rail. Both protocols moved money successfully for excellent products, empty products, malformed products, and provider errors.
These were two dated field reports. Different days, catalogs, price limits, and selection rules prevent a controlled benchmark. This comparison separates what the current specifications say from what our two wallets actually experienced.
They share the same purchase skeleton
MPP and x402 both turn 402 Payment Required into a machine-readable negotiation. A client asks for a resource, receives payment terms, authorizes payment, retries the request, and gets the resource plus payment evidence.
The wire formats differ. MPP’s HTTP transport uses WWW-Authenticate: Payment for the challenge, Authorization: Payment for the credential, and Payment-Receipt for the receipt. x402 v2 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE, each carrying Base64-encoded structured data.
That makes the protocols conceptually similar and wire-incompatible. A client library can hide most of the distinction once it recognizes the challenge.
The protocols put the abstraction in different places
MPP describes a general Challenge–Credential–Receipt exchange and lets the challenge name a payment method. Its current guides cover one-time charges, usage-based sessions, subscriptions, and multiple methods on one endpoint, including Tempo stablecoins, Stripe cards, and Lightning Bitcoin.
x402 describes payment requirements in terms of a scheme, network, asset, amount, and destination. Its current SDKs document exact, upto, and batch-settlement: fixed prices, usage with a maximum authorization, and off-chain vouchers redeemed in batches. The protocol now supports multiple crypto network families and token types, while optional extensions add discovery, idempotency, wallet authentication, and signed offers and receipts.
| Question | MPP | x402 |
|---|---|---|
| What crosses HTTP? | Challenge, credential, receipt | Payment requirements, signature, settlement response |
| Simplest fixed purchase | charge |
exact |
| Variable usage | session with a growing authorization |
upto with a maximum charge |
| Repeated high-volume usage | Session payment channel | batch-settlement vouchers |
| Recurring access | Subscription primitive | Compose payment with an external plan manager or access layer |
| Payment-method emphasis | One interface across stablecoins, cards, Bitcoin, and custom methods | Crypto-network and token schemes with facilitator or self-settlement paths |
| Discovery | MPP service directory and OpenAPI discovery | Bazaar discovery extension and facilitator catalogs |
The boundary is already getting porous. MPP’s mppx SDK added x402 exact-flow support, so a buyer can use one client surface for both wire protocols. A seller can also advertise both rather than making the buyer choose a camp.
What we actually tested
Our runs exercised one settlement path from each protocol. The MPP wallet paid direct USDC.e on Tempo. It did not use Stripe, cards, Bitcoin, or MPP Credits. The x402 wallet paid USDC on Base. It did not test the other networks, assets, upto, or batch settlement now covered by x402.
MPP field run
x402 field run
The numbers looked similar until I examined the denominators
MPP over Tempo
- Useful calls
- 69
- Companies delivered
- 67
- Spend
- $2.360092
- Median success
- 1.795s
- Saved responses
- 1.49 MB
x402 over Base
- Useful paid calls
- 149
- Settled calls
- 164
- Net spend
- $1.400875
- Median settled call
- 7.09s
- Paid responses
- 1.12 MB
The raw useful shares were almost identical: 69 of 111 MPP attempts, or 62.2%, and 149 of 242 x402 attempts, or 61.6%. That resemblance is visually satisfying and analytically weak. Removing MPP’s recorded safety skips changes its denominator, and neither run tested the same basket of products.
MPP had the faster median successful response at 1.795 seconds, then a much longer tail: the slowest successful job took 410.698 seconds. x402’s median settled call took 7.09 seconds, while its slowest took 23.86 seconds. Product shape likely explains part of that difference. The MPP catalog included image generation, deep research, screenshots, uploads, and other asynchronous work; the x402 sweep deliberately favored bounded calls below five cents.
The observed cost per useful result was about 3.42¢ for MPP and 0.94¢ net for x402. The x402 run had a strict under-$0.05 ceiling. The MPP run bought products costing as much as roughly $0.31. Those figures describe shopping choices rather than protocol fees.
MPP exposed broader products; x402 exposed more sellers in our snapshots
MPP’s memorable products included a one-day inbox, a file upload, generated art, synth-pop lyrics, a screenshot, long-running person research, and live transit data. Its directory also advertised physical delivery, gambling, donations, public posting, and paid human work that I declined to authorize.
The x402 sweep attempted 242 catalog provider groups and settled with 164 of them in 55 minutes. Most products were smaller structured objects: a sanctions heartbeat, DNS result, prompt score, schema extraction, financial series, web audit, embedding, market snapshot, or routing decision.
These catalog snapshots cannot establish protocol market share. They were taken eight days apart, x402 grouped sellers with a domain-based key, and the eligibility rules differed. Fifty-one settled x402 keys were hosted-project deployments; multiple deployments may share an operator.
Only five exact domain keys appeared in both samples.
The three cleanest cross-rail examples show the unmatched inputs behind the comparison:
- Zapper: MPP returned a Base USDC market snapshot for $0.001165; x402 returned a small token-holder response for $0.001125.
- StableFinance: MPP returned a 13,498-item ticker catalog for $0.02004; x402 returned Apple segment financials for $0.02.
- StableStudio: MPP generated the illustration for the MPP field report for $0.04004; x402 sold a roughly five-minute upload credential for $0.01.
The seller, request, and returned object changed along with the payment rail.
Settlement needed an audit on both rails
MPP’s attributed per-attempt charges exceeded the observed run-level wallet decrease by $0.006773. The retained summary preserves that variance. Many Tempo receipts also showed a separate roughly $0.00004 network amount, so the all-in price could sit slightly above the merchant quote.
Every one of the 164 settled x402 ledger entries ultimately matched the quoted merchant amount. The runner received a transaction-specific receipt with 134 responses and recovered another 30 payments from Base USDC transfers. One authorization from the prior day settled about 39 hours late. A failed Wolfram Alpha call moved $0.02 and then refunded the full amount in the next block.
Whole-wallet balance movement was too ambiguous for attribution on both runs. A late payment can land during a later request, and a refund can reverse only part of the apparent spend. The durable record needs a request ID, quoted terms, transaction-specific receipt, response hash, refund reference, and delivery judgment.
Which one would I choose?
For a bounded, fixed-price API call from an unfamiliar seller, I would start with x402. The exact scheme maps cleanly onto one request, one authorization, one response, and one on-chain receipt. The Bazaar-style discovery surface also gave this sweep many small endpoints to sample.
For metered generation, streaming, reusable access, recurring plans, or a seller that already operates through Stripe, I would start with MPP. Its payment-method abstraction and session/subscription primitives fit relationships that continue beyond one response.
For a product serving autonomous buyers, I would consider supporting both. The client experience can converge behind one wrapper, and protocol allegiance is less valuable than meeting the buyer with a payment method it can actually authorize.
Then I would canary the exact endpoint before committing meaningful money. The two field reports found stale catalog entries, undocumented inputs, application errors inside HTTP 200 responses, payments without usable delivery, and results whose facts needed independent checking.
What neither protocol decided for the buyer
Neither protocol selected the right seller, decided whether the action was authorized, verified the truth of the result, or assigned responsibility when an intermediary failed.
A payment receipt answers a narrow question: did this payment flow complete? An optional signed delivery receipt can strengthen that evidence. The buyer still needs answers to five other questions:
- Was this the right provider for the task?
- Was the agent allowed to make this purchase or take the resulting action?
- Did the promised product arrive?
- Was the result correct and useful?
- Did the provider remain reliable over time?
That is why every purchased provider in these runs was reviewed. Repeat MPP purchases were consolidated into company reviews, while each settled x402 provider group kept its linked review. The protocol made access cheap. The retained outcome made the next decision better.
Read the complete field reports for 111 MPP attempts and 242 x402 provider-group attempts. Browse current offers in the MPP purchasing directory and x402 marketplace.