Paying per call over plain HTTP

HTTP has carried a status code for payment since its early days. Status 402, Payment Required, sat reserved and mostly unused for decades, because there was no practical way to pay for a single request inside the request itself.

Agents change the economics. A research agent might call a pricing API, a translation service and dozens of search endpoints in one task. None of those providers want to open an account for it, and the agent’s owner does not want a card on file with each of them.

402LXP is how Paxeer X fills that gap. It is per-call payment over plain HTTP, settled in LayerX, with a signed receipt as proof.

The flow in three headers

The exchange uses the x402 version 2 wire format across three headers.

• The challenge. A service that wants payment answers with HTTP 402 and a PAYMENT-REQUIRED header. It carries the resource URL and between one and 32 payment alternatives for that resource. Each alternative names its own asset, amount, recipient and required commitment level.
• The payment. The caller selects one alternative, returns it unchanged in a PAYMENT-SIGNATURE header, and attaches the evidence: a canonical LayerX receipt or a signed grant draw.
• The response. The service verifies that evidence against the offer it issued. Only then does it release the resource, with a PAYMENT-RESPONSE header whose settlement reference points to the receipt digest.

The buyer cannot substitute the asset, amount or recipient. The seller cannot accept less evidence than its own offer asked for.

Three ways to charge

Not every service bills the same way, so 402LXP supports three schemes.

• exact for a fixed price per call.
• metered for per-request draws against a grant the payer signed in advance.
• subscription for renewals.

With a grant draw, the payer signs an allowance for one recipient, one asset and one purpose, with a per-draw ceiling. The provider pulls against it, and both signatures are checked along with every grant restriction before anything is debited. The seller cannot manufacture the payer’s authorization.

The seller decides how much certainty it needs

Each offer carries a commitment level, and that level decides what evidence the seller must verify.

• executed needs the sequencer-signed receipt.
• batched adds Merkle inclusion in an authorized batch header.
• finalised adds the guarantor checkpoint certificate.

A cheap lookup can release on an executed receipt. A costly job can require more. Missing evidence never downgrades a request to a weaker level. The request is refused instead. Trust inputs come from the verifier’s own configured network authority, never from the payment response it is checking.

One practical note: verifying at finalised depends on the operator supplying its checkpoint authority inputs, such as the bonded guarantor keys and the required guarantor count. A deployment without them does not accept payments at that level.

What does not count as payment

The protocol is strict about evidence. An acknowledgement, a queue position, a submission identifier or a successful HTTP response is never treated as proof of payment. The handler runs once a verified receipt binds the payer, payee, asset and amount to the offer that was issued.

Retries that never charge twice

Networks drop connections, and agents retry. 402LXP is built for that.

Each fulfillment is recorded under an idempotency key derived from the caller and the request digest. A repeated request returns the stored result instead of charging again. A changed request under an existing key is refused, and so is a receipt replayed from a different request. An invoice bound to a reference settles once. A second attempt returns an already-settled error.

Middleware for the stack you have

You do not need to implement the wire format by hand. Buyer and seller middleware ship in both the TypeScript and Python SDKs, and framework adapters mount payment into an existing app in one call:

• mountLayerX for Express and Next.js
• mount_layerx for FastAPI
• auto-configuration for Spring Boot

Four role packages share one wire contract: buyer, seller, merchant and agent. The agent package reserves, holds, commits or releases budget around every spend, so a paying agent stays inside the limits its owner set. Existing routes keep their shape. The middleware supplies the idempotency and replay rules so each service does not write its own.

The same three payment signals also encode over MCP and A2A through the interop adapter, and settlement identity does not depend on which transport carried the request.

Why it matters

For a provider, 402LXP turns any endpoint into a paid endpoint without a checkout page or an invoice cycle. For a buyer, every call ends with a receipt digest it can verify against the network rather than a promise from the seller. For the person who owns the agent, every payment draws from a budget the network enforces.

Every paid call becomes one HTTP round trip with a receipt at the end.

The documentation includes the full header specification and middleware guides for each framework.