MPP vs. x402: Which Machine-Payment Protocol Should You Use?

Here is the short answer

I kept seeing MPP described as Stripe’s answer to x402. That is not completely wrong, but it makes the decision sound simpler than it is.

If I were selling a one-cent API call, a file, a report, or access to a workflow, I would start with x402. The model is easy to understand: an agent asks for something, the server says what it costs, the agent pays, and the server delivers it.

MPP becomes more interesting when the business wants cards as well as stablecoins, already lives inside Stripe, or needs something beyond a single purchase—like a metered session or a subscription.

So yes, x402 often makes more sense for tiny payments. But MPP is not “the protocol for big payments.” Its real advantage is that it supports more ways to pay and more ways to structure the charge.

The simplest comparison I can make

Is x402 actually better for micropayments?

In most of the use cases I care about today, yes.

Imagine an agent needs one property record, one phone-number lookup, or one weather forecast. The seller does not need a customer account, a pricing page, or a monthly subscription. It needs a price attached to one request. That is exactly where x402 feels natural.

x402 also has batch settlement, which is designed for agents making thousands of very small purchases without settling every interaction separately onchain. That matters if the price drops below a cent or the volume gets very high.

MPP can still do small payments. Stripe documents a minimum of 0.01 USDC for stablecoin charges, and MPP sessions can meter usage below one cent before settling the accumulated amount. But if all I need is “pay one cent and get this JSON response,” x402 is the more obvious tool.

Where MPP starts to make more sense

MPP is more compelling when I stop thinking about one request and start thinking about the whole payment operation.

A business may want an agent to pay with a card because that is what the customer already has. It may want refunds, fiat settlement, fraud controls, reports, and reconciliation in the same Stripe account it already uses. It may want to bill for a session instead of putting a separate price on every request.

That is the strongest argument for MPP. Stripe and Tempo designed the protocol to support a one-time charge, a metered session, or a subscription. Stripe can then process the payment through its existing infrastructure.

A browser automation company is a good example. Charging separately for every browser action would be awkward. Opening a paid session, measuring the usage, and settling it afterward makes more sense.

The fee question is where this gets confusing

Both protocols can honestly say the protocol itself is open. That does not mean a real payment is free.

x402 advertises zero protocol fees. But somebody may still pay a blockchain network fee, a facilitator fee, a conversion fee, or the price of the product managing the integration. On a low-cost network, those charges can be small. They are still part of the economics.

MPP does not have one universal fee either. Stripe’s public documentation currently gives minimum payment amounts—$0.50 for cards and 0.01 USDC for stablecoins—but not one global MPP processing rate. The merchant’s country, account, payment method, and Stripe agreement determine the actual price. Another MPP provider could price it differently.

If I were evaluating either option, I would ignore the headline percentage for a moment and calculate what I actually keep on a $0.01, $0.10, $1, and $20 payment. Fixed fees and rounding can completely change the result at the low end.

Both protocols have serious companies behind them

x402 started at Coinbase, but it is no longer just a Coinbase project. The x402 Foundation now operates under the Linux Foundation. Its launch named 40 member organizations, including Coinbase, Cloudflare, Stripe, Visa, Mastercard, American Express, AWS, Google, Shopify, Circle, Adyen, Fiserv, Ripple, and the Solana and Stellar foundations.

MPP was co-authored by Stripe and Tempo. Stripe has a working implementation through PaymentIntents. Cloudflare documents MPP for Workers, HTTP services, MCP tools, and its Agents SDK. Solana also documents MPP payments.

The overlap is probably more important than the logos. Stripe is helping govern x402 while building MPP. Cloudflare supports MPP while playing a major role in x402. That tells me the market has not picked one winner, and the companies closest to it are preparing for more than one protocol to exist.

A few real decisions

A weather API sells a forecast for $0.01. I would choose x402. It is one resource, one price, and one immediate delivery.

A browser service charges for each minute an agent runs a session. I would take a serious look at MPP because the session model matches the product and Stripe can handle the merchant side.

A research company sells a $20 report. Either can work. If the buyers already use wallets, x402 may remain simpler. If the company wants card payments and Stripe settlement, MPP may be the better commercial choice.

A data platform charges a monthly base price plus usage. MPP maps more directly to that relationship. x402 could support it through extensions or a custom access model, but the team would be doing more design work.

What I would choose today

For an API, a workflow, a file, or a piece of content that an agent buys one request at a time, I would begin with x402. It is simpler, it is already built around the HTTP resource, and its discovery ecosystem is taking shape.

I would evaluate MPP when the business tells me it needs cards, Stripe, metered sessions, or subscriptions. I would not move to MPP just because a payment is worth $20 instead of twenty cents.

I also do not think this needs to become a winner-takes-all argument. Cloudflare says MPP clients can consume existing x402 services. The same business may eventually support both because different buyers arrive with different wallets and payment methods.

Why Access402 uses x402

I am building Access402 around a simple idea: a website or software company should be able to sell one useful thing to an agent without forcing that agent through an account, a sales form, or a subscription first.

That makes x402 the right starting point for Access402 today. It fits the resource-level transaction, while Access402 handles the less visible work around it: discovery metadata, payment verification, settlement records, and activity history.

Access402 does not currently implement MPP. If customers start asking for card-funded agent payments, metered sessions, or Stripe settlement, then MPP becomes a serious product decision. I would rather add it for a clear customer reason than pretend every protocol belongs in the product immediately.

Put this into practice

Continue from the problem to the implementation path that fits your resource.