Skip to main content
x402 extends the HTTP 402 Payment Required status into a full micropayment handshake. It lets an agent pay for a resource inline — no checkout page, no human, no stored card. Sella uses x402 for dataset purchases, Cradle and Mergekit jobs, and API Data Market calls.

​
The four-step flow

Every paid call follows the same four-step pattern. Your agent handles steps three and four; Sella handles the rest.
1

Request

Your agent calls a paid resource with no payment attached — just the normal request with your Bearer token.
2

Challenge

The server responds with HTTP 402 and a PAYMENT-REQUIRED payload that describes exactly what to pay, to which address, on which chain, and by when.
3

Sign

Your agent signs the challenge locally with its wallet key, producing a PAYMENT-SIGNATURE. The key never leaves your machine.
4

Retry & settle

Your agent retries the request with the signature attached. The server verifies the signature and settles the payment on-chain through the facilitator, then returns the resource.

​
Anatomy of a challenge

When a paid resource returns 402, the response body is a JSON challenge object. Here is a representative example:
​
x402Version
number
Protocol version. 2 is current and preferred.
​
accepts
array
One or more acceptable payment options. Each option specifies a chain, amount, recipient address, and expiry. Pick one option and sign it.
​
network
string
The settlement chain for this option, e.g. base, solana, or stellar.
​
priceInAtomicUnits
string
The amount in the token’s smallest denomination. Divide by the token’s decimals to get the human figure — for example, 45000000 equals 45 USDC at 6 decimals.
​
payTo
string
The recipient wallet address for this payment option.
​
expiresAt
string
ISO 8601 timestamp after which this challenge is no longer valid. If you miss it, request a fresh 402 and sign the new challenge.
Always read the chain, amount, and recipient from the live challenge. Never hard-code these values — they vary per listing and per option.

​
Versions and headers

x402 has two versions. Use v2 for all new integrations.

v2 (preferred)

Supply a PAYMENT-SIGNATURE header in direct HTTP calls. In MCP tool calls, pass the base64-encoded signature as the payment_signature argument.

Legacy v1

X-PAYMENT and X-PAYMENT-RESPONSE headers are still accepted for older clients — mapped to the x_payment and payment_proof MCP arguments respectively.

​
Supported chains

Sella’s chain-agnostic router selects the appropriate settlement chain per product. The 402 challenge always tells you which chain to use for that specific call. All settlements are denominated in USDC, regardless of the underlying chain.

​
MPP

The API Data Market also supports MPP for pay-per-call flows, settled via the mpp/pay proxy route — often on Tempo. The runtime MPP challenge is authoritative for price, just like a 402 challenge.

​
Settlement and fees

Sella verifies and settles payments through an x402 facilitator. On paid marketplace listings, a 3% platform fee is split to a per-chain treasury at settlement time. The remainder goes directly to the publisher’s wallet in USDC.

​
Security

x402 is designed so that neither Sella nor any other party can fabricate or replay a payment on your behalf.

Nonce + expiry

Each payment carries a unique nonce and an expiry timestamp. This prevents any signed payload from being replayed after it has settled.

Local signing

Your wallet key signs the challenge on your machine. The private key never transits Sella — only the resulting signature is sent.