#17 - HTTP 402’s Modern Makeover

How Agentic Payments are Reinventing a 90s Internet Standard

Sep 25, 2025

By Jay Yu, coauthored with Ryan Barney

What is 402 Status Code “Payment Required” 📖 What Is It & How To Fix It?

Research published on Pantera’s crypto blog.

Introduction

The Internet was born with an “original sin” [1]: while HTTP became the universal language for moving information, it never embedded a native way to move money. Buried in the protocol was a placeholder status code – HTTP 402: Payment Required – meant to make payments as seamless as loading an image or a video. But 402 was left undefined, and instead of protocol-native micropayments, the web economy was forced down the path of advertising, walled gardens, and awkward credit card forms.

This piece will trace how that abandoned relic of the early web has returned as the foundation of an emerging agent-driven economy. We’ll explore why HTTP 402 languished during the first e-commerce era, how stablecoins and blockchain rails are reviving its original vision, and how new standards like x402 and h402 could finally absolve the Internet of its original sin by making payments as native and as invisible as information itself.

1 - The Forgotten Payment Code of the Web

HTTP – HyperText Transfer Protocol – is the backbone of the modern Internet. Within the HTTP standard, there are many “status codes,” which servers use to tell browsers what happened when they tried to load something. Some of the most famous HTTP status codes include:

HTTP 200 - OK: Everything worked, and the page is loaded successfully
HTTP 404 - Not Found: The resource doesn’t exist
HTTP 500 - Internal Server Error: Something on the server side broke down

However, apart from these well known and widely adopted codes, there are many others that exist in the standard but are rarely seen in everyday browsing – like HTTP 402 - Payment Required, which was a reserved status code but never standardized.

The 1990s vision for HTTP 402 was to enable web servers and browsers to negotiate payments for premium content using a standard part of the web protocol. The idea was that servers could return a 402 Payment Required response, and browsers could natively handle a <payment> tag, much like <img> or <video> tags. Clients would then send servers some sort of “digital cash” payment to the server to unlock premium content.

Behind HTTP 402 was an economic vision of the Internet that contained:

Protocol-Native Payments: HTTP 402 envisioned a web where payments were as seamless as loading images or videos, using a hypothetical <payment> tag and browser-server negotiation.
Micropayment Economy: The goal was to enable per-request or per-article payments, making small, frictionless transactions a core feature of the web.
Alternative to Ads: By embedding money into HTTP itself, the internet could have avoided dependence on advertising-driven business models.

A hypothetical HTML tag for how payments might have been embedded at the protocol level with HTTP 402 server responses [2].

Yet, this grand vision of the <payment> tag never quite materialized. In 1994, when college student Dan Kohn made the first e-commerce transaction by selling a Sting CD on the Internet for $12.48, his NetMarket website relied on bolting credit card details onto the web via text boxes and basic encryption.

Despite tons of early experiments for “digital cash”, such as DigiCash, eCash, and Hashcash, HTTP 402’s original vision of Internet-native micropayments never materialized. The question of “what would happen after you clicked that buy button” remained a hard problem, with two major hurdles [1]:

Lack of Incumbent Interest - Incumbent payment networks like Visa and Mastercard lacked interest and technical chops in supporting micropayments at the cent-level scale
Enormous Processing Fees - for a cent level transaction, you could face dollar-level wiring fees. This meant that it made no economic sense for the Internet to adopt micropayments

This design flaw led to what has been dubbed as the “Internet’s Original Sin” [2] – that first-generation browsers like Netscape were never able to build payments natively as an operation in the HTTP spec [3]. This lack of a digitally native form of cash and payments directly influenced the economic model of the Internet. Instead of being able to charge users on a “pay per visit” model on premium content, sites were forced to adopt an advertising model to monetize, crowding out the core content of the web and denigrating not only the user experience, but also exposing unsuspecting users to phishing attacks, and other nasty security vulnerabilities.

