x402 vs. MPP

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

• Protocol shape: both use HTTP 402. x402 V2 defines dedicated payment requirement, payload, and settlement-response headers. MPP defines a Payment authentication scheme with challenge, credential, and receipt semantics.
• Headers: x402 uses PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE. MPP uses WWW-Authenticate: Payment, Authorization: Payment, and an optional Payment-Receipt on successful responses.
• Extensibility: x402 compatibility is expressed through scheme and network pairs. MPP separates payment methods from commercial intents such as charge and session.
• Payment patterns: x402 currently documents fixed exact, usage-capped upto, and batch-settlement schemes. MPP documents charge and metered session intents, plus subscriptions whose current availability varies by payment method.
• Merchant operations: Stripe’s MPP integration can connect machine payments to an existing Stripe balance and operational stack. x402 can use independent facilitators, self-facilitation, direct settlement, or later voucher redemption through batch-settlement. Stripe’s machine-payments stack also documents x402 acceptance (USDC on Base), so a seller’s processor choice does not force a protocol.
• 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.