Forem: Ihor

x402 upto vs MPP Sessions: Two Philosophies of Usage-Based Payments

Ihor — Mon, 13 Apr 2026 16:29:10 +0000

A deep comparison of x402 upto and MPP Sessions: how they handle variable-cost payments, micropayment streaming, escrow vs allowance models, and when to choose each architecture for machine-to-machine payments.

TL;DR

x402 upto and MPP Sessions (I use Tempo Session here as example) solve the same practical problem: how to charge a client exactly for what they actually consumed when the final cost is unknown in advance, while also reducing the number of transactions. But they solve it at different abstraction layers and with fundamentally different settlement architectures.

x402 upto is an “open check” with a maximum amount. The client signs a one-time authorization to charge up to X. The server delivers the service, calculates the actual cost, and performs one on-chain transaction for the real amount. This model lives entirely inside a single HTTP request-response cycle, uses Permit2, and requires no escrow.
MPP Tempo Sessions is a payment channel (state channel). The client deposits funds into an on-chain escrow contract, then exchanges off-chain EIP-712 “vouchers” with the server, each representing a cumulative amount. The channel stays alive for a long time, can contain unlimited micropayments, and requires exactly two on-chain transactions for all of them: opening and closing.

Simplified:

x402 upto = one HTTP request with an unknown final price.

MPP Sessions = a long-lived streaming connection where payments flow in sync with data.

Session Lifecycle

x402 `upto`

The upto scheme exists within a normal HTTP request-response cycle extended with HTTP 402 status.

Lifecycle:

Challenge. The client makes a request, and the server responds with 402 Payment Required containing PaymentRequirements, specifying scheme: "upto", recipient address, token, network, maximum timeout, and most importantly amount — the upper limit the server wants authorization for.
Signature. The client creates a Permit2 permitWitnessTransferFrom message where permitted.amount equals the maximum requested amount, witness.to is the recipient address, witness.facilitator is the facilitator address (published by the server via /supported), and sets deadline and validAfter. Then signs it with EIP-712.
Paid request. The client repeats the HTTP request, attaching PAYMENT-SIGNATURE with the payload (signature + Permit2 authorization parameters).
Verification. The facilitator verifies the signature, Permit2 allowance, client balance, signature validity window, and token/network consistency. No funds move at this stage.
Service execution. The server processes the request (generates tokens, returns a file, runs computation) and calculates the actual final cost.
Settlement. The server sends PaymentRequirements to the facilitator again, now with the actual amount (this is the key feature of the scheme: the same field means different things in different phases — maximum during verification, actual charge during settlement). The facilitator calls x402UptoPermit2Proxy.settle(...) using the real amount, which must be ≤ the signed maximum. If the actual amount is zero, no on-chain transaction happens at all — the authorization simply expires unused.

One signature = one settlement.

upto explicitly forbids multi-settlement and streaming: the same signature cannot be reused because of Permit2 nonce semantics. If another charge is needed, a new signature is required — meaning a new HTTP request.

MPP Tempo Sessions

A Tempo session is a full protocol with a dedicated on-chain TempoStreamChannel contract and multiple states.

Lifecycle:

Challenge. The server returns 402 with WWW-Authenticate: Payment method="tempo" intent="session". It includes price per unit of consumption (amount + unitType, e.g. 25 base units per llm_token), recommended deposit (suggestedDeposit), escrow contract address, and optionally channelId if the server proposes reusing an existing channel.
Open. The client sends an on-chain transaction open(payee, token, deposit, salt, authorizedSigner). The contract creates a channel with deterministic channelId = keccak256(payer, payee, token, salt, authorizedSigner, contract, chainId) and locks the deposit. The client sends the signed transaction to the server together with action="open" and an initial voucher with cumulativeAmount = 0.
Streaming + vouchers. The server begins streaming content (typically SSE or chunked). As consumption grows, the client signs EIP-712 vouchers with monotonically increasing cumulative amounts: 100 → 250 → 400 → .... Vouchers are sent over the same HTTP URI (often via HEAD requests), with no separate control plane. Each voucher is only a few hundred bytes and verifies in microseconds.
Top-up (optional). If the session lasts longer than expected and deposit runs low, the client can call on-chain topUp() and continue without closing the channel. Tempo even defines an SSE event payment-need-voucher to notify the client that balance is exhausted.
Settle (optional, many times). The server may call settle(channelId, cumulativeAmount, signature) at any time to withdraw already earned funds without closing the channel. This is a major difference from upto: partial on-chain settlements during a live session are allowed.
Cooperative close. The client sends action="close" with the final voucher. The server calls close(), and the contract transfers the delta (cumulativeAmount - already_settled) to the payee, refunds the remainder to the payer, and finalizes the channel.
Forced close (client protection). If the server becomes silent and does not close the channel, the client calls requestClose(), waits through a grace period (15 minutes in the reference implementation), then calls withdraw() to reclaim remaining funds. The server has a window to submit the final voucher.

