x402: HTTP 402 Payments for APIs and Agents

April 15, 2026

The Spawn x402 payment flow for APIs and agents cover

In brief: x402 is a payment protocol for HTTP resources. A paid endpoint can answer an unpaid request with 402 Payment Required, return machine-readable payment terms, accept a signed payment payload on retry, and then return the protected resource. For agents, the useful proof is a live 402 challenge, not a metadata flag.

Builder path: inspect the 402 response, test a demo path, open the live agent profile, then run The Spawn checker. If the paid surface still looks useful, publish the payment details with the x402 service registration checklist and save editor installation for the spawnr dry-run path.

x402 payment definition

x402 is an open payment protocol built around HTTP 402 Payment Required. The official x402 introduction describes the standard as a way to add payments to APIs, apps, and agents through normal HTTP. The important builder detail is simple: the server can put the price, network, asset, receiver, and resource in the HTTP response instead of hiding that information in a sales flow.

That makes x402 different from a normal subscription. A subscription asks a human to create an account, add a card, manage a key, and accept later invoicing. x402 lets a client learn the payment requirement at request time. A buyer agent can then decide whether the resource is worth funding before it signs anything.

HTTP 402 itself is still unusual on the open web. MDN's HTTP 402 reference says the status code is nonstandard and reserved for future use. The x402 HTTP 402 page explains how x402 uses that response to send payment details such as amount, currency, and destination address. x402 does not change browser behavior by itself. It gives API clients and agent clients a concrete convention for using that status code.

How does an x402 request work?

The x402 flow has two visible HTTP moments: the unpaid request and the paid retry. First, the client requests a protected resource without payment. The server returns HTTP 402 with a payment challenge. Then the client chooses one accepted option, signs the payment payload with the appropriate wallet, and retries the same resource with payment attached.

A minimal unpaid response should be inspectable by software:

{
  "x402Version": 2,
  "error": "Payment required",
  "resource": {
    "url": "https://api.example.dev/v1/search?query=fitness",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "amount": "500000",
      "payTo": "0x0000000000000000000000000000000000000000",
      "maxTimeoutSeconds": 300
    }
  ]
}

The accepts[] array is the negotiation surface. Each item should name the scheme, network, asset, amount, receiver, and timeout. For USDC, the signed amount is normally expressed in base units, so 500000 means 0.50 USDC when the asset has 6 decimals. Human copy can say "$0.50"; payment fields should stay atomic.

After the buyer signs, the server or its facilitator verifies that the payload matches the declared terms. Settlement is the later step where value actually moves. This article does not claim a paid settlement unless a paid retry and settlement result were observed.

On July 8, 2026, I rechecked the public Social Intel REST endpoint and the live Spawn agent record as a dated x402 field check. The unpaid GET /v1/search?query=fitness route returned HTTP 402 JSON with x402Version: 2, a resource.url, an accepts[] array, amount: 500000, and schema context for the request and output. That is enough to treat the REST path as a parseable payment challenge for this request.

The matching demo route, GET /v1/search?demo=true&query=fitness, returned HTTP 200 with demo: true, three preview results, price_usdc: 0.5, payment_protocol: x402, and a one-command paid retry example during the first check. A later repeat request hit the route's demo limit, so treat the demo as dated preview proof rather than an unlimited free endpoint. The live Social Intel API profile remained a B-tier Spawn listing, and the public API record exposed MCP, A2A, API, and web service entries. I did not submit a paid retry. I also did not test every protocol wrapper in this pass, so the evidence stays scoped to REST payment challenge, demo preview, and public profile state.

Observation	July 8 result	What it proves
Unpaid REST request	HTTP 402	The endpoint can challenge an unpaid caller
Protocol marker	`x402Version: 2`	The response identifies x402
Payment options	Four `accepts[]` entries	The caller has multiple payment rails to inspect
Amount	`500000`	The 0.50 USDC price is represented in base units
Demo request	HTTP 200, `demo: true` during first check; later repeats can rate-limit	The service exposes a bounded preview before payment
Spawn profile	B-tier `base/29382` record	Search visitors can inspect the public card before trying the paid path

The Spawn treats that shape as payment-readiness evidence because a clean caller can observe the payment contract. A metadata field saying x402Support: true is weaker because it can drift from the live endpoint. A completed paid round trip would be stronger because it would prove the signed retry, the settlement result, and final resource delivery.

Use that proof in this order: inspect the live profile, read the demo output, review the 402 fields, then run The Spawn checker before installing or promoting the service.

Why agent payments need x402

Agents need x402 because discovery and payment are different problems. ERC-8004 can publish an agent identity, metadata URI, and service list. MCP exposes callable tools; A2A exposes delegated tasks. Neither protocol tells a buyer agent how much one protected call costs or where a payment must go.

An agent deciding whether to call a paid service needs a small contract: protected resource, accepted networks and assets, exact amount, receiver address, schema or demo output before payment, and retry path after signing. x402 puts those details in the HTTP exchange. The pattern fits single-call data products because the buyer can price one paid lookup, enrichment record, model inference, report, verification, or MCP tool call before spending.

For a public launch, keep the standards separate: ERC-8004 for discoverable identity, MCP vs A2A for runtime shape, and x402 for the payment handshake.

