Coinbase built it. The Linux Foundation runs it. Visa, Mastercard, Stripe, and Google are founding members. Here is what x402 replaces, what it does not, and what still has to be built before agents can actually pay at scale.

HTTP 402 is the status code that sat unused for 30 years. Payment Required. The web's original architects wrote it into the spec in 1991 and never wired it up, because the infrastructure for pay-per-request did not exist and the business model behind free-to-browse, pay-somewhere-else worked too well to disturb. The code became a joke for a generation of engineers. Then, in late 2025, Coinbase wrote a protocol that finally uses it. Ten months later, the Linux Foundation runs it, and Visa, Mastercard, Stripe, and Google are at the table.

That is the short version. The longer version, which is the one that matters for anyone building in payments or agentic commerce, is that x402 is the first serious attempt to put a payment layer inside HTTP itself. Not a checkout page. Not a gateway SDK. A request-response handshake where the server says "pay to continue" and the client pays, in line, without leaving the transaction. The rest of the web is about to have a real argument with that.

At the spec level, x402 is small. A client makes a request to a resource. The server responds with HTTP 402 Payment Required, plus a JSON body describing the payment options. The client selects an option, constructs a payment payload (which today is most commonly a USDC stablecoin transfer on an L2), and re-sends the request with the payment attached as a header. The server verifies the payment and returns the resource.

That is the whole loop. It is deliberately simple, because the protocol is not trying to be a payment processor. It is trying to be a wire format. The processors, the settlement layers, the compliance rails all sit underneath.

What makes it different from a checkout page is three things.

First, it is machine-native. Humans do not fill out a 402 response. Agents do. The payment selection, the signature, the retry, the whole loop executes in code without a form, a redirect, or a session cookie. That is the entire point. If an agent has to open a browser and type a card number, the internet does not have a payment layer. It has a stack of manual checkouts behind an API.

Second, it is protocol-level. A checkout page is an application. A payment processor is a company. A payment protocol is a specification that many parties implement independently. The difference matters because the incentives change. As we mapped in our agentic commerce protocol overview, the protocol layer is where interoperability lives. Applications compete. Protocols cooperate. x402 is a bet that the payment layer for agents will be a protocol, not a product.

Third, it is value-neutral at the handshake. The 402 response can offer USDC, USDT, a fiat rail, or whatever a future implementation supports. The spec does not hardcode a settlement currency. That matters because it means card networks, stablecoin issuers, and real-time-payment rails can all sit inside the same framework without the protocol picking winners. Whether that stays true as the spec evolves is one of the more interesting open questions, which we will come back to.

The x402 idea is older than the protocol. Pay-per-request, micropayments, streaming money, all of those have been around since the 1990s. The reason they never shipped was not technical. It was that humans cannot do a pay-per-request flow without going insane. Every request is a decision. Every decision is friction. Every friction kills the flow.

Agents do not care. An agent can evaluate ten thousand 402 responses, select the cheapest, sign the payload, and move on in the time it takes a human to read one. The economics that make micropayments unbearable for humans are exactly the economics that make them rational for machines.

That is the "why now" in one sentence. Agents changed the demand side. Without agents, there was no reason to fix HTTP's missing payment layer. With agents, there is suddenly no substitute for it.

The supply side caught up at the same time. Stablecoin settlement on L2s is now cheap enough and fast enough that a sub-cent payment for a single API call is operationally viable. That was not true five years ago. It is barely true now. But it is true enough that the protocol can ship with a working implementation, and that is what changed.

Coinbase wrote the original x402 spec and the first reference implementation. The initial design was opinionated toward stablecoins on L2, unsurprisingly, because that is the layer Coinbase cares about and the one most x402-shaped problems could be solved on today. The spec was open-source from launch.

In late March 2026, Coinbase transferred x402 to the Linux Foundation, where it now lives as the x402 Foundation. The founding members list was the story. Visa, Mastercard, Stripe, and Google are all at the table. That is not a protocol sitting quietly on GitHub. That is a protocol with the four largest players in global payments and one of the two largest search-and-AI platforms in the room on day one.

We covered the handoff when it happened, in our analysis of the Linux Foundation transfer. What has changed in the weeks since is that the member list gives the protocol cover it did not have as a Coinbase project. A card network can integrate with x402 now without appearing to endorse a crypto-native settlement rail. That is a quiet but important shift.

The governance model matters. The Linux Foundation runs specifications the way standards bodies are supposed to: members contribute, a technical committee reviews, the spec evolves in the open, and implementations are free to ship against any version. That is different from how Visa and Mastercard typically govern their agent protocols (more on that below), and it is the reason x402 has a path to becoming actual infrastructure rather than a vendor tool.

There is a pattern in payments press releases where "live" means "a single demo transaction happened." x402 is past that stage, but not far past it.

Nevermined shipped the first production integration we have seen that ties x402 together with a card-network rail. Their implementation routes an agent-originated transaction through x402 for the negotiation and payment handshake, then settles on Visa Intelligent Commerce with VGS handling tokenisation. We wrote about that stack integration when it shipped. It is not a toy. It is not a roadmap. It is code in production handling real value.

Beyond Nevermined, the live data gets thinner. Operators running data marketplaces on x402 report early volume that is more diagnostic than impressive. One marketplace operator we have engaged with has reported 1,183 agent probes, five settlements, and $0.11 in total revenue. That sounds bad. It is not. It is exactly the kind of number a new protocol generates in its first months of production use, and the ratio of probes to settlements reveals the actual bottleneck.

Agents are hitting the 402 responses. They are not bouncing at the payment. They are bouncing at the evaluation. Before an agent pays, it decides whether the resource is worth paying for, and the signals it has to make that decision with are weak. That is not a payment protocol problem. It is a trust and discovery problem one layer up. And it is the single biggest hint about what has to be built next.

