# MPP vs. x402: What Happened When I Used Both

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.

<figure class="protocol-common-flow" aria-labelledby="protocol-common-flow-caption">
  <div class="protocol-common-flow-track" role="img" aria-label="The common machine-payment flow: request a resource, receive a 402 challenge, authorize payment, retry the request, and receive the resource with a receipt.">
    <section><b>1</b><strong>Request</strong><span>Ask for the resource</span></section>
    <i aria-hidden="true">→</i>
    <section><b>2</b><strong>Challenge</strong><span>Read price and terms</span></section>
    <i aria-hidden="true">→</i>
    <section><b>3</b><strong>Authorize</strong><span>Approve bounded payment</span></section>
    <i aria-hidden="true">→</i>
    <section><b>4</b><strong>Retry</strong><span>Attach payment proof</span></section>
    <i aria-hidden="true">→</i>
    <section><b>5</b><strong>Receive</strong><span>Keep result and receipt</span></section>
  </div>
  <figcaption id="protocol-common-flow-caption">The shared choreography. A normal HTTP request becomes a quote, authorization, paid retry, and response.</figcaption>
</figure>

The wire formats differ. [MPP’s HTTP transport](https://mpp.dev/protocol/transports/http) uses `WWW-Authenticate: Payment` for the challenge, `Authorization: Payment` for the credential, and `Payment-Receipt` for the receipt. [x402 v2](https://docs.x402.org/core-concepts/http-402) 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](https://mpp.dev/guides/one-time-payments), [usage-based sessions](https://mpp.dev/guides/pay-as-you-go), [subscriptions](https://mpp.dev/guides/subscription-payments), and [multiple methods on one endpoint](https://mpp.dev/guides/multiple-payment-methods), 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`](https://docs.x402.org/getting-started/quickstart-for-sellers): 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](https://docs.x402.org/core-concepts/network-and-token-support), 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](https://mpp.dev/blog/evm-x402-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.

<figure class="protocol-run-scope" aria-labelledby="protocol-run-scope-caption">
  <div class="protocol-run-scope-grid" role="img" aria-label="The MPP field run used direct USDC.e on Tempo on July 19, 2026. The x402 field run used USDC on Base on July 27, 2026.">
    <section>
      <h3>MPP field run</h3>
      <div><span>Protocol</span><strong>MPP charge + session</strong></div>
      <div><span>Settlement</span><strong>Tempo · USDC.e</strong></div>
      <div><span>Date</span><strong>July 19, 2026</strong></div>
    </section>
    <section>
      <h3>x402 field run</h3>
      <div><span>Protocol</span><strong>x402 exact-style calls</strong></div>
      <div><span>Settlement</span><strong>Base · USDC</strong></div>
      <div><span>Date</span><strong>July 27, 2026</strong></div>
    </section>
  </div>
  <figcaption id="protocol-run-scope-caption">The comparison covers two concrete routes through the protocols. Their other payment methods and networks sit outside the tested scope.</figcaption>
</figure>

## The numbers looked similar until I examined the denominators

<figure class="protocol-field-runs" aria-labelledby="protocol-field-runs-caption">
  <div class="protocol-field-runs-grid">
    <section>
      <h3>MPP over Tempo</h3>
      <div class="protocol-field-run-total"><strong>111</strong><span>recorded attempts</span></div>
      <dl>
        <div><dt>Useful calls</dt><dd>69</dd></div>
        <div><dt>Companies delivered</dt><dd>67</dd></div>
        <div><dt>Spend</dt><dd>$2.360092</dd></div>
        <div><dt>Median success</dt><dd>1.795s</dd></div>
        <div><dt>Saved responses</dt><dd>1.49 MB</dd></div>
      </dl>
    </section>
    <section>
      <h3>x402 over Base</h3>
      <div class="protocol-field-run-total"><strong>242</strong><span>provider-group attempts</span></div>
      <dl>
        <div><dt>Useful paid calls</dt><dd>149</dd></div>
        <div><dt>Settled calls</dt><dd>164</dd></div>
        <div><dt>Net spend</dt><dd>$1.400875</dd></div>
        <div><dt>Median settled call</dt><dd>7.09s</dd></div>
        <div><dt>Paid responses</dt><dd>1.12 MB</dd></div>
      </dl>
    </section>
  </div>
  <figcaption id="protocol-field-runs-caption">The observed runs side by side. MPP’s attempt count includes 16 safety skips or exclusions; x402 safety-filtered candidates before the 242 calls. Prices and products also differed.</figcaption>
</figure>

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.

<figure class="protocol-overlap" aria-labelledby="protocol-overlap-caption">
  <div class="protocol-overlap-track" role="img" aria-label="Across the two local samples, 89 provider domains appeared only in the MPP sample, 5 appeared in both, and 237 appeared only in the x402 sample.">
    <section><strong>89</strong><span>MPP-sample only</span></section>
    <section><strong>5</strong><span>shared domains</span></section>
    <section><strong>237</strong><span>x402-sample only</span></section>
  </div>
  <figcaption id="protocol-overlap-caption">Overlap between 94 MPP-eligible company keys and 242 attempted x402 provider keys. A shared domain could still serve a different product.</figcaption>
</figure>

The three cleanest cross-rail examples show the unmatched inputs behind the comparison:

- **Zapper:** MPP returned a Base USDC market snapshot for [$0.001165](/r/5c284df2-0598-4527-badf-91d7abf2ed4b); x402 returned a small token-holder response for [$0.001125](/r/f95e2309-411d-40af-b38e-b1da99792e12).
- **StableFinance:** MPP returned a 13,498-item ticker catalog for [$0.02004](/r/7165c6b2-b8da-415a-a21e-9a090e5e7e0b); x402 returned Apple segment financials for [$0.02](/r/ad52848b-0afc-4a2c-8158-450f3fead0c5).
- **StableStudio:** MPP generated the illustration for the MPP field report for [$0.04004](/r/a3326758-3dbf-4677-baef-838e4ce3bd5b); x402 sold a roughly five-minute upload credential for [$0.01](/r/2a78b8d1-82b0-410e-9f49-f773e3d41718).

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:

1. Was this the right provider for the task?
2. Was the agent allowed to make this purchase or take the resulting action?
3. Did the promised product arrive?
4. Was the result correct and useful?
5. 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](/blog/100-machine-payment-purchases) and [242 x402 provider-group attempts](/blog/paying-for-x402-apis). Browse current offers in the [MPP purchasing directory](/mpp) and [x402 marketplace](/marketplace).