Key detail: vouchers are cumulative. This means the client does not need to track history — it simply signs “total owed so far is X.” Once the server receives a newer voucher, all previous ones can be discarded. During settlement, the contract computes delta as cumulativeAmount - channel.settled, naturally preventing replay and double-spending.

Table of Key Differences

Parameter	x402 `upto`	MPP Tempo Sessions
Settlement model	Allowance (Permit2) — funds stay with client until settlement	Escrow — funds locked in contract
Protocol unit	Single HTTP request	Long-lived channel across many requests
On-chain tx per session	0 or 1 (final transfer only)	Minimum 2 (open + close), plus optional `settle()`
Payment granularity	One final amount per request	Unlimited vouchers (per-token, per-byte, per-ms)
Payment confirmation speed	~On-chain confirmation	Microseconds (voucher signature verification)
Client signature type	EIP-712 Permit2 Witness Transfer	EIP-712 Voucher (`channelId` + `cumulativeAmount`)
Time limits	Strict: `validAfter` + `deadline`	No expiry — channel lives until explicitly closed
Authorization reuse	Forbidden (single-use nonce)	Built-in: each new voucher replaces previous
Partial settlements during session	Not supported	Yes, via `settle()`
Client protection if server silent	Signature expires after deadline	`requestClose` + grace period + `withdraw`
Server protection	Signature + allowance/balance check; client may empty wallet before settlement	Funds already in escrow
Server state requirements	Minimal, nearly stateless	Requires persistent accounting
Ideal use case	REST endpoint with variable pricing	Streaming, agents, high-frequency APIs

Architectural Differences That Actually Matter

Escrow vs Allowance Is Not Style — It Is Risk Allocation

In x402 upto, funds physically remain in the client wallet until settlement. The server relies on:

valid signature,
sufficient balance at settlement time,
Permit2 allowance not revoked.

Between verification and settlement there is a window where the client can technically withdraw funds. In practice this window is short (seconds), but for high-stakes scenarios it is still a risk.

In MPP Sessions, funds are already in escrow. Once the server has a signed voucher, it is guaranteed to settle it — nobody else can withdraw those funds. This is a fundamentally different guarantee model, paid for with deposits and at least two on-chain transactions.

Why Sessions Can Handle a Million Payments per Second and `upto` Cannot

Verifying one voucher in Sessions is just ECDSA signature verification plus comparing cumulativeAmount > highestVoucherAmount. That takes microseconds. A server can process thousands of vouchers per second on one channel without touching blockchain. Heavy chain interaction happens only on open/close.

In upto, every payment requires a new Permit2 nonce and new signature. upto is designed for cases where neither client nor server knows in advance how much will ultimately be charged. It enables a complex process to run and then settle afterward. MPP Sessions, by contrast, allows continuous process control.

You could implement more complex channel-like logic in x402 too — but why, if MPP Sessions already provides it?

Cumulative Semantics — Small but Elegant

In MPP Sessions, a voucher specifies total amount paid so far, not incremental payment. This gives three properties:

Idempotency. Re-submitting the same voucher changes nothing.
Replay protection without nonce. Any older voucher is rejected because it was already accepted or superseded.
Resilience to network flakiness. Lost vouchers do not matter — the next one covers everything.

In upto, this problem is solved differently: single-use signatures and Permit2 nonce semantics. But the scenario itself is much simpler — one signature lives for one request only.

Server State

upto is nearly stateless — the server may store nothing between verification and settlement except the signature itself.

Sessions require persistent crash-safe accounting (draft-tempo-session explicitly requires writing spent into durable storage before delivering service, otherwise a crash may cause unpaid content delivery). This is serious operational complexity if your architecture was previously stateless.

Client Protection: `deadline` vs Grace Period

In upto, the client is protected by signature expiry: after deadline, the facilitator can no longer charge anything. But while it remains valid, the client cannot revoke it except by spending funds or calling Permit2.invalidateNonces.

In MPP Sessions, even without server cooperation, the client can always reclaim funds: requestClose → wait 15 min → withdraw. This costs 2–3 on-chain calls and some waiting, but guarantees exit.

Pros and Cons

