How HTTP 402 Can Power a Pay-per-Use Web Service

HTTP 402 can act as the doorway to a pay-per-use service, but the status code does not collect money on its own. A usable system must tell the client what the resource costs, accept a bounded payment authorization, verify and settle it, deliver the resource once, and return enough evidence for both sides to understand the result. x402 supplies one current protocol for that complete exchange.

HTTP 402 is only the signal

RFC 9110 reserves the 402 Payment Required status for future use and does not define a universal payment exchange. Ordinary browsers do not automatically open a standard checkout when they receive it. A pay-per-use service therefore needs an agreed protocol between server and client. x402 uses the status as a machine-readable challenge and defines how payment requirements, authorization and settlement results travel with the HTTP requests and responses.

The complete flow has seven states

A reliable design is easier to reason about as a state machine rather than a single paid request.

• Unpaid request: the client asks for a protected resource without acceptable payment.
• Quoted: the server returns HTTP 402 with the accepted scheme, amount or maximum, network, asset, recipient and expiry.
• Authorized: the client checks its policy and signs a payment payload matching those terms.
• Retried: the client repeats the resource request with the signed payment payload.
• Verified: the server or facilitator confirms that the authorization matches the advertised requirements.
• Settled or committed: value is transferred immediately or a valid batch voucher is accepted for later redemption.
• Delivered: the server returns the resource once with a structured payment result or receipt.

x402 version 2 standardizes three headers

The current x402 documentation defines PAYMENT-REQUIRED from server to client, PAYMENT-SIGNATURE from client to server and PAYMENT-RESPONSE from server to client. Their values contain Base64-encoded JSON objects. The first describes acceptable payment options, the second carries the buyer’s authorization and the third reports settlement. A compatible client library can parse the challenge, prepare the signature and retry automatically.

Quote enough information for a safe decision

A client should never sign merely because the response code is 402. The payment requirement needs the exact resource, scheme, price or maximum, token, network, receiving address and validity period. A description and MIME type help an agent judge whether the output matches its task. Multiple accepted options can be advertised, but each option should be complete enough to validate independently.

Use exact when the price is known before work starts

The exact scheme fits a fixed lookup, file, cached report or deterministic transformation. The buyer authorizes the advertised amount and the service settles that amount. This is the simplest model because price is known before execution, but a push payment is generally irreversible after settlement. The server still needs a rule for resource failure after payment.

Use upto when final usage is unknown

The upto scheme lets the buyer sign a spending ceiling before execution. After the workload finishes, the seller charges the measured usage without exceeding that limit. It fits model tokens, compute time, bytes processed or another workload that cannot be priced precisely in advance. The ceiling protects the buyer; it is not an amount the seller should try to consume.

Use batch settlement for repeated small calls

High-frequency buyers can fund an EVM escrow channel once and sign off-chain vouchers for individual requests. Providers aggregate those vouchers before redeeming them onchain. This lowers the number of separate settlements required for tiny calls, but it adds channel state, deposit policy and redemption logic, making it better suited to repeated traffic than an initial proof of concept.

Choose the route boundary before choosing the price

Protect a resource with a clear unit: one weather result, one document conversion, one inference job or one archive item. Charging an entire application without defining what one payment unlocks creates ambiguous retries and support disputes. The route contract should state the method, expected input, output type, maximum processing time and whether the result may be cached.

Verify before expensive work

The initial unpaid request should not trigger costly inference or a large database operation. First validate the payment requirement match, signature, expiry, network, asset, recipient and replay status. For fixed-price work, settlement can normally happen before resource execution. Variable usage requires a more careful sequence because the final amount depends on work performed; reserve the maximum, measure usage and settle the actual amount under the chosen scheme.

Bind payment to the requested resource

A valid transfer to the right wallet is not enough if it can be reused for another URL or another payload. The authorization should be tied to the resource and terms the seller advertised. Signed offer and receipt extensions can create verifiable records of the quote and successful response. Strong binding reduces payment substitution, stale-price acceptance and arguments about what was purchased.

Idempotency turns retries into one purchase

Network timeouts are normal. Without an idempotency rule, a client may pay twice after receiving the resource but losing the response, or a proof may unlock the same work repeatedly. The x402 payment-identifier extension lets a client send a unique payment ID and allows the server to cache the completed response for later retries. The cache lifetime should cover the realistic retry window without keeping sensitive output longer than necessary.

