SASAME S.R.L. — research
x402 revives HTTP's dormant 402 status code to let software agents pay per API call in stablecoins with no accounts or subscriptions. Technically live; economically still early.
For most of the web's history, the HTTP 402 'Payment Required' status code sat unused — defined in the original HTTP spec but never standardized into a working payment flow. x402 changes that: when a client (often an AI agent) requests a paywalled resource, the server returns a 402 with payment instructions, the client signs and sends a small stablecoin payment, and the resource is returned in the same request-response cycle. There's no signup, no stored card, no monthly invoice — just a machine-speed micropayment attached to an ordinary HTTP call.
The appeal for AI agents is specific: an autonomous agent that needs to call dozens of different data APIs, tools, or other agents' services doesn't want to negotiate contracts or manage separate accounts with each one. Per-call stablecoin payment, settled on a blockchain, fits that pattern better than subscription billing or card processing, which assume a human is setting up the relationship in advance. This is why x402 is discussed less as 'crypto payments' and more as plumbing for an agent economy — one where an AI can discover a paid MCP tool or API and pay for exactly the calls it makes.
As of 2026, the honest answer to 'can AIs pay other AIs' is yes, technically, and increasingly with infrastructure backing — but the economic picture is mixed. Genuine agent-to-agent commercial demand, where independent parties transact because an agent actually needs a paid service, coexists with a large amount of testing, demo, and pilot traffic that isn't representative of sustained real-world usage. Teams evaluating x402 should treat published transaction-volume figures skeptically and look for evidence of repeat, externally-initiated, non-affiliated activity rather than one-off proofs of concept.
Developers building in this space — including smaller software shops doing MCP server, Claude/agent tooling, and automation work, such as Romania-based SASAME S.R.L. — are generally best served treating x402 as one payment option to evaluate alongside conventional rails (e.g., Stripe) rather than a wholesale replacement, at least until real transaction volume, dispute handling, and wallet-security practices mature further.
What is x402?
x402 is an open payment protocol, originally introduced by Coinbase, that uses the HTTP 402 'Payment Required' status code so a server can ask a client for a small on-chain payment (typically a stablecoin like USDC) before returning a response. It is designed so an API call and its payment happen in a single HTTP round trip, without accounts, API keys, or invoices.
Can an AI agent actually pay another AI agent using x402 today?
Yes, mechanically: an agent holding a crypto wallet with stablecoins can complete an x402 payment flow to another agent's paywalled endpoint automatically. Whether this happens at meaningful scale in production, versus mostly in demos, testnets, and pilot integrations, is a separate and less settled question.
Why not just use a credit card or Stripe for AI agent payments?
Card rails require merchant accounts, KYC, chargebacks, and settlement delays that don't fit a model where an agent might make thousands of sub-cent calls to many different, unvetted counterparties. x402 targets that gap with stablecoin micropayments that settle immediately, though it trades away chargeback protection and card-network dispute handling.
Is x402 the only machine-payment protocol for AI agents?
No. It sits alongside related efforts such as Google's Agent Payments Protocol (AP2), which focuses more on authorization and intent-verification for agent-initiated purchases, and various wallet/agent-identity frameworks. x402 is notable for being narrowly scoped (pay-per-request) and for early support from infrastructure providers like Coinbase and some cloud/CDN vendors.
What are the main risks or limits of agent-to-agent payments?
Key concerns include wallet key security if an agent is compromised, the risk of runaway spending without human-in-the-loop limits, immaturity of dispute resolution compared to traditional payment rails, and genuine uncertainty about how much of current x402 transaction volume reflects real economic demand versus testing, demos, or wash activity.