x402 `upto`

Pros:

Simplest integration on top of any REST API.
Zero operational overhead: stateless server, no background settlement tasks.
No deposit — client funds are not locked.
Fits naturally into existing HTTP semantics and HTTP 402.
Uses canonical Permit2 trusted across the EVM ecosystem.
Minimal setup: client only needs to approve Permit2 once.

Cons:

Not suitable for streaming: impossible to pay per-token in real time.
Strictly single-use authorization — multi-settlements are out of scope.
Server pays gas for every settlement separately.
Client must trust server’s cost calculation within the signed maximum.
Between signing and settlement, client may theoretically empty wallet.
Requires client funds to remain in wallet rather than escrow.

MPP Tempo Sessions

Pros:

True streaming: payment synchronized with data flow.
Gas amortization: thousands of micropayments fit into two on-chain tx.
Strong guarantees for server (funds already escrowed).
Built-in forced close protects clients.
Supports delegated authorizedSigner: hot wallet can sign while cold wallet deposits.
Clean top-up model without closing channel.
Uses IETF-compatible Payment Auth scheme — not just a Web3 hack.

Cons:

Two mandatory on-chain steps: open and close. Expensive for short sessions.
Deposit locks client capital.
Requires separate contract and infrastructure (indexing, workers, crash-safe accounting).
Server must maintain persistent per-channel state.
Harder to debug: more states, more failure scenarios.
Bound to a specific network (Tempo chain in this case); cross-chain is harder.

When to Choose Which

Choose upto if:

You have a classic REST/RPC API where one request = one response.
Request price is variable but resolved in one atomic operation.
You do not want escrow/state-channel infrastructure.
Your clients do not want locked deposits.
Payment frequency is low.
You want to monetize an existing API quickly with minimal changes.

Choose Sessions if:

You stream content (SSE, WebSocket, chunked) and want payment synchronized with bytes.
Agents/bots interact hundreds of times per minute.
Gas cost for on-chain settlement becomes comparable to service price.
You need strong guarantees that client payment is secured.
You are building AI inference marketplaces with millisecond billing latency.
Your architecture can support stateful servers.

Hybrid is also valid. Nothing prevents one service from supporting both upto for one-shot API requests and Sessions for streaming endpoints. At the 402 challenge level, you simply offer multiple schemes and let the client choose.

Conclusion

upto and Sessions are not competitors — they are complementary tools at different points on the “frequency vs complexity” spectrum.

upto is the evolution of the HTTP request. You add the ability to charge an amount only known after processing, while everything else stays familiar.
Sessions are the evolution of payment infrastructure. You establish a dedicated payment channel where money movement becomes nearly free, but inherit the complexity of state channels.

For most AI APIs today — where “one prompt = one response” — upto wins because of simplicity. But once you seriously enter machine-to-machine economies, where agents live inside APIs for hours and consume streams continuously, MPP Sessions becomes the only viable option.

A simple mnemonic:

upto = “Charge me whatever it costs, within the check limit.”

MPP Sessions = “I put money in the vault — take vouchers as needed until I say stop.”

x402 vs MPP: Almost Honest Comparison

Ihor — Wed, 08 Apr 2026 19:47:22 +0000

Lately, machine payments and HTTP 402-based solutions have been gaining traction and hype.

If you ignore all the AI agent buzz and look at this as just payments, the idea is pretty simple:

a user (or agent) has a wallet with a balance (crypto or fiat — doesn’t matter)
they pay for actual usage (a request to a service), not for a subscription
services become easier to access and try

A simple example:

today: 5 subscriptions at $20 → that’s just 5 services, and:
- you have to register and subscribe
- in some cases create API keys or deal with auth breaking
- you might not even use the full subscription value
with pay-per-request machine payments:
- you can spend $0.5 on 1–2 requests and decide if you need the service
- use a service for $3–5 instead of a full subscription
- try and use more different services overall

This changes the UX quite a lot.

And this is where two different approaches come in: x402 from Coinbase and MPP (Machine Payment Protocol) from Stripe and Tempo.

Both protocols are solid in their own way.

They each have their own strengths and limitations, and it’s hard to say which one is “better” or which one will fade over time.

General model: HTTP 402 as transport

Both protocols use the same basic mechanism — HTTP 402 Payment Required.

Before, an HTTP request was just a data request.

Now it becomes something like a request with a payment condition.

The flow (or execution model) is the same in both cases:

client makes a request
server responds: “pay” (402)
client pays
repeats the request
gets the result

At this level, the similarity mostly ends.