Separate payment failure from service failure

A malformed or unacceptable payment payload should not look like a successful purchase. A verified payment followed by an origin failure is a different state and needs a defined remedy. Log the request ID, payment ID, advertised terms, verification result, settlement result and delivery status. Return structured errors that allow the client to decide whether it should correct the payment, retry safely, wait or stop.

A facilitator reduces blockchain work but does not remove responsibility

A facilitator can verify signed payloads, submit settlement and return a result, allowing the seller to avoid direct chain integration. The seller still decides which facilitator to trust, which schemes and networks to advertise, how to handle outages and whether a settlement result is sufficient to release the resource. Coinbase currently lists 1,000 facilitator transactions per month free and a $0.001 fee for each additional transaction, so very low endpoint prices need an explicit unit-economics check.

Worked route: usage-priced document extraction

Consider POST /extract with a maximum authorization of $0.05. The server returns 402 with the upto scheme and the maximum. The client signs after checking its task budget. On retry, the server verifies the authorization before opening the document, processes 18 pages, calculates an actual charge of $0.027, settles that amount and returns JSON plus the payment result. A repeated request with the same payment ID returns the cached result instead of processing and charging again.

Do not assume a normal browser is a compatible buyer

A browser currently treats an unfamiliar 402 response as a generic client error unless the site adds its own interface or wallet integration. Pay-per-use over x402 is strongest for wrapped fetch clients, SDKs, agents, MCP tools and applications prepared to understand the headers. A human-facing website may need a conventional checkout or an adapter that performs the protocol on the user’s behalf.

Test failures before moving to mainnet

A successful testnet payment proves only the happy path. Exercise the boundaries that cause duplicate charges or unpaid work.

• Missing payment returns one clear 402 challenge.
• Wrong asset, network, recipient or amount is rejected before resource execution.
• Expired and replayed authorizations cannot unlock a fresh response.
• A timeout followed by the same payment ID returns one result without a second charge.
• A failed origin operation records a service failure separately from payment verification.
• The client refuses a changed price or recipient that exceeds its policy.
• Logs can reconcile the resource request, settlement and delivered response.

A production decision checklist

Launch only after the commercial unit and technical state machine are both clear.

• One defined billable resource per route
• Exact, upto or batch settlement chosen for the workload
• Supported asset, network and facilitator confirmed
• Client maximums and server price limits enforced
• Request binding and expiry validated
• Payment identifier and retry cache implemented
• Resource failure and refund policy documented
• Settlement, delivery and margin monitored separately
• Small mainnet test completed before wider access

The practical architecture

HTTP 402 works best as the visible transition between free discovery and a precise paid resource. The server quotes; the client authorizes within policy; verification happens before avoidable cost; settlement follows the selected scheme; idempotency prevents duplicate buying; and delivery produces a traceable final state. Removing any one of those steps turns a clean pay-per-use design into an ambiguous payment experiment.

How the technical claims were checked

The public article was read before replacement. RFC 9110 supplied the status-code boundary. The current x402 specification and seller, buyer and extension guides supplied the header names, schemes, retry model and receipt behavior. Coinbase documentation was used only for hosted facilitator and network facts. The document-extraction route is a calculated example, not a report of a deployed service.

Technical source record — July 28, 2026

The source set is limited to protocol specifications and current provider documentation. No search engine or Google material is cited.

• RFC 9110 status code semantics: https://www.rfc-editor.org/rfc/rfc9110.html
• x402 HTTP 402 and version 2 headers: https://docs.x402.org/core-concepts/http-402
• x402 seller quickstart and scheme selection: https://docs.x402.org/getting-started/quickstart-for-sellers
• x402 buyer retry and discovery flow: https://docs.x402.org/getting-started/quickstart-for-buyers
• x402 network, token and batch-settlement support: https://docs.x402.org/core-concepts/network-and-token-support
• x402 payment identifier for idempotency: https://docs.x402.org/extensions/payment-identifier
• x402 signed offer and receipt extension: https://docs.x402.org/extensions/offer-receipt
• Coinbase facilitator role and pricing: https://docs.cdp.coinbase.com/x402/core-concepts/facilitator
• Coinbase x402 network support: https://docs.cdp.coinbase.com/x402/network-support

FAQ