Research guide · x402 seller/buyer interoperability · 13 September 2026
x402 upto: meter usage, settle less than the maximum
Fixed-price x402 is straightforward when the price is known before work starts. The upto scheme handles the harder case: the buyer signs a maximum spend, the service performs one variable-cost request, and the seller settles only the measured amount — provided the entire buyer → server → facilitator path understands the scheme correctly.
Published 13 September 2026 · sources checked 13 September 2026
EVM
Current x402 upto specification is EVM/Permit2
max → actual
Buyer signs a ceiling; seller settles the metered amount
0 ≤ charge ≤ max
Zero settlement is valid; the seller cannot settle above the signed ceiling
Scheme selection
Use upto for one variable-cost request, not every payment problem
| Scheme | Price knowledge | Settlement shape | Best fit |
|---|---|---|---|
exact | Known before execution | One fixed charge | Simple fixed-price API calls or content |
upto | Maximum known; final cost measured later | 0 to the signed ceiling | One variable-cost request: tokens, bytes, compute time |
batch-settlement | Repeated charges over a session | Aggregated / channel-style settlement | High-frequency repeated micropayments |
Wire semantics
The same amount field changes meaning between verify and settle
The important implementation trap is phase-dependent amount semantics. During /verify, the payment requirement amount is the buyer's authorized maximum and must match the Permit2 authorization ceiling. During /settle, the resource server replaces that requirement amount with the actual charge produced by metering.
The facilitator must therefore re-verify the signature against the original permit2Authorization.permitted.amount, confirm that the actual settlement amount is less than or equal to that ceiling, and transfer the actual amount. A facilitator that requires the settlement amount to equal the signed maximum will reject every legitimate partial settlement.
The specification also permits a zero settlement. If no billable usage occurred, the authorization can expire unused without an on-chain settlement transaction.
Buyer risk
A spending ceiling is authority, not a promise of fair metering
The x402 scheme deliberately gives the resource server control over the final charge within the signed limit. That enables useful billing for token generation, bandwidth and dynamic compute, but it also creates a trust boundary: a malicious or faulty server can charge the full authorized maximum even when actual usage was lower.
Autonomous buyers should therefore choose conservative per-request ceilings, preserve the quote and request fingerprint, record the final PAYMENT-RESPONSE or stronger settlement evidence, and compare billed usage against the service's published metering rule when that rule is independently measurable.
Do not reuse upto as a substitute for session budgeting. The authorization covers one variable-cost payment. For repeated calls, combine it with buyer-side spend policy and idempotent retry controls; where both parties support a high-frequency payment channel, batch-settlement may be the more natural scheme.
Compatibility checks
Never assume “supports x402” means “supports upto”
- Confirm that the client, resource server and facilitator all support the same
(scheme, network)pair. - On EVM, expect Permit2 for
upto; EIP-3009 is not the transfer method for this scheme because it fixes the amount at signature time. - Check one-time Permit2 allowance or an advertised approval-sponsoring extension before treating a payment failure as a metering bug.
- Test a deliberately partial settlement, not only “actual equals maximum”. That catches the common verify/settle equality mistake.
- Keep the buyer's maximum, the seller's metering output and the facilitator's final settled amount as separate evidence fields.
Related zFinia paths
Pair metered billing with payment evidence and retry safety
Before paying an unfamiliar service, use zFinia's x402 verification guide to separate challenge, verification, settlement and delivery evidence. For timeouts and crash recovery, use the payment-identifier idempotency guide. To find payable services, use x402 API discovery, or inspect zFinia's machine-service catalogue at /api.
Primary sources