Neuronto PaymentsAccept payments

What is x402? The HTTP status code that lets software pay for things

x402 is an open payment protocol that puts a price on a single HTTP request: the server answers an unpaid call with 402 Payment Required plus machine-readable terms, the client signs a stablecoin transfer for exactly that amount, and retries the same request with the signature in a header.

Answer first

  • HTTP 402 has been in the specification since the 1990s with no defined behaviour. RFC 9110, section 15.5.3, still says in full: "The 402 (Payment Required) status code is reserved for future use." (RFC 9110)
  • x402 defines what goes in that response. It was published by Coinbase on 6 May 2025 and the documentation is licensed Apache-2.0. (Coinbase Developer Platform, x402 docs)
  • Two versions are in the field: x402Version: 1, which names networks with short strings such as base, and x402Version: 2, which uses CAIP-2 identifiers such as eip155:8453.
  • The payer needs a funded wallet on the right network. There is no account, no API key, no card, and no reversal.
  • A facilitator verifies the signed payload and broadcasts the transfer. It cannot change the amount or the destination, and it never holds the funds. (x402 specification)
The x402 payment flow over one HTTP request A client requests a resource, receives HTTP 402 with payment terms, signs a stablecoin payment, retries the request, the server verifies and settles it through a facilitator, and the resource is delivered with a settlement receipt. Client or agent Resource server Facilitator 1. GET /premium 2. 402 + PAYMENT-REQUIRED 3. GET /premium + PAYMENT-SIGNATURE 4. POST /verify 5. POST /settle 6. 200 + PAYMENT-RESPONSE amount, asset, payTo, network signature over the exact amount signature and balance checked, nothing moves transfer broadcast on-chain transaction hash of the settled transfer

What does "402 Payment Required" mean?

Two different things, and telling them apart matters.

A bare 402 with an HTML or plain JSON body is almost always a billing message from an API you already have an account with: credit exhausted, invoice unpaid, plan expired. Nothing in HTTP tells the client what to do next, so it reaches a human like any other 4xx error.

An x402 402 is different in one observable way: it carries payment terms a program can act on, in a PAYMENT-REQUIRED response header holding a base64-encoded object, and in the response body. The x402 documentation defines the protocol as one that "is built around the HTTP 402 Payment Required status code and allows clients to programmatically pay for resources without accounts, sessions, or credential management" (x402 docs).

Version 2 of the protocol uses three headers, and they are the whole wire surface: PAYMENT-REQUIRED from server to client, PAYMENT-SIGNATURE from client to server, PAYMENT-RESPONSE from server to client after settlement (x402 docs, HTTP 402).

Who created x402, and is it an internet standard?

Coinbase published it. The launch post is dated 6 May 2025 and opens: "Coinbase is launching x402, a payment protocol that enables instant stablecoin payments directly over HTTP" (Coinbase Developer Platform). The specification and documentation are Apache-2.0 and now sit under an open foundation repository.

It is not a ratified standard. No RFC has redefined status code 402, and the reservation in RFC 9110 stands unchanged. An IETF draft on agentic payments describes the position precisely: "RFC 9110 reserves status code 402 (Payment Required) for future use [RFC9110]; recent protocol work proposes wire mechanics for machine payment using that code," and adds that such work "is cited in this document as provenance for an established pattern, not as a settled standard" (draft-king-yew-choo-agentic-payments). Build on x402 because the implementations interoperate today, not because a standards body has blessed it.

How the x402 payment protocol works, one request at a time

A real unpaid request against a live x402 resource, trimmed to the interesting headers:

bash
curl -i https://pay.neuronto.com/echo
http
HTTP/2 402
content-type: application/json
cache-control: no-store
payment-required: eyJ4NDAyVmVyc2lvbiI6MiwiZXJyb3IiOiJQQVlNRU5U...
access-control-expose-headers: PAYMENT-REQUIRED, PAYMENT-RESPONSE, X-PAYMENT-RESPONSE

{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required",
  "resource": {
    "url": "https://pay.neuronto.com/echo",
    "mimeType": "application/json",
    "serviceName": "Neuronto Payments"
  },
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "1000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0xb648c75bC8303062Bd4A6311808827E08a52c61D",
    "maxTimeoutSeconds": 60,
    "extra": { "name": "USD Coin", "version": "2" }
  }]
}

