Payment Schemes

A scheme defines what the client authorizes and what the server or facilitator can settle. Pick the scheme based on pricing semantics, not just SDK availability.

exact

The exact scheme is the simplest mental model: the server knows the required amount in advance, and the payment must match it exactly. It fits paid articles, fixed-price API calls, one-off file downloads, small data products, and deterministic tool calls.

Exact is attractive because support and accounting are straightforward. The downside is that it does not naturally handle unknown final cost. If your endpoint might produce 200 tokens or 20,000 tokens, exact either overcharges, undercharges, or requires a preflight pricing step.

Best for: fixed-price resources.
Hard requirement: amount and destination correctness.
Buyer risk: irreversible push payment, so refund policy must be business logic.

upto

The upto scheme authorizes a maximum. The actual settlement amount is chosen later based on usage, but it must not exceed the authorized maximum. This is closer to usage-based billing while preserving a single request/response authorization model.

The spec adds important constraints: single-use authorization, explicit validity windows, recipient binding, and maximum amount enforcement. Those requirements exist because a flexible maximum is more dangerous than a fixed price if replay, recipient, or expiry checks are weak.

Best for: LLM tokens, bandwidth, dynamic compute, or variable-size results.
Hard requirement: settlement amount must be less than or equal to the authorized maximum.
Buyer risk: the max should be low enough that worst-case settlement is acceptable.

batch-settlement

Batch settlement is for workloads where many individual requests should not each become a separate immediate onchain settlement. The docs describe an EVM implementation with unidirectional payment channels: the buyer deposits into escrow, signs cumulative vouchers offchain, and the seller redeems later.

This is the right direction for high-throughput APIs and repeated agent calls. It lowers per-call settlement overhead, but it adds channel state, escrow management, voucher accounting, and more complicated dispute or refund flows.

Best for: repeated paid API calls and high-frequency usage.
Hard requirement: reliable accounting across many offchain authorizations.
Seller risk: batching improves economics but increases state-management complexity.

FAQ

Which scheme should I implement first?

Use exact for the first production endpoint unless your product genuinely needs variable final pricing. It is easier to test, explain, and support.

Can schemes evolve?

Yes. x402 v2 is designed around modular schemes and extensions so new payment models can be added without rewriting the core protocol.