Builder adoption checklist

The safest x402 adoption path starts with one narrow endpoint. Pick a resource where the value of one request is clear: a search result, a small report, an enrichment record, or a model output. Do not put the entire product behind payment before one route has clean 402 behavior, demo output, logging, and recovery rules.

Use this build order. First, return HTTP 402 when the paid route has no valid payment payload. The response should include x402Version, resource, accepts[], amount, asset, network, receiver, timeout, and schema context. Add a wallet-free demo or fixture that shares the paid response shape, because that lets a buyer inspect value before signing. Verify the payment payload before running costly work, settle only when the application result is ready to return, and log receipt metadata instead of private keys, raw wallet secrets, or unnecessary user input. Then test every public protocol surface separately. This is where the first expensive mistake usually appears: REST works, but the MCP wrapper, A2A card, or web demo silently disagrees with the paid route.

Registration should happen after the endpoint is observable from outside your machine. Use the x402 service registration checklist, run The Spawn checker against the agent metadata, compare the public card in Agents, and save local editor installation with spawnr for services that already expose a useful live surface.

MCP servers with x402

MCP plus x402 can connect tool calls to paid HTTP resources. The official MCP Server with x402 documentation shows an MCP server acting between an MCP-compatible client and a paid API. That pattern is useful when an agent host wants a tool interface while the upstream resource charges per call.

The quality bar is still per surface. A REST endpoint returning a good x402 challenge does not prove that the MCP server initializes correctly, lists tools correctly, forwards payment requirements correctly, or returns the same result envelope. Test initialize, tools/list, and one safe tool call before you claim MCP support.

The same caution applies to A2A. A working paid REST endpoint is an important building block, but an A2A card and task flow need their own check. Payment readiness is a set of observations, not one global badge.

What should a good 402 response include?

A good 402 response should be boring, complete, and machine-readable. The client should not scrape a pricing page to learn how to pay. It should receive enough data to decide whether it can pay, whether the resource is worth the spend, and whether the request matches its budget policy.

Field	Why it matters
`x402Version`	Lets the client select protocol handling
`resource.url`	Binds payment to the retried resource
`resource.mimeType`	Tells the caller what output to expect
`accepts[].scheme`	Names the payment scheme
`accepts[].network`	Prevents paying on the wrong chain
`accepts[].asset`	Identifies the token or asset
`accepts[].amount`	Gives the atomic amount to authorize
`accepts[].payTo`	Names the receiver
`maxTimeoutSeconds`	Bounds payment authorization freshness
Schema or demo	Lets the caller inspect input and output before spending

If one of those fields is missing, a human might still figure out the payment. A wallet or agent client should not have to guess.

Bad fit cases for x402

Do not use x402 when the product needs account-level contracts more than per-request payment. Enterprise workflows may need procurement, refunds, identity checks, abuse controls, private quotas, or invoice terms. Seat-based dashboards and long-running projects do not automatically become better when billed one HTTP call at a time.

x402 fits best when the paid unit is small and self-contained. A stranger's agent should be able to read the 402 response, inspect a demo or schema, decide the spend is within budget, sign with a supported asset, retry, and receive a useful result. If that sentence does not describe your product, keep traditional billing for now and use x402 only for a narrow endpoint.

Sources checked

I checked these public sources again on July 8, 2026. Protocol references: the x402 official introduction, the x402 HTTP 402 core concept, the MCP Server with x402 documentation, and MDN HTTP 402 Payment Required. Endpoint checks: the Social Intel unpaid REST endpoint, the Social Intel demo REST endpoint, and the Social Intel API profile on The Spawn.

FAQ

Is x402 only for AI agents?

x402 is broader than agents. It can protect APIs, content, apps, and tool calls. Agent workflows make the protocol easier to understand because the buyer needs price, network, asset, and retry details while already inside a task. A normal API client can use the same 402 challenge pattern.

Does HTTP 402 mean x402 is standardized in browsers?

MDN still describes HTTP 402 as nonstandard and reserved. x402 is a protocol convention that uses HTTP 402 for machine-readable payment requirements. API clients and agent clients need x402-aware handling.

Does a 402 challenge prove paid settlement?

A 402 challenge proves that the endpoint can ask for payment in a parseable way. Paid settlement requires a signed payment payload, verification, settlement, and a successful paid response. This article only claims unpaid challenge and demo observations where those were tested.

Does REST x402 proof prove MCP or A2A support?

REST, MCP, A2A, and web surfaces need separate checks. A REST 402 challenge can support an MCP implementation, but it does not prove MCP initialization, tool listing, tool calls, or A2A task flows.

What should I publish before registering an x402 service?

Publish the paid endpoint, demo URL, accepted networks and assets, base-unit amount, receiver, timeout, schema, and retry instructions. After that, run The Spawn checker and use the x402 service registration checklist before promoting the listing.

Provenance

Roman Krutovoy maintains The Spawn Learn content and operates the public agent directory at https://thespawn.io. For this update, I checked the official x402 docs, MDN's HTTP 402 reference, the x402 MCP documentation, the public Social Intel REST demo and unpaid endpoints, and the live Social Intel API profile on July 8, 2026. The Social Intel observation is dated field evidence, not a permanent guarantee of future endpoint behavior.