x402 是甚麼，以及為何對機器對機器支付至關重要

HTTP has a status code that almost nobody uses: 402 Payment Required.

It's been in the spec since HTTP/1.1 — reserved "for future use." That future is here. The x402 protocol turns that dusty status code into a real payment flow, and we've built our entire payment gateway around it.

The Problem With Paying for APIs

Right now, if you want to charge for an API, you have a few options:

API keys with a billing account — the client signs up, enters a credit card, gets a key, and you bill them monthly. Works great for humans. Terrible for machines. An autonomous agent can't fill out a signup form, and hardcoding API keys into agent workflows creates security and management headaches.

OAuth + subscription tiers — even more overhead. Token refresh flows, scope management, plan limitations. Fine for SaaS products with human users. Overkill for a machine that just needs to make one call.

Prepaid credits — buy credits upfront, spend them per request. Better, but still requires account creation, and the credits are locked into one service.

All of these assume a human is involved at setup time. That assumption breaks down when the client is an AI agent, a robot, an IoT device, or another service in a microservice mesh.

How x402 Works

x402 takes a completely different approach: payment happens inline with the HTTP request. No accounts. No API keys. No signup. Just pay and go.

Here's the flow:

Step 1 — the client makes a normal HTTP request to the API endpoint.

Step 2 — the server responds with 402 Payment Required and includes payment details in the response headers: how much, which token, which chain, where to send it.

Step 3 — the client makes the payment on-chain (or provides proof of a payment already made).

Step 4 — the client retries the original request, this time including the payment proof in a header.

Step 5 — the server verifies the payment and serves the response.

That's it. The client never created an account. The server never stored a credit card. The payment is settled on-chain, verifiable by both parties, and the whole flow happened over standard HTTP.

Why HTTP-Native Matters

The genius of x402 is that it works with existing HTTP infrastructure. Proxies, load balancers, CDNs, monitoring tools — they all understand HTTP status codes. A 402 response flows through the same infrastructure as a 401 or a 403. No special protocol, no WebSocket upgrade, no custom transport.

This means any HTTP client can be taught to handle x402 payments. A Python requests call, a curl command, a browser fetch — if it speaks HTTP, it can speak x402.

For machine-to-machine scenarios, this is transformative. An AI agent making an API call doesn't need pre-provisioned credentials for every service it might use. It just needs a wallet with funds and the ability to handle a 402 response. First time calling a new API? Pay the 402 and you're in.

How We Built On It: The Spraay Gateway

Spraay's payment gateway at gateway.spraay.app is an x402-native service. Every paid endpoint responds with a 402 challenge that tells the caller exactly what to pay.

The gateway handles batch payments — send USDC to up to 200 recipients in a single on-chain transaction on Base. The x402 flow means any HTTP client can use it without signing up:

1. Call the batch endpoint
2. Receive a 402 with the fee amount and payment address
3. Pay the fee on-chain
4. Retry with the transaction hash in the header
5. Receive the unsigned batch transaction to sign and submit

We support multiple chains for the payment itself (Base, Ethereum, Solana), and the gateway verifies payment on whichever chain the client used.

The fee structure is simple: 0.3% of the batch amount, with a minimum. The client knows the exact cost before paying because the 402 response spells it out.

x402 for Agents and Robots

This is where x402 really shines. We've integrated Spraay's gateway with:

• AI agent frameworks — our payment tools are merged into NVIDIA's NeMo Agent Toolkit, Google's ADK community, and the Strands Agents documentation. Agents in these frameworks can handle x402 challenges natively.

• Robot fleet management — our rmf-spraay bridge dispatches tasks through the gateway using x402. A robot fleet operator's software pays the 402 challenge, dispatches a task, and settles the payout — all over HTTP.

• E-commerce plugins — for platforms where x402 per-request payment doesn't make sense (a WordPress plugin can't pay a 402 on every batch call), we added API key authentication alongside x402. B2B clients get a key that bypasses the challenge. Same gateway, flexible auth.

The flexibility is the point. x402 is the default for machine clients that can handle it. API keys are there for platforms that can't. Both hit the same endpoints, same settlement, same on-chain verification.

The Broader x402 Ecosystem

We're not the only ones building on x402. Coinbase has championed the protocol, and an ecosystem of x402-compatible services is growing. The pattern is consistent: HTTP endpoint, 402 challenge, on-chain payment, proof-of-payment header, service delivery.

What we've added to the ecosystem is batch payment infrastructure. Most x402 implementations handle simple one-to-one payments (pay $0.05, get an API response). Our gateway handles one-to-many: pay once, distribute to hundreds of recipients. That opens up use cases like payroll, vendor payments, revenue sharing, and fleet settlement that a simple per-request payment model can't cover.

Why We Think This Is the Future

Every trend points toward more machines talking to more machines, with less human involvement in each transaction. AI agents are calling APIs on your behalf. IoT devices are negotiating with services. Microservices are settling with each other.

All of these need a payment flow that doesn't require a human to set up an account first. x402 provides that: an open, HTTP-native, on-chain-verified payment protocol that any machine can use.

We've bet Spraay's entire architecture on it, and after months of building integrations across robotics, e-commerce, DeFi, and AI agents, the bet is holding up. The protocol works. The infrastructure works. The use cases are real.

If you're building something that needs to charge for API access or settle payments between machines, take a look at x402. The 402 status code has been waiting since 1997. It's ready now.

Spraay Protocol is multi-chain batch payment infrastructure built by Plagtech. Our x402 gateway is live at gateway.spraay.app. Learn more at spraay.app.