x402 is not the only agentic commerce protocol. It is one of four that matter, and it does not compete with the other three in the way a casual reading of the press releases might suggest. The four are layered, not substitutable.

Agent identity and trust sits at the top. Who is this agent? Who authorised it? Is it allowed to spend against this account? Visa's Trusted Agent Protocol and a handful of other efforts, covered in our review of the Visa approach, live at this layer. x402 does not try to solve this. It assumes it.

Agent intent and action sits below that. What does the agent want to buy? Under what constraints? Who can it negotiate with? Google's AP2 and Mastercard's verifiable-intent work operate here. Again, x402 does not try to solve this. It accepts the intent as input.

Agent payment is where x402 lives. The client wants a resource. The server wants money. The payment handshake, the settlement reference, the receipt. This is the thinnest layer and the one nobody had a standard for until x402.

Settlement sits underneath. Stablecoins, card rails, real-time-payment rails, bank transfers. x402 is protocol-agnostic about which settlement layer runs underneath a given transaction. That is the spec's design choice, and it is why the Visa/Mastercard presence on the founding member list is coherent rather than contradictory.

Our Q1 protocol map laid out the full landscape. The short version: x402 owns the payment handshake. Other protocols own the layers above and below. Whether they all play well together is a live question that the next twelve months will answer.

Four unsolved problems are bigger than the protocol itself. Any one of them could decide whether x402 becomes infrastructure or an interesting footnote.

Trust scoring. The marketplace data we referenced above is the single clearest signal. Agents are not bouncing at payment, they are bouncing at evaluation. The missing layer is an x407-style trust-scoring mechanism that lets an agent know whether the resource behind a 402 is worth paying for before it pays. Nobody has shipped that yet. Several proposals exist. The protocol that solves it becomes the credit-rating agency for agent commerce, which is a very valuable seat.

Stablecoin dependency. Today, most x402 traffic settles in USDC on an L2. That works. It also concentrates risk in a single stablecoin, a single issuer, and a regulatory regime that is still being written. The stablecoin side of this is moving fast, and we tracked the settlement-layer shift in our coverage. If USDC becomes a choke point, the protocol has to route around it. If the card networks want to run x402 traffic on their own rails, the spec has to accept that gracefully. The first real stress test is probably twelve to eighteen months out.

Dispute resolution. A card transaction has chargebacks, representment, arbitration, and Reg E. An x402 transaction has none of that today. When an agent pays for a resource that turns out to be broken, spam, or fraudulent, who handles the dispute? The agent's operator? The merchant? The stablecoin issuer? A neutral body that does not yet exist? This is the ugliest open problem, and it is the one regulators are going to ask about first.

Liability for bad agent behaviour. An agent with a wallet can go wrong in more ways than a human with a card. It can be hijacked, prompt-injected, or simply misconfigured. The question of who bears the loss when an agent pays for the wrong thing is not answered in the x402 spec, and it should not be, because it is a regulatory question, not a protocol one. But until someone answers it, serious institutional adoption stays slow.

The uncomfortable question for the card networks is whether x402 displaces them or co-opts them. The answer is neither clean.

In the pure stablecoin-settled flow, x402 routes around card networks entirely. An agent pays a server in USDC. No Visa, no Mastercard, no interchange. If that flow becomes the default for agent-originated transactions, the card networks lose a large category of payments to a protocol they did not design and do not control. That is the worst case for them, and it is the reason Visa and Mastercard are founding members. A seat at the table is cheaper than an external disruption.

In the network-routed flow, x402 does the handshake and the card networks still settle. An agent hits a 402, selects a card-rail option, and Visa or Mastercard runs the authorisation underneath. The card networks preserve the interchange stream. x402 becomes the front door, not a competitor. That is the best case for them, and it is the reason they contributed to the spec rather than building a competitor.

Which flow wins is not decided by the protocol. It is decided by the settlement economics. Stablecoin settlement is cheap. Card settlement is rich. Merchants and processors will pick the one with better unit economics for their use case, and for most agent-originated transactions today that is stablecoins. As x402 matures, that calculus will get more contested. Fiserv's positioning on issuer-side agentic commerce is one early signal of where the middle ground sits.

The honest read is that x402 will co-exist with the card networks for a long time, and it will displace them in corners of the stack they care about less. That is not nothing, and it is not everything.

Four milestones will tell us which direction x402 goes from here.

First, whether the Linux Foundation member list keeps growing in a credible direction. Banks, acquirers, and regional payment networks joining would signal the protocol is becoming infrastructure. Crypto-native firms joining is ambient. Banks joining is load-bearing. The tracker we are launching alongside this piece will follow that closely.

Second, whether a trust layer ships. Someone will build the x407 equivalent, and when they do, agent discovery and evaluation become native features rather than external products. If that layer ships from inside the Linux Foundation Foundation, the stack stays coherent. If it ships from outside, the stack fragments.

Third, whether regulators take a position. The CFPB, the FCA, and the European Commission have all started thinking about agentic payments. The first formal position any of them takes will reshape the adoption curve. Our piece on the FCA's early work sketched what that looks like.

Fourth, whether one of the big merchants picks it up. Shopify's storefronts, Walmart, Target, or any of the brands already building inside ChatGPT. If a major merchant adds x402 as a first-class payment option alongside card and Apple Pay, the protocol moves from infrastructure layer to consumer-visible. Until that happens, it is a backend protocol with big implications. After it happens, it is a competitor to everything.

If the payment layer of the internet becomes protocol-native, what is left of the checkout as a product category?

Charlie Major is a Product Development Manager at Mastercard. The views and opinions expressed in Major Matters are his own and do not represent those of Mastercard.