In 1991, when Tim Berners-Lee and the IETF were defining the HTTP status codes that still power the web today, they reserved one for a use case that didn't yet exist.
402 Payment Required.
No implementation. No specification. Just a note in the RFC that read: reserved for future use.
Thirty-four years later, the future arrived. In May 2025, Coinbase published the x402 protocol, a concrete implementation of HTTP 402 that turns "payment required" from a reserved stub into a real primitive. By December 2025, it had processed 75 million transactions. Cloudflare and Google Cloud announced integrations. And the protocol quietly became one of the most interesting pieces of infrastructure for anyone building AI agents.
Here's what x402 is, how the mechanics work, and why it matters specifically for autonomous agent systems.
The Problem x402 Solves
Before x402, getting software to pay for something was surprisingly complicated.
If your agent needs to call a paid API, it needs credentials: an API key provisioned through an account signup, billing configured on a dashboard, and a shared secret stored somewhere. If the agent needs to buy something at checkout, it needs a card number, a shipping address, and often CAPTCHA verification designed to stop exactly what agents do.
The underlying issue is that the web was built for humans. Payment flows assume a person who can read a pricing page, click a buy button, and enter card details. Programmatic access was bolted on afterward with API keys and OAuth tokens.
x402 inverts this. It defines a payment standard that lives in the HTTP layer itself, the same layer where the web was built. Agents don't need pre-provisioned accounts or credentials. They negotiate payment terms and settle inline with the request.
How x402 Works
The protocol is straightforward. It follows the standard HTTP request-response cycle with one additional round trip for payment.
Step 1: Initial request. The agent sends a normal HTTP request to a resource or service.
GET /api/generate-report HTTP/1.1
Host: api.example.com
Step 2: 402 response. If the resource requires payment, the server responds with HTTP 402 and a structured payment payload in the response body. This payload includes the amount, accepted currencies, destination address, and a payment nonce.
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"x402Version": 1,
"accepts": [{
"scheme": "exact",
"network": "base-mainnet",
"maxAmountRequired": "1000",
"resource": "https://api.example.com/api/generate-report",
"description": "Report generation fee",
"mimeType": "application/json",
"payTo": "0x1234...abcd",
"maxTimeoutSeconds": 300,
"asset": "0x833589...USDC",
"extra": { "name": "USDC", "version": "2" }
}]
}
Step 3: Payment. The agent's wallet reads the payment requirements, validates the terms, and submits the on-chain transaction. The signed transaction receipt is base64-encoded.
Step 4: Retry with receipt.
The agent retries the original request, this time including the payment proof in the X-PAYMENT header.
GET /api/generate-report HTTP/1.1
Host: api.example.com
X-PAYMENT: <base64-encoded-payment-proof>
Step 5: Service response.
The server verifies the payment receipt against the blockchain, confirms it matches the nonce issued in step 2, and returns the requested resource with a 200 OK.
The whole exchange is HTTP. No redirects to payment pages. No OAuth flow. No account creation. Just a request, a 402, a payment, and a retry.
Why This Matters for Agents
Virtual cards are the right tool for most agent spend today. Universal merchant acceptance, chargeback protection, and a mature compliance layer make them the default choice for any agent transacting in the real economy. That doesn't change with x402.
What x402 opens up is a category of spend that card rails weren't built for: machine-to-machine API transactions where both sides are software, pricing is per-request, and the interaction happens in milliseconds. For this use case, x402 is a genuinely new primitive rather than a workaround.
API keys cover some of this today, but they require pre-provisioned accounts with upfront pricing decisions. An agent can't decide at runtime whether a particular API call is worth paying for, negotiate terms, pay exactly that amount, and move on. x402 can.
From an agent's perspective, what x402 adds to the stack:
No credentials to manage. There's nothing to provision before the agent starts working. The agent encounters a 402, inspects the payment terms, decides whether they're acceptable, and pays or doesn't. The decision happens at runtime, in context.
Granular pricing. Resources can be priced at any granularity: per request, per token generated, per second of compute, per kilobyte transferred. Billing is metered to exactly what the agent consumed. This is more precise than monthly SaaS plans and more flexible than API key tiers.
Instant settlement. USDC on Base settles in under five seconds. There's no 2-3 day card settlement cycle. For high-frequency agent workflows where cash flow matters, this compounds quickly.
Programmatic refusal. An agent can inspect a 402 response and refuse to pay if the terms don't match its policy. If the asking price exceeds the agent's per-call budget, it can abort, try an alternative resource, or escalate to a human. This gives operators meaningful spend control without predefining every possible vendor.
Machine-readable pricing. The 402 response is structured JSON. Agents can parse it, evaluate it, and make decisions against it without any natural language processing of a pricing page.
The Current State
x402 is real and in production, but early.
Coinbase shipped the reference implementation on Base using USDC. Cloudflare integrated x402 into their Workers platform, enabling serverless functions to charge per request natively. Google Cloud announced compatibility. Several API-first companies have implemented the protocol, particularly in the AI/compute space where per-request pricing makes economic sense.
The 75 million transaction figure from December 2025 sounds large, but transaction count is misleading for a protocol that enables sub-cent payments. In dollar terms, x402 volume is a small fraction of what card rails process.
The honest gap is merchant acceptance. x402 works cleanly for:
- ▸API services that build native support
- ▸Developer tools and compute providers
- ▸Digital goods and content APIs
- ▸Agent-to-agent payments where both sides implement the protocol
It doesn't work yet for:
- ▸Most ecommerce merchants
- ▸Airlines, hotels, and travel
- ▸Any merchant that hasn't explicitly built x402 support
The protocol is also USDC-native today. The specification is designed to be currency-agnostic. Nothing in the HTTP negotiation prevents other stablecoins or assets from being specified. But the tooling, wallets, and integrations are largely USDC on Base or USDC on Solana.
x402 vs. Cards: Not Either/Or
The instinct is to frame x402 against card rails as a replacement question. That's the wrong frame.
Cards solve the universal acceptance problem. If your agent needs to book a flight, procure SaaS, or make any purchase at a merchant who hasn't opted into x402, cards are the only option. That's the overwhelming majority of merchants today.
x402 extends the stack into native machine-to-machine payments for services that are built specifically to serve agents. For compute, APIs, and digital services where both sides are software, x402 adds precision and speed that card rails weren't designed to provide.
The practical path for agent platforms is both. Cards cover the real economy. x402 covers the agent economy:
| Use case | Rail | Why |
|---|---|---|
| Ecommerce, travel, SaaS | Virtual cards | Universal acceptance, dispute mechanisms |
| API calls, compute, digital goods | x402 | Per-request precision, instant settlement |
| Agent-to-agent payments | x402 | No human in the loop at either end |
| Regulated industries, high-value transactions | Virtual cards | Chargeback protection, compliance infrastructure |
As x402 merchant adoption grows, the card column will shrink. For now, a wallet that supports both rails is more useful than one optimized for either.
What Operators Need to Think About
If you're building agent infrastructure today and planning around x402, a few practical considerations:
Policy enforcement still matters. The fact that agents can inspect 402 terms and refuse to pay is only useful if you've defined what terms are acceptable. Without a policy layer, agents will either pay for anything (no budget control) or pay for nothing (overly conservative). Your wallet or infrastructure needs to evaluate payment terms against operator-defined rules before signing.
Settlement is fast, refunds aren't. On-chain payment is final. There's no chargeback mechanism for x402 transactions. If an agent pays for a resource and the server returns garbage, the recourse is off-protocol: either a relationship with the provider or a dispute at the application layer. For consequential spend, this is a meaningful difference from card rails.
Wallet custody. x402 requires the agent to hold a funded on-chain wallet. That's a different key management problem than card credentials. You need to think about where keys live, how wallets are funded and drained, and what happens if a private key is exposed.
Auditability. Every x402 payment is an on-chain transaction. The audit trail is immutable. The challenge is that on-chain transaction data isn't structured for financial reporting. You'll need tooling to parse transaction logs into something a finance team can read.
Why x402 Is the Right Long-Term Architecture
Step back from the current limitations and look at the protocol's design.
HTTP is the substrate of the internet. Every agent, every service, every API communicates over it. Building payment negotiation into HTTP means payment becomes as universal as HTTP itself. There's no SDK to install, no payment provider to integrate, no checkout flow to automate. If you can make an HTTP request, you can make a payment.
This is what Berners-Lee left room for in 1991. Not because he knew agents were coming, but because he understood that the web would eventually need a way for machines to pay machines.
The design is also honest about what it is. x402 doesn't try to replace the financial system. It doesn't require merchants to abandon card processing. It adds a new primitive on top of HTTP that works for the use cases where HTTP-native payment makes sense. For agentic systems, that turns out to be a significant and growing share of total agent spend.
Where Signets Fits
Signets wallets support both rails. Agents can hold fiat-backed balances for card spend and on-chain balances for x402 payments, with the same policy layer governing both.
The approach matters because agents rarely live entirely in one world. An agent managing a marketing campaign might spend on Meta Ads via virtual card, call a data enrichment API via x402, and book a vendor lunch via card again. All in the same workflow. Building the infrastructure that makes this work without forcing agents to manage multiple wallets, keys, and policy systems is the problem we're solving.
x402 is early. The ecosystem will grow. The merchants will come. The tooling will mature. But the protocol is right, and the agents that treat it as a first-class payment primitive will be better positioned for how agentic commerce is going to work.
Signets wallets support x402 payments alongside card rails. If you're building agent infrastructure and want to support both, get in touch.