If you've been researching x402, you've likely come across another acronym: MPP, the Machine Payments Protocol. They look similar on the surface — both use the HTTP 402 status code, both are designed for machine-to-machine payments, and both are being used in the emerging AI agent economy. But they're not the same thing, and the differences matter if you're deciding which to build on.
Both protocols start from the same premise: the existing web has no native way for software to pay for things autonomously. Both use the HTTP 402 response as the trigger — a server signals "payment required," a client pays, and the request is retried. Both are designed to work with stablecoins, and both are being actively developed in the open rather than sitting behind a single company's proprietary paywall.
x402's design philosophy is intentional minimalism. It specifies the payment handshake itself — the 402 response, the signed payment header, the 200 confirmation — and not much else. It's deliberately narrow: settlement is on-chain, in stablecoins (primarily USDC), with a specific payment scheme (called "exact") that authorises a fixed, predetermined amount. The simplicity is a feature. It's easy to implement, easy to audit, and easy to understand.
MPP extends this foundation in a few meaningful ways. It's designed to be payment-method-agnostic — meaning it's not locked to stablecoin-on-chain settlement and can, in principle, support fiat rails, card networks, or other mechanisms alongside crypto. It adds session-based billing (so a single authorisation can cover multiple requests within a session, rather than paying per request), MCP transport support for agent frameworks, and more formalised protocol primitives around idempotency and replay protection. MPP is also explicitly backwards-compatible with x402, meaning an MPP client can interact with an x402 server.
| x402 | MPP | |
|---|---|---|
| Payment methods | Stablecoins on-chain (USDC primary) | Payment-method agnostic, including fiat |
| Billing model | Per-request (exact scheme) | Per-request or session-based |
| Backwards compatible | N/A | Yes — MPP clients work with x402 servers |
| Maturity | Production-ready; V2 shipped Dec 2025 | Newer; still evolving |
| Governance | x402 Foundation (Linux Foundation) | Emerging standard, less formalised |
| Best fit | On-chain micropayments, API metering | Multi-rail, session-heavy, agent frameworks |
For most developers building today, x402 is the more pragmatic starting point — it has better documentation, more existing facilitator support, and a clearer production track record. The x402 Foundation's roster of members (Google, Visa, Stripe, Mastercard, AWS) suggests it's the protocol most of the industry is converging around at the specification level.
MPP is worth watching if you need session-level billing (charging for a conversation or a task rather than a single API call), or if you're building something that needs to support non-crypto payment methods alongside on-chain settlement. Its backwards compatibility with x402 means choosing MPP later doesn't require abandoning an x402 integration — which reduces the risk of picking one now.
The honest position is that both are early enough that "wait and see which wins" is a reasonable stance, particularly for businesses where neither is yet a material source of revenue. What isn't reasonable is ignoring both — agent-initiated payments are growing fast enough that having at least a working understanding of both puts you in a much better position when the adoption inflection point arrives.
Protocol details for both x402 and MPP are actively evolving. Verify current specifications directly with the x402 Foundation and relevant MPP documentation before making integration decisions.