Of course, eventually money did in fact catch up with the Internet. With the rise of ecommerce in the 2000s, online payments became ubiquitous – but not in the way HTTP 402’s creators envisioned. Instead of a native, protocol-level mechanism for transferring value, payment was redirected through centralized intermediaries like PayPal, Stripe, and later Shopify Checkout, using essentially the same method as Dan Kohn – bolting credit card details into encrypted text boxes.

These systems solved the problem of “how to move money online” by herding the users into their own “walled gardens” of APIs and integrations, bypassing HTTP entirely. When a user clicked “Buy” on a website, they would be redirected to a payment page or widget, where they entered card or Paypal credentials, and waited for confirmation while Paypal or another intermediary processed their transaction. While this approach enabled the explosion of e-commerce, it came with clear tradeoffs:

Human-Driven: Every payment assumed a person at the keyboard, filling out forms and clicking “Pay Now.”
Batch Settlement: Funds moved over legacy card and banking rails, often taking days to clear.
Fee Floor: Card network interchange fees (~$0.30 + % cut) made micropayments impractical.
Walled Gardens: Each payment processor controlled its own ecosystem, locking merchants and consumers into proprietary flows.

While these tradeoffs were fine for buying a $50 sweater or a $500 flight, they were fatal to 402’s dream of instant, per-request payments for digital content, API calls, or other fine-grained online services. In short, e-commerce thrived, but protocol-native payments died. In contrast to the simple <payment> tag command, this is what it would take to make the same purchase in PayPal, forcing clients into the “walled garden” of the Paypal SDK:

Example of Code integrating Paypal into an HTML page via their walled garden

And so, for over two decades, the 402 status code stayed dormant – a reserved but undefined relic in the HTTP specification, waiting for the dream of “internet native money” to catch up.

That infrastructure finally arrived with the stablecoin revolution.

2 - Stablecoins for AI Agents: Where Money Meets the Internet

What HTTP 402 envisioned was a world of Internet-scale micropayments: a peer-to-peer cash system as seamless as the peer-to-peer flow of information. Today, with the global rise of stablecoins and cheap, fast blockchain rails, that world may finally be here. Stablecoin supply has surged from under $2 billion in 2019 to over $246 billion in 2025 [4], with Circle’s USDC alone growing 29-fold in volume last year and going public on the NYSE [5]. Meanwhile, blockchain infrastructure has matured, with L1s and L2s offering sub-cent level fees – Solana averages just $0.0048 per transaction – making HTTP 402’s vision of instant, per-request payments feasible at last.

Today, AI assistants such as ChatGPT and Claude have seeped into every corner of our daily lives, and can provide product recommendations for a wide range of items. Yet when it comes to actually paying, today’s processors like PayPal and Stripe still assume a human at checkout. For example, while Stripe has been experimenting with issuing temporary “agent cards” these cards may be flagged as “high risk” by payment processors leading to rejections, and AI agent payments always seem to be just out of reach.

Stablecoins, by contrast, are natively programmable. An AI agent can craft an on-chain transaction, either asking the user to sign or executing directly under a pre-approved policy. In fact, Visa estimates that 90% of stablecoin volume already comes from programmatic transactions, rather than “organic” end users [7] – a testament to the potential and practicality of machine to machine payments. After all, it is far easier for an AI agent to get access to a private key than to a bank account.

Thus, we can easily see a world in which AI agents not only recommend what to buy, but also buy them on our behalf, using stablecoins like USDC as their execution layer. In this way, ERC20.transfer finally realizes the functionality that the <payment> tag originally envisioned – that of an open, peer-to-peer system of money, just as programmatic as the Internet itself. In other words, stablecoins moving over blockchain rails finally solve the question of “what happens after you click the buy button”?

3 - Technical Implementations of the HTTP 402 Standard

HTTP 402 Payment Flow. Source: Original Content

