x402 and MPP let software pay for web services, but clients need support for the chosen protocol and payment method. Compare the billing workflow, supported implementation and recovery path before choosing.
A fixed-price lookup and a metered browser session need different accounting. Neither the protocol name nor a stablecoin option tells you whether your merchant stack supports both.
Where the payment request appears
x402 uses HTTP 402 responses to communicate a resource's payment requirements. A compatible client supplies a payment payload, and the seller verifies and settles it under the selected scheme. V2 specifies payment-related headers for that exchange. x402 HTTP flow.
MPP also defines an HTTP payment challenge and a client response, with receipts documenting successful payment. Its design separates the requested payment intent from the payment method used to fulfill it. Machine Payments Protocol.
These common goals don't establish wire-level compatibility. A client and server must support the same protocol, version and method. A service advertising both needs to implement both correctly rather than assume one header can be renamed into the other.
An agent framework can support several payment clients. That is a product integration choice, with testing and maintenance costs. The agent still needs policy deciding which offers it may accept.
Choose a billing path before a protocol
A single paid request and an ongoing metered session need different authorization and accounting.
A protocol and a processor differ
The protocol describes how participants communicate. A merchant integration supplies a working way to verify a payment, move money and record it. Commercial fees, customer eligibility and operating support can depend on that integration.
Stripe co-authored MPP with Tempo and describes an integration through its PaymentIntents API. Its announcement includes stablecoin and fiat payment options, with Shared Payment Tokens used for supported conventional payment methods. Stripe MPP announcement.
x402 likewise supports different facilitator paths. A merchant can use a managed service, run its own facilitator or perform settlement functions within its server. Supported schemes and networks depend on the selected components. x402 facilitator paths.
This matters when comparing fees. A specification can be open while the convenient managed route charges for operating the service. A “gas-free” buyer experience can involve another party paying the network cost. The complete quote should identify those parties.
Sessions change the billing problem
A session lets a service maintain a commercial relationship across a sequence of interactions. That can suit streaming output, rented infrastructure or repeated tool use. The customer needs a spending ceiling, a way to stop usage and a record of accumulated charges.
MPP provides a session-oriented payment path in its documented method ecosystem. That shouldn't be generalized into every merchant implementation supporting every session feature. Method support needs checking at the client and server. MPP session documentation.
x402 isn't limited to one fixed charge for every HTTP call. Its current scheme set includes exact, up-to, batch settlement and auth-capture. A comparison that attributes aggregation only to MPP misses part of the current x402 design. x402 payment schemes.
The practical question is how your service meters work. Charging for one data item is easy to define. Charging for an open-ended research session requires rules for cancelled calls, unused budget and variable-cost operations.
Compare the customer's full purchase
| Question | x402 path | MPP path |
|---|---|---|
| How does the server request payment? | HTTP 402 with scheme and payment requirements | HTTP payment challenge with intent and method information |
| Which billing shapes should you inspect? | Exact, up-to, batch settlement and auth-capture support | One-time charges and method-specific sessions |
| Who performs payment operations? | Selected facilitator or server-side implementation | Selected payment method and service integration |
| Must the buyer use a particular chain? | Depends on accepted scheme/network pairs | Depends on the chosen method, not the MPP name alone |
| What needs additional product work? | Budget policy, delivery, discovery and receipts | Budget policy, delivery, discovery and receipts |
The table describes design questions as of October 13, 2026. It doesn't promise every SDK or processor supports every option. An integration review should pin the actual versions and supported routes.
For a fixed-price weather lookup, both routes need a clear offer and one recoverable purchase. For a browser rented by the minute, cancel the session early and inspect the final charge and unused authorization. That test exposes whether the integration supports the billing behavior the customer expects.
MPP also documents adapters for existing x402 services. Those can reduce integration work while retaining the underlying protocol distinctions; they don't make every client automatically compatible with every method. Using MPP with x402.
The failure cases decide the workload
Consider a payment authorization accepted just before a network timeout. The buyer doesn't know if the seller fulfilled the request. Retrying with a new payment can duplicate the charge; retrying without enough information can leave the job unresolved.
The integration needs a stable purchase identity and a reconciliation path. A protocol receipt can help describe the payment result, but the resource service still needs to associate it with the delivered work. x402 payment identifiers.
For a session, include a stalled client and a seller continuing to charge. The spending boundary should remain enforceable after the agent loses connectivity. “The agent will close the session” is a weak protection if the agent has crashed.
These are normal commercial operations, not exotic attacks. Testing them provides better evidence of readiness than counting successful requests in a clean demonstration.
A payment method doesn't judge the offer
An agent can spend successfully on a poor-quality dataset. It can buy the same answer from several services or accept a price higher than the task's value. The payment mechanism won't decide the purchase was wasteful.
That decision belongs to the agent's policy and service-selection process. The wallet article separates transaction limits from broader task budgets. The identity article examines the evidence an agent can use when judging another agent or service.
For merchants, predictable response quality and pricing can matter more than a tiny difference in payment overhead. The customer should be able to determine what it will receive before it pays. The seller guide focuses on that offer.
Choose the supported route, then compare
Write down the payment asset, method, billing unit and maximum exposure. Ask who submits settlement and how the seller records a failed delivery. Then test the path with the same constraints under both candidate integrations.
A merchant already using a payment platform may value its accounting and support. A service targeting stablecoin-native clients may prefer a different operating path. Neither preference makes the underlying protocol universally better.
The financial comparison is the next step. Our micropayment calculator shows how settlement frequency can change the result even when the customer pays the same price per request.
A useful compatibility test
Take one fixed-price endpoint and one metered session. For each candidate integration, record the client version, merchant version, accepted method, maximum authorization and cancellation behavior.
A client passing the fixed-price test has demonstrated that route. It has not demonstrated streaming, session closure or every method advertised by the protocol. Conversely, an adapter handling an x402 payment does not establish general compatibility with every x402 scheme. The supported intersection is the product you can deploy. MPP integration with x402.