Every field does work. scheme: "exact" means the buyer signs for the advertised amount and no more. amount: "1000" is atomic units, and USDC carries 6 decimals, so this request costs one tenth of a US cent. asset is the token contract, payTo is the merchant's own wallet, maxTimeoutSeconds bounds the validity window of the signature, and extra.name and extra.version are the EIP-712 domain parameters the wallet needs to produce a signature the token contract will accept. Those two differ per network, which is a common source of an invalid signature: USDC on Base signs as USD Coin version 2, while the same token on Base Sepolia signs as USDC.

The client reads accepts, picks an option it can pay, and signs. Under the default eip3009 transfer method, the payload it sends back is shaped like this, taken verbatim from the specification:

json
{
  "x402Version": 2,
  "accepted": {
    "scheme": "exact", "network": "eip155:84532", "amount": "10000",
    "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
    "payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
    "maxTimeoutSeconds": 60,
    "extra": { "assetTransferMethod": "eip3009", "name": "USDC", "version": "2" }
  },
  "payload": {
    "signature": "0x2d6a7588d6acca505cbf0d9a4a227e0c52c6c34008c8e8986a1283259764173608a2ce6496642e377d6da8dbbf5836e9bd15092f9ecab05ded3d6293af148b571c",
    "authorization": {
      "from": "0x857b06519E91e3A54538791bDbb0E22373e36b66",
      "to": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "value": "10000",
      "validAfter": "1740672089",
      "validBefore": "1740672154",
      "nonce": "0xf3746613c2d920b5fdabc0856f2aeb2d4f88ee6037b8cc5d04a71a4462f13480"
    }
  }
}

That object goes back base64-encoded in PAYMENT-SIGNATURE on a retry of the same request. The signature is 65 bytes over a transferWithAuthorization call, the nonce is single use, and validAfter and validBefore make the authorisation expire on its own (x402 exact EVM scheme).

The server now has a decision to make, and it makes it by calling a facilitator twice:

bash
# 1. free, moves nothing: does this signature actually pay the advertised terms?
curl -s https://pay.neuronto.com/verify \
  -H 'content-type: application/json' \
  -d '{"x402Version":2,"paymentPayload":{...},"paymentRequirements":{...}}'
# -> {"isValid":true,"payer":"0x857b..."}

# 2. after the work is done: move the money
curl -s https://pay.neuronto.com/settle \
  -H 'content-type: application/json' \
  -H 'Idempotency-Key: req_8f21c0' \
  -d '{"x402Version":2,"paymentPayload":{...},"paymentRequirements":{...}}'
# -> {"success":true,"transaction":"0x...","network":"eip155:8453","payer":"0x857b...","amount":"1000"}

Serve the paid response after success: true, not after verification. Verification proves a payment can settle; settlement proves it did. Wiring this by hand is unnecessary: an x402 server SDK does the whole exchange from a route table.

js
import express from "express";
import { paymentMiddleware, x402ResourceServer } from "@x402/express";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { HTTPFacilitatorClient } from "@x402/core/server";

const server = new x402ResourceServer(
  new HTTPFacilitatorClient({ url: "https://pay.neuronto.com" }),
).register("eip155:8453", new ExactEvmScheme());

const app = express();
app.use(paymentMiddleware({
  "GET /premium": {
    accepts: { scheme: "exact", price: "$0.001", network: "eip155:8453", payTo: "0xYourWallet" },
    description: "One premium answer",
    mimeType: "application/json",
  },
}, server));
app.get("/premium", (req, res) => res.json({ ok: true }));
app.listen(3000);

What an x402 facilitator does, and what stays with the merchant

A facilitator is the only party that talks to a blockchain, and its powers are deliberately small.

StepWho does it
Decide the price and which networks to acceptMerchant
Publish the 402 with acceptsMerchant, usually via SDK middleware
Check the signature, the balance, the expiry windowFacilitator, POST /verify
Run the paid workMerchant
Broadcast the transfer and pay the gasFacilitator, POST /settle
Hold the received fundsNobody. They land in the merchant's advertised wallet
Refund, dispute, invoice, taxMerchant, outside the protocol

The specification is blunt about the limits of the role: "In all cases, the Facilitator cannot modify the amount or destination. They serve only as the transaction broadcaster" (x402 exact EVM scheme). The documentation adds that "The facilitator does not hold funds or act as a custodian" (x402 docs, Facilitator).

That is also the difference between an x402 facilitator and a card payment facilitator. The card kind aggregates merchants under its own account, takes the money first and pays out later. An x402 facilitator never takes the money at all: the payer's signed authorisation moves USDC straight to the merchant's address in one transaction.