Where the difference begins

If you go a bit deeper, the differences show up in both philosophy and implementation:

x402
- a more concrete, crypto-native approach
- a ready-to-use payment method
MPP
- a more general, flexible, protocol-level approach
- a way to describe how payment should happen

It’s a subtle difference — but a fundamental one.

Payment Model

x402: built-in payment method

x402 was originally designed as a crypto-native solution.

payments via ERC-20
uses signatures (ERC-3009, Permit2)
the client sends a signed transaction
the transaction is committed on-chain via a facilitator or the server

The client simply signs a transaction and sends it.

This provides transparency, verifiability, and decentralization (there can be multiple facilitators).

At the same time, it introduces limitations — crypto-only assets, dependency on the blockchain, latency, and fees.

MPP: intent-based model

MPP introduces a more abstract model:

the server returns a payment intent / challenge
the client fulfills it
the server validates the result

Important:

the protocol doesn’t care what the payment actually is
it only defines how to verify that the payment happened

This allows implementing different payment methods:

Stripe / cards
crypto
custom schemes

At the same time, all validation logic is pushed to the server side.

The difference here is fundamental:

x402	MPP
fixed payment method	description of the payment method
client submits a signed transaction	client performs payment based on server requirements
web3, crypto payments	web3 + traditional web2 payments (cards, etc.)
concrete implementation	meta-protocol
you adapt to the protocol	you adapt the protocol to yourself

And this already becomes noticeable at the integration stage.

Payment Processing

x402: facilitator as a layer

Here, x402 tries to follow a crypto approach — decentralization and crypto philosophy.

x402 introduces a separate entity — the facilitator.

It exists because:

someone has to send the transaction to the blockchain
someone has to confirm that it went through

The server usually doesn’t do this itself and delegates it to the facilitator.

So the flow looks like:

client → server → facilitator → blockchain

This makes sense in a crypto context, but it adds an extra layer.

On one hand:

you can use multiple facilitators
you don’t need to run your own infrastructure

On the other:

you introduce a dependency
part of the logic moves outside your system

MPP: validation abstraction

MPP follows a different philosophy — it’s primarily a protocol focused on payments and standards.

Here you get a challenge / validation model:

challenge — instructions for the client on how to pay
validation — server-side check whether the payment was successful

The server doesn’t say “send this exact transaction”, it says:

“here are the payment conditions — fulfill them.”

This is where MPP provides flexibility.

The validation function on the server can:

verify the payment locally
or delegate it to an external service — blockchain, payment processor, facilitator

So the architecture is not enforced.

This gives you more freedom, but at the same time requires more effort and time to implement.

x402	MPP
server relies on a facilitator to send transactions and get results	server decides how to validate payments, giving more flexibility
crypto philosophy, decentralization-first	focused on payments and standards

Stateless vs Sessions

This is where the difference stops being theoretical and becomes very practical.

x402

Works strictly in a one request — one payment model.

It’s simple and predictable.

But if you have, for example, 100 requests in a row — you need 100 payments.

MPP

Adds another layer — sessions, while still supporting one-off payments.

This is already closer to real-world billing:

you open a session
make multiple requests within it
payment is settled later or based on usage

This significantly changes the UX:

fewer operations
lower latency
easier to handle high-load scenarios

And this is where MPP provides more flexibility.

x402	MPP
stateless, only 1 request = 1 payment	supports both charge (1 request = 1 payment) and sessions

Integration Complexity

x402

With x402, everything is very straightforward.

There’s good documentation, SDKs, and ready-to-use examples. The protocol already defines:

how to pay
how to validate
which formats to use

Because of that, integration is fast — especially if you’re already working with EVM / Solana and USDC.

There’s also standardization: if a token supports ERC-3009 or Permit2, you can simply add a new network — the rest of the logic stays the same. You only need a facilitator for that network.

MPP

With MPP, the situation is a bit different.

If you use prebuilt payment methods (for example, Stripe, Tempo, or other ready solutions), the basic integration is also quite simple.

But after that, you start making decisions that x402 already made for you.

For example, you need to decide:

whether you operate in one-off payment (charge) mode
or use sessions

And if you want something custom, you’ll need to implement:

your own payment intents / challenges
your own payment validation logic

This isn’t technically hard, but it does require more time and architectural thinking.

And this is where the main trade-off becomes clear:

in MPP, complexity is the price you pay for flexibility

In the end:

x402 — faster to start, fewer decisions
MPP — more control, but more work

At the same time, both protocols are generally easy to integrate — these aren’t the kind of systems where you spend a week fighting the docs and nothing works.