So how might HTTP 402’s modern makeover look like in an age of agentic payments? Today, several teams have proposed solutions, including Coinbase’s x402 standard, BitGPT’s h402 standard, and Radius Tech’s EVMAuth. At a high level, they all involve the following steps:

The user prompts an agent for an action, funding a policy with the transaction amount
The agent will send a transaction to a website, and get back a 402 response, also called a “challenge.”
1. This challenge will include details such as the merchant wallet, accepted chains, assets, and value of the good or service.
Upon receiving this challenge, the agent will forward this to a “payment facilitator,” which can be the end user or a custodial wallet service. This “facilitator” will check the information in the challenge against a transaction policy (eg. is this <100 USDC, is this a whitelisted domain)
If the facilitator OK’s the transaction, then it will send the transaction to the merchant wallet, and the agent send proof of payment (eg. transaction hash) to the merchant using the same API.
The merchant confirms payment and ships the goods or service.

However, all of these frameworks differ on the specifics of their implementations, mostly in three aspects [10]:

Challenge schema – this is the “shape” of the HTTP 402 responses that they get in Step 2.
Facilitator Policy – the rules and restrictions that facilitators place on the payment method and policy.
Proof of Payment Form – the type of “receipt” they give back to the server

Importantly, it is not necessarily these standards themselves that monetize, as they are all open source. Rather, companies such as Coinbase, BitGPT, and Radius aim to monetize by running the “payment facilitators” that process flows in their HTTP 402 system. After all, the company that creates the universal standard will naturally have an edge in creating the dominant payment facilitator. This is similar to how HTTP is a public protocol but Chrome and Mozilla monetize by running web browsers that collect user traffic.

Moreover, these HTTP 402 standards are also composable with broader agentic communication frameworks. For example, Google recently announced their Agent-to-Agent (A2A) protocol, a system that allows AI agents to talk to one another and complete multi-task steps [19], in partnership with Coinbase’s x402 protocol. Whereas A2A provides a common interoperability layer for agents to share data and workflows, x402 plugs in as a payment extension within Google’s Agentic Payments Protocol (AP2). With x402 on top of Google’s A2A framework, users can buy a refrigerator from Lowes just by chatting with an AI agent [20], marking the beginning of a new era of ecommerce.

4 - The Future for HTTP 402 Adoption

From above, we see that with each of these implementations of the HTTP 402 standard, there exists a tradeoff between composability (types of chains and assets) and distribution (vendor integration). But what are the core ingredients needed for this to really take off and become the go-to standard for agentic payments? I believe that HTTP 402’s adoption lies in the further growth of four interlocking components: 1) client-side integrations, 2) vendor adoption, 3) facilitator providers, 4) underlying stablecoin rails.

Client-Side Integrations – what does UI for the end user look like?

Even though HTTP 402 positions itself as an “agent to agent” system, the end demand or intention has to come from somewhere. Going back to the case where I decide to buy a pair of jeans from Amazon, there has to be some interface (such as Claude’s chat UI) that captures what I need or want. These user interfaces can be instantiated in multiple ways. The most common is likely an MCP server (such as the x402 MCP server that CDP provides) with mainstream chatbot such as Claude or ChatGPT. Alternatively, this could take place as an AI-enhanced web browser, similar to The Browser Company’s Dia Browser, or perhaps a hardware interface, such as a smartwatch or AI-enhanced wearable. Openmind, for example, takes x402’s vision of agentic payments into the realm of robotics, allowing robots to pay each other for collaborative services [14].

Vendor Adoption – what can these HTTP 402-enabled agents actually buy?

This is perhaps one of the most difficult components to gain traction in, as for these payment agents to truly gain traction, they must be able to buy services from traditional ecommerce vendors, such as Amazon, or subscription content providers such as the New York Times. This requires a monumental amount of buy-in from legacy vendors that may be reluctant to quickly adopt crypto and agentic payment. In fact, many of the existing vendors integrated into x402 are crypto-adjacent companies, such as Pinata for IPFS upload/download, Heurist for deep agentic research, and Hyperbolic for LLM inference [15] [16]. Nonetheless, as crypto payments go mainstream, this list will likely expand as time goes on. x402 also has a “discovery page” noting many of the projects that are within the ecosystem, highlighting live integrations such as Prodia for image-gen, firecrawl for web crawl, and various community wrappers of LLMs, web search, and stock data.

