One API call,one receipt.
A data provider sells per request over plain HTTP. No accounts, no invoices, no card on file.
- Category
- Payments
- Built with
- 402LXP, x402 middleware
- 402the HTTP status that carries the price and the terms
- L0–L4finality ladder behind the commitment a seller can require
- 4frameworks with one-call mounts, Express to Spring Boot
The problem
Selling data per request usually means accounts, API keys, prepaid credit and a monthly invoice. That works for a buyer with a procurement team. It shuts out an agent that needs one answer, once.
How it works on Paxeer X
402LXP is HTTP-native payment on LayerX, compatible with x402 version 2. A protected route answers with a price. The caller pays and retries with a signed payment header. The route releases its data only after a LayerX receipt verifies against the exact offer it issued.
- Mount the middleware on an existing Express, Next.js, FastAPI or Spring Boot route in one call
- Each offer names its asset, amount, recipient and required commitment; the buyer cannot substitute any of them
- Idempotency keys make a retry replay the original result instead of charging twice
- A reference-bound invoice settles once. A second attempt is refused.
The outcome
The seller is paid per request and holds a receipt digest it can check against the network, not a promise. The buyer holds the same receipt. The same payment signals travel over HTTP, MCP and A2A, so a dispute starts from evidence instead of logs.
“An acknowledgement, a queue position or a successful HTTP response is never treated as proof of payment.”
Build the next one.
The limited beta is open to approved developers. Tell us what you are building and we will get you an allocation.