x402 vs MPP: an operational guide
Published . Protocol claims checked against official specifications and provider documentation.
Short answer: choose x402 or MPP by payment method, pricing shape and infrastructure, not by acronym. Both use HTTP 402 to turn an unpaid request into a payment challenge. x402 has an established stablecoin-oriented implementation ecosystem and a compact request-payment-retry flow. MPP defines HTTP authentication semantics, receipts and multiple intents, including one-time charges, metered sessions and subscriptions. Stripe's MPP implementation accepts cards through Shared Payment Tokens and stablecoins; its x402 implementation is stablecoin-based. AWS AgentCore Payments supports both. Those provider capabilities do not define the full limits of either open protocol.
The common flow
Both protocols start with the same useful idea. A client requests a paid resource. The server answers with 402 Payment Required and terms. The client obtains or creates payment proof, retries the request, and receives the resource after verification.
The important differences start after that outline. MPP uses HTTP authentication fields: a challenge in WWW-Authenticate: Payment, a credential in Authorization: Payment, and an optional Payment-Receipt. x402 defines its own payment-requirements and payment-payload representations and delegates verification and settlement to a facilitator in common implementations.
Operational comparison
| Decision | x402 | MPP |
|---|---|---|
| Core job | Pay for a protected request using x402 payment requirements and proof | Authenticate machine payments over HTTP with extensible methods and intents |
| Pricing shape | Commonly exact per request; AWS also documents an “upto” ceiling | Charge, metered session and subscription intents are documented |
| Payment methods | Depends on scheme, network and facilitator; Coinbase documentation focuses on stablecoins | Protocol is method-agnostic; official docs list Tempo and Stripe methods as production |
| Card path | Not a general property of the protocol | Stripe documents cards through Shared Payment Tokens in its MPP implementation |
| Stablecoin path | Documented across x402 implementations and facilitators | Stripe documents MPP stablecoins on Tempo and Solana |
| Repeated usage | Scheme-specific; “upto” can cap dynamic usage in AWS | Session intent explicitly models reusable state and metered updates |
| Receipt | Defined by the x402 flow and implementation | Payment-Receipt is part of the HTTP authentication model |
| Retry safety | Implementation must prevent replay and duplicates | Spec requires single-use proofs and recommends Idempotency-Key for non-idempotent methods |
Choose x402 when
- your current buyer or agent ecosystem already speaks x402;
- the resource maps cleanly to a paid HTTP request;
- the supported scheme, currency, network and facilitator match your settlement policy;
- you have validated the exact or bounded-usage path your clients implement.
A protocol name is not enough. Confirm the version, scheme, asset, network, facilitator, finality rules and receipt behavior. The x402 infrastructure review covers the surrounding ecosystem.
Choose MPP when
- you need one HTTP payment framework across more than one payment method;
- you need metered sessions for tokens, compute, streams or repeated tool calls;
- you want the challenge, credential, receipt and failure model expressed through HTTP authentication;
- your payment provider offers a supported MPP method in the countries and currencies you need.
MPP's session intent is not a promise that every method supports every session feature. Method specifications define how funding, updates, verification and settlement work on the underlying rail.
Support both when the client population requires it
AWS is current evidence that one orchestration layer can support both protocols. Its AgentCore Payments service launched x402 support in preview and added MPP at general availability on 18 August 2026. That proves coexistence in one named product. It does not prove universal interoperability between arbitrary x402 and MPP implementations.
A dual-protocol endpoint still needs an explicit offer and test matrix:
- protocol and version;
- payment method, scheme or intent;
- currency, asset and network;
- minimum, maximum and rounding behavior;
- challenge lifetime and replay protection;
- idempotency and duplicate-payment handling;
- receipt, refund and reconciliation identifiers;
- regional availability and provider approval.
Failure handling matters more than the happy path
The MPP documentation gives precise failure semantics: malformed, expired, already-used or unverifiable credentials receive a fresh 402 challenge and a problem detail. A valid payment that is denied by access policy receives 403. It also requires single-use proof semantics and tells servers not to perform unpaid side effects.
Apply the same discipline to any x402 implementation. A retry after a network timeout must not settle twice. A successful payment followed by a delivery failure needs a recoverable receipt and a defined compensation path. Payment credentials must not enter logs, prompts or analytics.
What the current documentation does not tell us
No primary source reviewed for this guide provides a comparable, independent success rate, cost curve or merchant count for the two protocols. Provider availability differs by country, payment method and account approval. A production choice therefore needs a controlled test with the intended client and provider, not a market-share claim.
For controls that apply whichever protocol you choose, use the agentic payment controls guide and the merchant payment overview.