What is the difference between x402 and MPP?
x402 and MPP both use an HTTP 402 challenge pattern for programmatic payments. x402 is an open protocol built around signed onchain payment payloads and facilitator-based verification or settlement. MPP is an open protocol co-authored by Stripe and Tempo that defines payment challenges, credentials, and receipts across supported payment methods.
Neither protocol is automatically right for every business. Begin with the Agent Business Readiness Scan, then use Agent Merchant Activation if you need a scoped implementation and test purchase.
x402 vs MPP at a glance
| Question | x402 | MPP |
|---|---|---|
| Core request pattern | HTTP request, 402 requirements, signed payment retry, verification and settlement | HTTP request, 402 challenge, payment credential retry, verification and receipt |
| Primary current payment model | Onchain token payment using supported schemes and networks | Method framework that can support Stripe Shared Payment Tokens and stablecoins |
| Buyer prerequisite | Compatible wallet or signer with the supported asset and network | Credential supported by the merchant’s selected MPP method |
| Seller infrastructure | x402 middleware plus local verification or a facilitator | MPP implementation plus a supported payment method or processor adapter |
| Settlement | Onchain to the seller’s chosen address or provider-supported destination | Depends on the selected method and processor integration |
| Natural fit | Paid APIs, data, content, and small deterministic resources with onchain buyers | Paid APIs and services where the seller wants MPP credentials, receipts, or Stripe-centered processing |
| Main diligence point | Wallet, asset, network, facilitator, refund, and accounting design | Method availability, processor status, challenge binding, receipt, and refund design |
This table describes the current protocol designs, not a guarantee of account eligibility, network availability, or commercial fit.
How does x402 work?
In x402, a client requests a paid resource. The server returns 402 Payment Required with payment requirements. The client creates a signed payment payload and retries. The server or facilitator verifies the payload, settles it when required, and returns the resource with a payment response. (Coinbase Developer Platform, x402 overview)
x402 version 2 standardizes headers including PAYMENT-REQUIRED, PAYMENT-SIGNATURE, and PAYMENT-RESPONSE. New implementations should use the current specification and SDK versions rather than copying a version 1 example. (x402 version 2 specification)
x402 is most straightforward when buyers already have a compatible wallet or signer and the seller is prepared to receive and account for the supported onchain asset. A facilitator can reduce verification and settlement infrastructure, but the seller still owns pricing, delivery, refund, sanctions, accounting, and support decisions.
How does MPP work?
MPP also begins with an unpaid resource request and an HTTP 402 response. The challenge describes the available payment methods and binds the payment request to the resource. The client retries with a compatible credential. The server verifies the credential, records or settles the payment through the selected method, and returns the resource with a receipt.
Stripe’s current MPP documentation describes an integration that can accept Shared Payment Tokens and stablecoins, with payment recorded through Stripe. MPP is co-authored by Stripe and Tempo, while the protocol specification lives at MPP’s own site. (Stripe, MPP; Machine Payments Protocol)
MPP’s broader credential model can be useful when a merchant wants more than one supported payment method. The actual methods, processor features, preview versions, and geographic availability must be checked at implementation time.
When is x402 a practical fit?
x402 is a plausible fit when all of the following are true:
- the product is a deterministic API, data response, content unit, or tool call;
- the buyer population can use a supported wallet, asset, and network;
- the seller can price and deliver the resource synchronously;
- payment verification happens before valuable output is returned;
- the seller has a clear refund, duplicate-payment, reconciliation, and support process;
- the team is comfortable with onchain settlement or a provider-supported settlement path.
It is usually a poor first fit for LLC formation, government pass-through fees, bespoke documents, or other high-touch work that begins only after identity review and may cross irreversible milestones.
When is MPP a practical fit?
MPP is a plausible fit when:
- the product is programmatically deliverable;
- target buyers use a supported MPP credential;
- the seller wants the current processor or method adapters available in its stack;
- receipt and challenge semantics fit the fulfillment design;
- the team has confirmed current preview access, versions, payment methods, and settlement behavior.
If the only buyer is a conventional web customer, a normal Stripe Checkout or invoice may be simpler. Protocol adoption should follow real buyer demand, not the novelty of returning status code 402.
What must both implementations get right?
Regardless of protocol, the seller needs:
- an exact product or resource identifier;
- a server-authoritative amount and currency or asset;
- validation before charge;
- replay and duplicate-payment protection;
- delivery only after valid payment evidence;
- an output contract and error taxonomy;
- a receipt tied to the request and delivered result;
- settlement reconciliation;
- a refund and dispute boundary;
- monitoring, incident response, and a disable control.
Test a successful purchase, an underpayment, a wrong asset or method, an expired challenge, a duplicate retry, a delivery failure after payment, and a disabled route. A single happy-path demo is not enough.
How should a seller decide?
Write down the actual buyer, credential, resource, amount, settlement destination, refund requirement, and accounting treatment. Then implement the smallest compatible path and run a low-value end-to-end purchase.
The readiness scan can identify missing organization, authority, provider, and merchant prerequisites. Agent Merchant Activation can scope protocol selection, conformance, test-purchase evidence, and the operating runbook.
Last updated August 2026. Protocol versions, processor availability, supported networks, methods, and pricing can change. Confirm current primary documentation before production use. This is not legal, tax, financial, or security advice.
Primary sources:
