x402 vs MPP: How AI Agents Actually Pay on the Web

If you build agents that buy data, tools, or compute without a human opening a vendor portal, you eventually hit the same wall: how does the machine pay?

In 2026 the serious answers cluster around two HTTP-native protocols:

x402 — revive 402 Payment Required as a stateless, per-request challenge; settle with stablecoins (often on Solana or other L1/L2 rails)
MPP (Machine Payments Protocol) — Stripe × Tempo’s open protocol for machine payments over HTTP, with session-friendly credentials and multiple method types

They are not the same product with different logos. They optimise for different failure modes. This post is a builder comparison — including how we run both on Milypay.

For the pure x402 primer, start with x402 on Solana. For the product we shipped on it: Milypay case study.

The shared idea

Both protocols reuse a status code the web reserved in the 1990s and mostly ignored:

HTTP 402 — Payment Required.

The server does not invent a proprietary “buy credits” UI. It answers the request with a structured challenge: what to pay, how, and how to prove payment on the retry. The client (human app or agent) pays, attaches proof, and gets the resource.

That is the whole pitch. The fork is what happens inside the challenge.

x402 in one paragraph

x402 treats each paid HTTP call as its own economic event.

Agent GETs a resource
Server returns 402 + payment requirements (asset, amount, network, pay-to, scheme)
Agent signs a stablecoin transfer (or facilitator-assisted flow)
Agent retries with a payment proof header (commonly PAYMENT-SIGNATURE / X-PAYMENT)
Server verifies and unlocks the body — often with a machine-readable receipt

There is no mandatory long-lived session. Discoverability can sit in manifests and well-known endpoints. Facilitators (for example PayAI-class infrastructure) can help verify and settle without every merchant running a full chain indexer.

Best fit: pay-per-call APIs, data feeds, one-shot tools, agent-to-agent micropayments, open multi-chain catalogs.

Trade-off: naive “one on-chain tx per request” at extreme QPS gets expensive and chatty unless you batch, cache, or design prices accordingly. Solana keeps the fee floor low enough that sub-cent calls are realistic — which is why we built Milypay there first.

MPP in one paragraph

MPP also starts from HTTP 402, but leans on the HTTP authentication framework: challenges and credentials travel in WWW-Authenticate / Authorization (Payment scheme), with problem+json bodies and a clearer path to sessions, spending limits, and multiple payment methods (stablecoins, cards via Shared Payment Tokens, Lightning, custom rails — depending on the stack).

Stripe’s machine-payments docs and Tempo’s MPP work position it as coordination for agents and services: challenge → credential → receipt, extensible methods, enterprise-shaped reporting when you want Stripe in the loop. Solana has also been called out as an MPP-capable network for USDC in Stripe’s tables; Tempo is the native home for much of the early MPP energy.

Best fit: high-frequency agent sessions, hybrid fiat + crypto, teams that want Stripe-class ops (fraud, tax, receipts) without rebuilding them, APIs that prefer authorize-once then stream usage.

Trade-off: more moving parts than “sign this transfer and retry.” You inherit method-specific constraints (which chain, which currency, which wallet stack). It is open as a protocol, but many happy paths will feel Stripe/Tempo-shaped in practice.

Side-by-side

	x402	MPP
Incubation	Coinbase-origin open protocol; wide facilitator ecosystem	Stripe × Tempo design; open MPP specs at mpp.dev
HTTP shape	402 + payment-required payload / headers	402 + WWW-Authenticate Payment / Authorization Payment headers
Default mental model	Stateless per request	Challenge/credential; sessions and intents
Money	Stablecoins on supported chains (Solana-strong in our stack)	Stablecoins, cards (SPT), Lightning, custom — method-dependent
Autonomy	Excellent for fully agentic, no-account loops	Excellent when pre-auth + method breadth matter
Ops / compliance story	You own more of the stack	Stripe path available when you want it
Milypay today	Default Solana rail	Opt-in Tempo charge via `?rail=mpp`

The internet does not need a single winner. APIs can speak more than one challenge language — the same way servers speak Bearer and cookies.

Wrong comparisons we keep seeing

“MPP replaces x402”

No. Replacing a permissionless per-request rail with a session-and-method framework is a product choice, not an upgrade path. If your agent discovers a random AU data endpoint at runtime, x402’s simplicity still wins. If your agent runs a long research job against one vendor with a spend cap, MPP’s session shape wins.

“x402 is crypto-only cosplay”

Stablecoin settlement is the point for machine micropayments without card networks in the hot path. That is not cosplay when the alternative is API keys and monthly minimums for a $0.002 lookup.

“MPP is just Stripe Checkout for bots”

The protocol is broader than one vendor UI. Stripe is a major implementation and commercial surface. Builders should read the open MPP docs and method types — then decide how much of Stripe they want.

How Milypay runs both

Milypay sells Australian data to agents: ABN/ASIC, address, BSB, energy, and more. Settlement is AUD-native where we can (AUDD, AUDM, dAUD) plus USDC/USDT for catalog compatibility.

Default rail — Solana x402

GET https://api.milypay.xyz/au-business/abn/51824753556
→ 402 + PAYMENT-REQUIRED (Solana stables)

No API key. Payment is the credential. Demo traffic stays on milypay.xyz/api/*.

Opt-in rail — Tempo MPP

GET https://api.milypay.xyz/au-business/abn/51824753556?rail=mpp
→ 402 + WWW-Authenticate: Payment (method=tempo, intent=charge)

Clients can also signal MPP via X-Payment-Rail: mpp or a Payment credential on Authorization. MPP does not steal default Solana agents — bare GETs stay on x402 so existing CLI/MCP/SDK flows keep working.

What is not claimed: full “x402-on-Tempo” facilitator settlement for eip155:4217 as the default path until facilitators list and settle that network the way Solana is settled today. Dual-rail means x402 on Solana + MPP charge on Tempo, not “every logo on every chain.”

Live product surface: milypay.xyz · status and agent docs on the same host.

Choosing a rail (short decision guide)

Prefer x402 when:

Price is per call and small
Agents must pay without accounts or KYC theatre in the hot path
You want open facilitators and multi-client ecosystems (CLI, MCP, raw HTTP)
Solana (or another cheap finality chain) matches your fee budget

Prefer MPP when:

You want session spend limits and fewer round-trips per tiny call
Card or hybrid methods matter
Your stack already speaks Tempo/Stripe machine payments
Enterprise reporting and method extensibility beat minimal headers

Prefer both when:

You run a public API for heterogeneous agents (you do)
You refuse to strand clients on one ecosystem fad
You can gate the second rail behind an explicit signal (rail=mpp) so defaults stay stable

Australia angle

Domestic agent products still trip on USD mental models. Whether the challenge is x402 or MPP, the unit of account should match the domain when liquidity allows — AUD stables for Australian data and local ops. See why Australia needs its own stablecoin and the 2026 builders guide.

Protocols move value. They do not replace FX, AFSL, or “who is the merchant of record.” Design the money story on purpose.

Work with us

Milysec designs and ships agent payment rails and Australian onchain products. If you need x402, MPP, or a dual-rail API in production — not a slide — contact the studio or try the live API at milypay.xyz.