create account

Protocol comparison

x402 vs. MPP

A neutral comparison of x402 and the Machine Payments Protocol (MPP): request flow, payment methods, settlement, use cases, and trade-offs.

11 min readBy Patrick BarattinReviewed
x402HTTP 402scheme + network pairs
shared outcomePay for a machine-readable resourcechallenge · authorize · retry · receive
MPPHTTP authpayment-method agnostic

TL;DR

x402 and MPP both use HTTP 402 to let machines pay for resources, but their wire formats differ. x402 V2 uses dedicated PAYMENT-* headers and registered scheme/network pairs. MPP maps Challenge, Credential, and Receipt semantics into HTTP authentication, with separate payment-method and intent specifications.

What to remember

  • Both protocols can keep a manual checkout out of the critical request path.
  • The correct choice depends on buyer wallets, seller settlement, payment patterns, and ecosystem support.
  • A protocol-agnostic application layer reduces the cost of choosing too early.

What x402 and MPP have in common

Both protocols start from the same problem: conventional payments and API onboarding were designed for humans. They let a service express payment requirements in an HTTP interaction and let a machine respond programmatically.

Both can support pay-per-use APIs and agent tools. Both still require the buyer to control authorization and the seller to enforce resource access. Neither protocol replaces discovery, ranking, budgeting, observability, or outcome evaluation.

The practical differences

x402 and MPP compared across protocol shape, headers, extensibility, payment patterns, and merchant operations.
x402MPP
Protocol shapeHTTP 402 with dedicated payment requirement, payload, and settlement-response headers (V2).HTTP 402 with a Payment authentication scheme carrying challenge, credential, and receipt semantics.
HeadersPAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE.WWW-Authenticate: Payment, Authorization: Payment, and an optional Payment-Receipt on success.
ExtensibilityCompatibility expressed through registered scheme and network pairs.Payment methods kept separate from commercial intents such as charge and session.
Payment patternsFixed exact, usage-capped upto, and batch-settlement schemes.Charge and metered session intents, plus subscriptions whose availability varies by payment method.
Merchant operationsIndependent facilitators, self-facilitation, direct settlement, or later voucher redemption through batch-settlement.Stripe’s MPP integration can connect machine payments to an existing Stripe balance and operational stack.
  • A processor choice does not force a protocol: Stripe’s machine-payments stack also documents x402 acceptance (USDC on Base).
  • Ecosystem: SDK, wallet, facilitator, processor, network, and provider support are moving quickly for both protocols. Current compatibility matters more than abstract elegance.

A decision framework

  1. 01

    Start with the buyer

    What wallets, credentials, networks, and approval model can the agent actually use?

  2. 02

    Model the commercial pattern

    Is this one request, a metered session, a recurring relationship, or streaming usage?

  3. 03

    Choose the seller’s settlement

    Does the provider want direct onchain settlement, a processor balance, fiat payout, or several options?

  4. 04

    Check operational support

    Compare SDK maturity, facilitators, refunds, observability, idempotency, and reconciliation.

  5. 05

    Preserve an abstraction boundary

    Keep capability search and policy independent from protocol-specific challenge handling.

Why Weft stays protocol-agnostic

Agents care about completing the task under the right constraints. They should not have to begin with a rail. Weft’s market layer can rank a service by capability, price, latency, and reliability, then use a compatible payment path under the team’s policy.

Protocol diversity is useful while the market is young. It creates pressure for better developer experience, wider payment support, and lower cost. The durable layer is the one that can understand what is being bought and observe whether the purchase produced value across those rails.

Sources and further reading

Protocols change quickly. We reviewed the primary sources below on July 23, 2026.

  1. x402 V2 HTTP headersx402 Foundation ↗
  2. x402 payment schemesx402 Foundation ↗
  3. MPPMachine Payments Protocol ↗
  4. MPP subscriptions and payment patternsMachine Payments Protocol ↗
  5. Introducing the Machine Payments ProtocolStripe ↗
  6. Machine payments protocol and network supportStripe Documentation ↗
  7. Payment HTTP authentication Internet-Draftpaymentauth.org ↗