HTTP/1.1 402 PAYMENT REQUIRED · x402 + MPP dual-stack 500+ tools · 12 rails · 0% seller fee

What is MPP?

MPP, the Machine Payments Protocol, is an open, IETF-track standard that lets software pay for web services per request through HTTP's native authentication headers. A paid endpoint answers with 402 Payment Required and a WWW-Authenticate: Payment challenge; the client answers with a signed stablecoin payment; the server verifies, settles on chain, and returns a signed receipt.

No accounts, no API keys, no subscriptions. For the broader story of why machine payments exist and how x402 fits alongside MPP, see What is x402?

ON THIS PAGE
01 / THE HANDSHAKE

How one MPP payment works.

Two HTTP round trips, typically a couple of seconds. Because it rides the standard WWW-Authenticate / Authorization machinery defined in RFC 9110 - the same one behind every login prompt on the web - payment becomes just another HTTP auth scheme.

01

The client requests a paid resource

A plain HTTP request, no credentials attached. The server answers 402 Payment Required with a WWW-Authenticate: Payment challenge naming the price, the asset, the chain, and a one-time challenge id.

02

The client signs and retries

It signs a payment authorization for exactly that amount with its own wallet key and repeats the identical request, carrying the signed credential in an Authorization: Payment header. The key never leaves the client.

03

The server verifies and settles

The credential is checked against the challenge, the payment settles on chain, and only then does the server run the request.

04

The response carries a receipt

A signed Payment-Receipt header returns with the result - a verifiable record that this exact payment bought this exact answer.

●on the wire
# 1. the client asks, without paying
POST /api/edgar-filing-text

# 2. the server quotes a price
HTTP/1.1 402 PAYMENT REQUIRED
WWW-Authenticate: Payment
  realm="agent402", amount="0.004",
  asset="USDC", network="base"

# 3. the client signs and retries
POST /api/edgar-filing-text
Authorization: Payment
  <signed authorization>

# 4. verified, settled, delivered
HTTP/1.1 200 OK
Payment-Receipt: 0x8f2a…c41d
{ "filing": "10-K", "text": "…" }
02 / COMPARISON

MPP vs x402, side by side.

Two dialects of the same idea: pay-per-request over HTTP 402, settled in stablecoins, no accounts. They differ in which headers carry the handshake, not in economics. A server can speak both from the same URL at the same price - that is how Agent402 runs today, one paywall, two wire formats. Settlement itself now branches: MPP's evm method still shares x402's exact settlement path, but Agent402 also speaks MPP's own tempo method natively - a genuinely separate settlement mechanism (Tempo's own relay), not a translation of the other two.

 x402MPP
Payment terms ride inPAYMENT-REQUIRED header (base64 JSON offer)WWW-Authenticate: Payment challenge
Payment rides inX-PAYMENT headerAuthorization: Payment header
Proof of settlementPAYMENT-RESPONSE headerSigned Payment-Receipt header
OriginCoinbase (x402.org)Tempo (paymentauth.org, IETF-track)
SettlementEIP-3009 stablecoin authorization, verified by a facilitatorDepends on the method: MPP's evm method settles identically (EIP-3009, same facilitator); its tempo method settles natively via Tempo's own relay - a different mechanism entirely, same price
03 / IS IT REAL?

Where MPP settles today.

Every paid endpoint on Agent402.Tools is dual-stack: the same 402 carries an x402 offer and an MPP challenge, a stock mppx client works unmodified, and a real purchase settles over the native MPP wire every day as part of the service's paid canary - so "MPP works here" is continuously re-proven on mainnet, not demonstrated once. Other x402 sellers have begun advertising MPP as an alternate rail as well.

Reference tooling: tempoxyz/mpp on GitHub. Spec: the Payment auth scheme at paymentauth.org.

04 / ACCEPT IT

How do I accept MPP payments on my own API?

If you already speak x402, a translation layer can add MPP without touching settlement: answer 402s with an additional WWW-Authenticate: Payment challenge derived from your existing offer, and re-encode inbound Authorization: Payment credentials into your existing verification path. Agent402's implementation of exactly that pattern is open source (AGPL) in its server repository, and the mppx tooling in tempoxyz/mpp provides the client and codec primitives.

SELL

List your API, both wires included

Serve x402, register your origin, and MPP dual-stack support ships free alongside it. No signup, nothing deducted from your price.

LIST YOUR API →
BUY

Pay in either dialect

An mppx client and an @x402/fetch client both work unmodified against every paid route on Agent402 - the buyer's client picks.

ADD TO CLAUDE →
05 / QUESTIONS

Questions people and agents ask.

What is the Machine Payments Protocol (MPP)?

MPP is an open, IETF-track protocol that lets software pay for web services per request using HTTP's standard authentication mechanism. A paid endpoint answers an unpaid request with status 402 and a WWW-Authenticate: Payment challenge naming a price; the client answers with a signed stablecoin payment in an Authorization: Payment header; the server verifies it, settles on-chain, and returns the result with a signed Payment-Receipt header. No account, API key, or subscription is involved.

How is MPP different from x402?

They are two dialects of the same idea - pay-per-request over HTTP 402, settled in stablecoins. x402 (from Coinbase) carries payment terms in a PAYMENT-REQUIRED header and the payment in an X-PAYMENT header; MPP carries the same handshake through the web's standard auth headers (WWW-Authenticate / Authorization, the mechanism defined in RFC 9110), which makes it a natural fit for the IETF standards track. A server can speak both from the same URL at the same price, and dual-stack servers exist today.

Is MPP a finished standard?

It is IETF-track and in active development - the Payment HTTP authentication scheme is documented at paymentauth.org with the reference implementation in the tempoxyz/mpp repository. Live services accept MPP payments on mainnet today, so the wire format is real and settling, but as with any draft-stage protocol, details can still evolve.

Where can I see MPP working right now?

Every paid endpoint on Agent402.Tools is dual-stack: the same 402 response carries both an x402 offer and a WWW-Authenticate: Payment challenge, a stock mppx client works unmodified, and settled responses return a signed Payment-Receipt. A real purchase settles over the native MPP wire daily as part of the service's paid canary, so the claim is continuously re-proven, not a demo that worked once.

How do I accept MPP payments on my own API?

If you already speak x402, a translation layer can add MPP without touching settlement: answer 402s with an additional WWW-Authenticate: Payment challenge derived from your existing offer, and re-encode inbound Authorization: Payment credentials into your existing verification path. Agent402's implementation of exactly that pattern is open source (AGPL) in its server repository, and the mppx tooling in tempoxyz/mpp provides the client and codec primitives.

402

Now put it to work.

Agent402 speaks x402 and MPP on the same routes at the same price. Free to list, free to browse.

LIST YOUR API - FREE → WHAT IS x402?