One warning worth repeating from the documentation before anything goes to production: "the public x402.org facilitator is intended for development and testnet workflows. Do not assume it is the default path for production mainnet routes" (x402 docs, Facilitator).

What x402 does not do

  • It is not card payments. No Visa or Mastercard rails, no 3-D Secure, no stored card.
  • It is not fiat. The merchant is paid in a stablecoin, on-chain. Converting to a bank balance is a separate job with its own compliance.
  • It is not custody. Nothing in the protocol holds a balance on anyone's behalf, which also means no account balance to draw down.
  • It is not subscription billing. There are no plans, renewals, dunning or proration. One request, one payment.
  • It is not chargebacks. There is no dispute mechanism and no reversal. A settled transfer is final.
  • It is not identity or authorisation. A valid payment says money moved, not who the payer is or what they may do with the answer.
  • It is not a token. x402 is a protocol specification. Assets named on ticker sites that borrow the string "x402" are unrelated to the specification.

The inconvenient part is the wallet. A buyer cannot pay a 402 with a credit card, an email address or a promise: they need a funded wallet holding the right asset on the right network before the first call, and if they pay for a broken response, the money is gone and the only remedy is the merchant's goodwill. Machine payments also inherit the ledger's own gap, described in an IETF draft on x402 receipts: "an off-chain receipt does not confirm that a settlement was committed to a public ledger" (draft-vauban-x402-consolidated). Keep the transaction hash.

What a payment costs

The protocol adds no fee of its own. What remains is network gas for the settlement transaction, paid by the facilitator that broadcasts it. On this facilitator, GET /pricing publishes the formula and the number: network gas cost multiplied by 1.30, expressed in credits of $0.001 and rounded up to 0.01 credit, with verification at zero and a 14 day notice before a published rate changes. The current estimate for one Base settlement is 2.11 credits, around $0.00211. Settlements on testnets are free.

Check GET /supported before advertising terms rather than hardcoding a network. It lists every live combination of x402Version, scheme and network, so a route never quotes a price the facilitator cannot take.

x402 compared with AP2 and the other agent payment protocols

They are not competitors so much as different layers. AP2, the Agent Payments Protocol published by Google, covers mandates and intent: what the user authorised the agent to buy, at what price limit. It spans card, bank transfer and stablecoin. The two are explicitly joined: Google states that "in collaboration with Coinbase, Ethereum Foundation, MetaMask and other leading organizations, we have extended the core constructs of AP2 and launched the A2A x402 extension, a production-ready solution for agent-based crypto payments" (Google Cloud).

A useful split: AP2 answers whether this agent was allowed to spend. x402 answers how the money actually moves for this one request.

FAQ

What is x402 in one line?

An open payment protocol that lets an HTTP server charge for a single request by answering 402 Payment Required with machine-readable terms the client can pay programmatically (x402 docs).

What does 402 Payment Required mean?

In HTTP itself, nothing: RFC 9110 reserves the code for future use. In practice it means either "your account has no credit" from a conventional API, or, when the response carries an accepts array and a PAYMENT-REQUIRED header, an x402 payment challenge.

Who created x402?

Coinbase, announced 6 May 2025, published under Apache-2.0 and now developed in an open specification repository.

How do I buy x402, and is there an x402 coin?

There is nothing to buy. x402 is a specification, like HTTP itself, and payments under it are made in existing stablecoins such as USDC. Treat any "x402 token" as unrelated to the protocol.

How do I test a 402 Payment Required response?

Point a client at a live x402 resource rather than a mock. curl -i https://pay.neuronto.com/echo returns a real 402 with real terms, and that endpoint refunds the payment in full inside the same request, so a client can be exercised end to end for nothing.

What is an x402 facilitator?

A service that verifies signed payment payloads and broadcasts the settlement, so the merchant's server needs no blockchain connectivity, no private key and no node (x402 docs, Facilitator).

Does x402 only work on Base?

No. The protocol is network agnostic and facilitators differ in which networks they settle. Ask the facilitator: GET /supported returns exactly what is live at that moment.

What happens if settlement fails after the server has done the work?

The merchant has spent compute for nothing, which is why verification runs first: it checks the signature, the balance and the window before the handler does any work. It can still fail if the payer empties the wallet in between, so prefer a facilitator that re-simulates the transfer immediately before broadcasting.

Can a facilitator take my money?

Not under the exact scheme. The amount and destination are inside the payer's signature, and the specification states the facilitator cannot modify either.

Sources