x402 Puts Payment Inside the HTTP Request. The Checkout Flow Was a Control Point.

Visa, Mastercard, Stripe, AWS, and Coinbase just moved the agent payment standard under the Linux Foundation. Here's how 402 Payment Required actually works, and what to build around it before your agent gets a wallet.

HTTP has had a status code reserved for payments since 1997. Code 402, Payment Required, sat in the spec for almost thirty years marked "reserved for future use" while the web built checkout pages, card forms, and subscription billing around it instead.

On July 14, the Linux Foundation announced that the x402 Foundation is operational and that Coinbase has completed its contribution of the x402 protocol, the standard that finally puts 402 to work. Forty organizations signed on. The premier member list reads like the seating chart at a payments industry summit: Visa, Mastercard, American Express, Stripe, Adyen, Fiserv, AWS, Google, Cloudflare, Shopify, Coinbase, Circle, Ripple, and the Solana and Stellar foundations, all in the same working group.

When the card networks and the crypto companies agree on something, it's worth asking what they agreed on. The answer: your agent should be able to pay for things without you in the room.

The part everyone is underplaying

Here's the position I'll defend for the rest of this piece. The interesting thing about x402 is not the crypto rails, and it's not the micropayments dream getting yet another revival. It's that the protocol deletes the checkout flow, and the checkout flow was never just friction. It was the last moment in digital commerce where a human paused, looked at a number, and confirmed that money was about to move.

x402 replaces that moment with a header. A server says "this costs something," an agent signs a payment, and the request goes through. No cart, no confirmation screen, no thumbprint. That's the entire pitch, and it's a genuinely good pitch for machine-to-machine commerce. It's also the removal of a control point that fraud teams, budget owners, and ordinary people have leaned on for thirty years.

Nothing replaces that control point by default. Whatever spending policy you wire around your agent is now the only checkout there is.

How the protocol actually works

The mechanism is small enough to hold in your head, which is part of why it's winning. The flow runs in four steps:

1. A client (your agent, your script, anybody's crawler) requests a resource. The server responds with status 402 and a payment-required header describing what it accepts: price, payment scheme, network.
2. The client picks one of the offered payment requirements, constructs a signed payment payload, and retries the same request with the payload attached in a payment header.
3. The server verifies the payload, either locally or by handing it to a "facilitator" service that checks validity for that scheme and network.
4. The server settles the payment (again, directly or through the facilitator), then returns 200 with the resource and a settlement receipt in a response header.

That's it. Payment becomes a retry with an extra header. The facilitator role matters more than it first appears: it's the piece that lets an API seller accept payments without running any settlement infrastructure themselves, and it's also a brand-new intermediary that sits in the middle of every transaction. Remember that for the limitations section.

The Linux Foundation's announcement stresses that the protocol supports payment types "from traditional cards to stablecoins." In practice, the live deployments today lean heavily on stablecoins. Circle's VP put the selling point plainly in the launch materials: with x402 and USDC, agents can make payments that clear in seconds for a fraction of a cent. The card networks are in the room because they intend to be a scheme inside the standard, not because they already are one everywhere.

This is further along than a five-day-old foundation suggests

The foundation is new. The deployment is not. Months before the operational launch, AWS shipped a preview of Bedrock AgentCore Payments, a managed service built on x402. It handles the whole client side of the flow for an agent: receiving the 402, signing through a connected wallet (Coinbase CDP or Stripe's Privy), enforcing session-level spending limits, and keeping an audit trail. AWS also exposes a Coinbase-run "x402 Bazaar" through its gateway, which the AWS documentation describes as more than 10,000 pay-per-use x402 endpoints an agent can discover and call.

Read that again from the seller's side. There is already a directory of thousands of services priced for machines, and the largest cloud provider has already built the buyer's wallet. Mastercard is shipping something it calls Agent Pay for Machines. Stripe says outright that it wants agents to become economic actors on the internet.

The trend under all of this is the one I keep returning to: the industry has decided agents are first-class participants in commerce. x402 is what that decision looks like as infrastructure.

Put this into practice

You don't need a wallet-wielding agent to get value from understanding x402 this week. Start on whichever side of the transaction you actually live on.

If you sell an API or paid content:

1. Read the spec and reference implementation. It's a small protocol; an afternoon covers it.
2. Wrap one low-stakes endpoint in a 402 flow using the reference middleware and a testnet facilitator. Don't touch your billing system. The goal is to learn the shape of payment requirements, payloads, and settlement receipts while mistakes are free.
3. Decide your pricing unit now. Per-request pricing is what the protocol wants, and it will fight your seat-based or tiered model. That product conversation takes longer than the integration.

If you build agents that consume paid services:

1. If you're on AWS, the AgentCore Payments preview is the lowest-friction path: connect a test wallet, set a session spending limit, point the agent at a Bazaar endpoint, and watch the audit trail it produces.
2. Set spending limits as if they're the only safety mechanism, because they are. Per-session caps, per-tool caps, and an expiry. An agent budget with no ceiling is an incident report with no timestamp yet.
3. Treat the wallet key like a production credential, which means it never sits in the agent's context or environment where a prompt-injected model can read it. Signing should happen in infrastructure the model can call but cannot see into.

The test I'd apply before going past testnet: can you state, in one sentence, the maximum amount of money your agent can lose in its worst hour? If you can't, the integration isn't done.

Honest limitations

The governance is days old. The protocol has real production miles through Coinbase's ecosystem, but the vendor-neutral version of it, the one with 40 members voting, has existed since Tuesday of last week. Standards bodies change things. Early adopters should expect churn in schemes, headers, and facilitator APIs.

Implementations are uneven. The stablecoin path is paved; the "traditional cards" path the press release promises is mostly intention. If your business needs card settlement, chargebacks, and the consumer protections that come with them, x402 today does not hand you those. Machine payments over stablecoins settle fast precisely because they skip the dispute machinery. That's a feature for a 200-microservice data pipeline and a serious problem for anything a consumer might regret.

Stablecoin settlement will start a compliance conversation at any company with a finance department, and that conversation is measured in quarters, not sprints.

The facilitator is a new trust dependency. It verifies, it settles, and it sees your transaction flow. The protocol lets you self-settle, but the convenience gradient points at hosted facilitators the same way it pointed at hosted email. Know who yours is and what happens when it's down.

And the biggest one: removing the human confirmation moment moves all the risk to agent judgment, and agent judgment is exactly the thing this industry has spent 2026 learning not to trust unsupervised. A prompt-injected agent with a funded wallet is a jackpot waiting for a jackpotter. Spending caps bound the damage; they don't prevent it.

What to do with this

A payment standard with the whole card industry behind it doesn't need your belief to succeed, and the 402 status code isn't going back to sleep. The question that's actually open is the control layer: budgets, approvals, attribution, and refund stories for actors that click "confirm" a thousand times a minute. Nobody has won that layer yet. Some of it will get built into the protocol; more of it will get built by whoever moves first.

Read the spec, run the testnet flow, and figure out what your agent's checkout should look like before the default answer becomes "it doesn't have one." If you've already put x402 into production on either side of the transaction, I want to hear what broke first.

Sources: Linux Foundation press release, x402.org, coinbase/x402 on GitHub, AWS Bedrock AgentCore Payments documentation, InfoWorld coverage.