Compatibility

A small but important point.

x402 came earlier and is already in use with its own rules and ecosystem.

MPP is a newer protocol, but it was designed with existing approaches in mind, including x402.

The key point:

MPP can be implemented in a way that is compatible with x402

In other words, if you build your system on MPP, you can still work with servers that use x402.

This makes MPP more universal in terms of integrations and transitions between protocols.

Scalability

If you look at the real world, there are many payment methods: different types of cards, bank transfers, local systems, crypto (with different networks and tokens).

And users in different regions will use different options.

So for a service, it’s important to:

support multiple payment methods
not limit the user
scale as the service grows

x402

With x402, there are some limitations.

Yes, it can be wrapped through processors like Stripe, but in practice the payment still ends up being a blockchain transaction.

So: even if the user “pays with a card”, under the hood it’s still crypto

Which means:

dependency on the network
fees
latency

MPP

MPP is not tied to any specific payment method.

It allows you to:

use different payment rails
adapt to regions
use sessions instead of paying per request

This is already closer to real-world billing systems.

MPP provides more flexibility for scaling and, in this sense, looks stronger.

A small off-topic note.

You can argue about different implementations — what’s simpler, what’s more complex, and so on.

But at the most abstract level, a protocol is just:

a set of headers + rules for handling them

And the actual processing can be implemented in different ways.

However, I personally stick to defined protocols and try not to deviate from their original specifications.

And from that perspective, MPP clearly has the advantage.

Discovery and Machine-Readable Description

Another very important topic I want to touch on is discovery in both protocols.

Not just “how to pay”, but how to find the right service and understand what it can do.

x402

With x402, this is handled through the so-called bazaar discovery layer.

It’s implemented at the facilitator level:

the server declares discovery metadata (description of its routes and endpoints)
the facilitator extracts and aggregates this information
the client queries the facilitator to discover available services

In essence:

the facilitator becomes an API marketplace

This is especially useful for AI agents, which can use the facilitator as a source to discover available tools.

And this unlocks a strong use case:

a lot of services are aggregated in one place, and you can immediately start interacting with them.

MPP

MPP takes a different approach.

There is no single entry point, but there is a specification:

each server must expose an openapi.json
it describes endpoints and pricing

This is a more classic, decentralized approach.

But there’s a trade-off:

the client (or agent) has to query each service and collect this information itself

Unlike x402, where the facilitator can return everything at once.

In the end, there’s no “right” answer here.

x402 → centralized discovery via facilitator
MPP → decentralized discovery via OpenAPI

Both approaches are valid and practical.

But personally: discovery through the facilitator is a very strong and underrated feature of x402

And in this aspect, it feels noticeably more convenient.

What to choose

So in the end — what should you choose, and for which use cases?

In my view, both protocols are useful, they just operate at different levels of abstraction.

x402 is a good choice if:

you only need crypto payments
fast and simple setup matters
you’re interested in the facilitator ecosystem and bazaar discovery

It’s a solid option when you want to quickly launch pay-per-request in a crypto environment without adding complexity.

MPP is a better fit if:

you plan to scale
you need multiple payment methods (not just crypto)
you expect high load
sessions and flexible billing matter

This is closer to building a full payment infrastructure.

In my view:

x402 is a fast and straightforward entry point
MPP is the foundation for more complex and scalable systems

Forem: Ihor

x402 upto vs MPP Sessions: Two Philosophies of Usage-Based Payments

TL;DR

Session Lifecycle

x402 upto

MPP Tempo Sessions

Table of Key Differences

Architectural Differences That Actually Matter

Escrow vs Allowance Is Not Style — It Is Risk Allocation

Why Sessions Can Handle a Million Payments per Second and upto Cannot

Cumulative Semantics — Small but Elegant

Server State

Client Protection: deadline vs Grace Period

Pros and Cons

x402 upto

MPP Tempo Sessions

When to Choose Which

Conclusion

x402 vs MPP: Almost Honest Comparison

General model: HTTP 402 as transport

Where the difference begins

Payment Model

x402: built-in payment method

MPP: intent-based model

Payment Processing

x402: facilitator as a layer

MPP: validation abstraction

Stateless vs Sessions

x402

MPP

Integration Complexity

x402

MPP

Compatibility

Scalability

x402

MPP

Discovery and Machine-Readable Description

x402

MPP

What to choose

x402 `upto`

Why Sessions Can Handle a Million Payments per Second and `upto` Cannot

Client Protection: `deadline` vs Grace Period

x402 `upto`