Facilitator Providers – who controls the purse?

Facilitators play a key role in the HTTP 402 workflow, being able to decide if a payment request from an agent can be authorized. In fact, facilitators are arguably the most lucrative role, as they can monetize by (1) charging flat-rate service fees to users and agents to custody funds and maintain policy security, and (2) take a cut from transaction order flow. Given that fundamentally HTTP 402 is an open-source protocol, many of the companies behind the push driving its adoption, such as Coinbase, BitGPT, and Radius profit off this system by running the facilitator for these payments.

As this standard matures, we can see other players in the wallet-as-a-service and custodial space, such as Privy and Turnkey play a greater role in facilitating these systems, as well as AI native wallet systems such as Circuit AI, and academic systems such as Liquefaction. Interestingly, almost all of these policy engines rely on Trusted Execution Environments (TEEs) for key management and policy execution.

Underlying Stablecoin Rails – how is the payment processed?

As iterated throughout this article, stablecoins are essential to HTTP 402’s revival and further growth. Improvements in the underlying stablecoin rails and payment stack will undoubtedly accelerate HTTP 402’s adoption as a standard and catalyze further growth. Over the past few years, the stablecoin payments stack has matured enormously, with many players bridging the gap between traditional payment rails and stablecoins.

For example, Coinflow provides a one-click service for merchants to receive payment and payouts in stablecoins. BVNK, Bridge (acq. Stripe) and others facilitate the orchestration of payments between stablecoins and traditional financial systems. OpenFX allows for cross-border payments with real-time FX settlements. Circle’s Gateway and CCTP allows for USDC to move smoothly between the various blockchains it’s integrated with [17], and NEAR Intents also allows for cross-chain business logic for HTTP 402 workflows [18]. Improvements in all of these underlying rails will make stablecoin-powered HTTP 402 payments faster, cheaper, and more interoperable, ultimately lowering friction for both developers and end-users.

Conclusion

Over 30 years have passed since HTTP 402 was first proposed, during which the status code served as a placeholder for an Internet-native form of money that never quite arrived. But today, the pieces might finally be snapping into place: stablecoins providing programmable cash, AI agents becoming autonomous consumers of content, and new standards like x402 and h402 are stitching it all together.

So what might all this mean for the everyday user?

Imagine asking your Claude-powered assistant to compile a research report. It quietly pings ten different APIs – news databases, image generators, model inference endpoints – and pays each one a few cents using a policy wallet you’ve pre-approved. No checkout. No credit card forms. No cookies tracking you across the web. Just clean, programmatic intent, executed seamlessly.

Or picture an enterprise dev platform where apps are no longer billed monthly by seat, but dynamically per compute cycle or inference call. Agents meter usage and authorize payments on your behalf. Budgets become policies. Subscriptions become flows. Finance becomes code. In this world, HTTP 402 becomes a medium for agentic exchange, part of a broader workflow that empowers AI agents to not only create recommendations, but also transact real world value.

And one day, maybe your cousin will open a debugging dashboard and casually remark, “Oh yeah, my AI hit a 402 earlier and topped off the credits,” without thinking twice. Just like “404 Not Found,” “402 Payment Required” might finally enter the cultural lexicon, not as a relic of the early web, but as a native verb of the next one.

And perhaps that is the day when the Internet finally absolves itself of its “original sin.”

Many thanks to Mason Nystrom from Pantera, Daniel Lev from Coinflow, Lia Muller Pena from BitGPT, Lincoln Murr from Coinbase Developer Platform for comments and suggestions.

If you are building a next-generation payment network, please reach out to jay@panteracapital.com!