Part 1: The tale of The Machine That Couldn’t Pay — Agents and 402

For approximately thirty years HTTP 402: Payment Required, stayed dormant, waiting for its chance to shine.

It was originally created in 1991 with specification for a future in which websites could natively ask for money. As there was no such native way for machines to pay (or none was created) it was abandoned. What took its place was human eyes entering credit card information, with security features and reconciliations done to make sure everything was alright.

A few years ago, with the advance of AI, Agents were created. They are writing code, scraping websites, find vulnerabilities and run whole workflows on their own. However, they are still under-age and illegal in the eyes of our payment system. They could impersonate a human but that would be illegal in most cases and also unproductive.

To mitigate this situation, the industry brought to life the 402 status code via x402, pioneered by Coinbase and integrated via Cloudflare’s web infrastructure and new machine payment protocol. Although tech quickly caught up and is ready to plug agents to pay for our groceries, we realized that the plumbing of the Western payment system is not as ready yet for this change.

1. What Is HTTP 402 and How Is It Supposed to Work?

Imagine you sending your agent to buy you the latest album of Kanye West, the agent finds a reputable seller and asks to buy it. You do not even need to pull out your wallet.

The seller’s server receives this request and replies with a clean response: HTTP 402 Payment Required.

Together with this response some metadata arrive, fully machine readable which define things like the price and instructions on how to pay. The agent now is responsible now to process this response and make the suitable arrangements to pay for it. When the agent succeeds, it returns back to the seller and provides the confirmation of payment.

All this hopefully in less than a second.

Attached to that response is a machine-readable payload containing a price tag (e.g., $0.05) and a payment destination (such as a Stripe-managed crypto deposit address on a fast network like Base). The agent’s backend wallet signs a micro-transfer, hits your server again with the cryptographic receipt attached, and your server hands over the data—all in less than half a second, with zero human intervention.

2. The Agent’s money wallet

The agent, as described above, must use a wallet to make the payment and here we are in a pickle. Agents do not have bank accounts, they cannot make payments and approve 3D Secure or similar systems, and what if they hallucinate and by 10 albums instead of one?

The industry turned to crypto. Crypto wallets fall in a non-so-much of a regulated space. You can easily assigned any code to run your wallet and for example give it to an agent. It is wise to create a wallet with a part of your funds. But who would accept this?

3. Enter Stripe: Bridging Crypto to Fiat Dashboards

You might wonder: If an agent pays with crypto, do I as an seller have to become a crypto broker or integrate with one?

Not quite. Payment gateways like Stripe are bridging this gap. Via Stripe’s machine payment features, a merchant is able to generate a crypto address inside Stripe without even needing to manage a wallet or even private keys.

Now the agent is able to pay in USDC, a faciliator verifies the transaction and Stripe immediately logs in the merchants dashboard as a normal Payment Success. In your accounting system your balance remains in dollars just as a normal credit card process would.

Of course, this work is not fully hands-off. The agent’s owner would need to configure the system to the relevant endpoints and fund the agent’s wallet. Personally I cannot but mention that a natural extension of this would be the adoption of HATEOS, so that the agent has a clear way of completing the transaction, although it might be a bit more heavy.

4. But Why Couldn’t We Already Do This?

I cannot help but get frustrated with the state of modern banking. Any fintech can quite easily spin up wallets and allow on-chain transactions to be translated into a merchant’s dashboard so why did we not have this earlier?

Not only that, but we have built whole systems around protecting credit card fraud, with Europe introducing SCA and 3D Secure under the PSD2 umbrela. We went further away from allowing automated payments, to demanding proof that a human is actually initiating this transaction, while my 3 year old niece while playing with her mom’s phone purchased a book on Amazon.

The real truth is that those measures are needed, however they act like a wall when it comes to autonomous software. Western banking is built around the idea that every digital transaction is a high risk event, and personally decided to protect the system rather than to innovate and move forward.

5. Meanwhile, in Asia: Why 402 Is Not Needed

While in the western world we are setting up workarounds to patch our payment model with crypto, countries like China and Japan operate in a very different manner and even reality.

• China (Super-Apps): In China, there is no need for card networks like Visa or Mastercard as super-apps like Alipay or WeChat have created a network that allows them to set the rules of transfer. These Super-Apps already have a verified identity for each user (KYC), with their bank connections, and their checkouts in a single closed system, the addition of agentic payment did not require a new protocol. A User simply sets a budget inside their app and the agent is able to seamlessly pay within this network. A bank is never involved.

• Japan (Token Credit): Japan avoided for a long time the traditional route of credit card transactions through a Token/Credit system and a wide adoption of QR-Wallet like PayPay. This was a favorite of consumers for micro transfers as the cost remained low and you did not have the case like in Germany in which payments bellow a certain value are not affordable for the merchant.

6. Why the West lags and Europe even more

Europe always had a tendency to create frameworks that support it’s banking system over the ease of use. With the implementation of PSD2, it has create an environment of heavy regulation in which everything needs to go through third party aggregators, leaving the “Open” in Open Banking only to some.

When the introduction or better yet, need for a process such as 402, requires a choreography of virtual card generations, 3DS bypass tokens and stablecoin off-ramps, it showcases vividly the structural disadvantage that our financial railway is in, burdened by bureaucracy.

X402 moved very fast and managed to go through this dance but the cost is still visible when trying to incorporate it into existing systems.

This situation raises some more discussions which stray from the protocol itself and more into the realm of “why is even our system structured like that”, if you are interested stay tunned for Part 2.