HTTP 402: How Machines Move Money

Every second, ~80+ million HTTP requests are sent over the internet on average. In that same second, Visa can handle no more than 65,000 payments, and Mastercard around 20,000.

Machines move data at the speed of the web. What happens when they start to move money the same way?

Machines are Moving Money

In the blink of an eye, LLMs have evolved beyond simple Q&A chatbots into context-aware, tool-equipped economic actors we now call agents.

No one quite knows how this development evolves from here, but payment incumbents wasted no time hedging their bets; Visa launched its Trusted Agent Protocol and a new CLI for agent payments; Mastercard released Agent Pay and Agent Suite, and in March executed Europe’s first live AI agent payment within a regulated banking framework alongside Banco Santander; American Express just recently announced the ACE developer toolkit, just to name a few names. Few compare to Stripe’s efforts, however, whose agentic stack now spans new agent payment primitives, business and developer tooling, and co-authoring an open-source payments protocol purpose-built for machine-to-machine payments.

Amid a great deal of warranted skepticism surrounding the impact of AI agents, trillion dollar market cap companies who certainly know a thing or two about payments are allocating significant resources to help software pay for software.

A payment is simply a way to settle an obligation: to exchange value for access to a specific good or service. For an agent, a payment may be the single blocker between a decision and a realized outcome by unlocking access to a necessary resource in a workflow the moment it’s needed. ‘Agentic payments’ and ‘agentic commerce’ have become the umbrella terms, and though the branding could use some work, the category has evidently materialized.

The interesting question remains what the supporting infrastructure will look like. Before we get there, it’s worth reviewing what it actually means when machines are moving money.

Intention Is All You Need

The free open public access to the internet we know and love is subsidized by advertisements. Bryan Kim puts this well:

“Internet advertising has created one of the greatest “public goods” in history, for the negligible price of occasionally having to look at ads for cat snuggies or hydroponic living room gardens.”

Google, Facebook, YouTube, and TikTok, have generated billions of dollars through ads, a simple act of monetizing basic human behavior: uncertainty. The gap between what someone intends to do and what they actually end up doing is the very premise of the attention economy. Every commercial webpage someone loads is an opportunity to present an ad to a persuadable consumer.

This model collapses when the primary consumer is an AI agent, who is a far more rational economic actor than a human by design.

An assigned task and a set of tools to complete that task (e.g. “Build me X using Y within budget Z”) leaves little room for ambiguity, while the lack of a limbic system means no susceptibility to the emotional pleas of advertisements.

Agents as consumers exhibit behavior patterns quite distinct from humans. They don’t face the same cognitive constraints that humans do; their very purpose of these machines is to multiply our output by orders of magnitude. Importantly, this means their resource consumption is far more granular: they require more resources, more frequently, though often at much smaller quantities (per-call, per-request rather than per-seat or per-month).

• A coding agent tasked with fixing a bug reads files, runs terminal commands, calls a code execution sandbox, and iterates on the output across dozens of API calls in a single session. Each call is billed by the model provider per token consumed. A single debugging session can consume 50,000 to 200,000 tokens across planning, editing, testing, and verification.

• A research agent compiling a market analysis might query a financial data API, a news archive, a web scraping service, and a document search index, each at a different price point, each needed at a different point in the workflow.

The transactions occur at runtime: the exact point in a workflow where a capability gap appears. Simon Taylor refers to this as the intention economy: the consumer, now an agent, arrives with a predetermined intent and moves money only if necessary to fulfill that intent.

Importantly, the byproduct of empowering AI agents as consumers is requiring new business models to accommodate them. Here we see the headless merchant emerge. Building on the increasingly popular headless commerce model, in which an e-commerce app’s frontend (user interface) is separate from its backend (data and core business logic), the headless merchant removes the frontend entirely because the buyer, an agent, has no eyes and preference for UX. The headless merchant simply needs a server, a set of API endpoints to call, a designated price-per-call, and some way to accept payments.

Several takeaways follow clearly from this. Payments need to be granular, meaning small enough to settle a single API call or token batch. They need to be programmatic, meaning triggered by code as a function call rather than a human action. And they need to be real-time, firing at the exact moment a capability gap appears in a workflow. The architecture of today’s ad-subsidized web is largely path-dependent on monetizing human uncertainty. But the intention economy, which monetizes outcome, needs its own corresponding payment infrastructure to match.

Moving Money On The Web

To understand where agent payments are going, it helps to first understand how online payments actually work today.

Online payments today involve entering a card number, clicking “pay,” waiting for a confirmation, a process that travels across web infrastructure the same way any other data does. But importantly, the web infrastructure simply provides the communication layer in this flow. Card details move as a POST request to a payment processor, which calls a card network API, which calls the payer’s bank. The actual payment, authorization, and settlement logic all lives in infrastructure layered on top of the web.

The likes of Visa, Mastercard, AmEx are building agent payment infrastructure on top of these same rails, intent on making their existing middleware smarter. What if instead, online payments worked the same way data does? What if, say, a server could respond to a request with a price, the client could pay online, and the resource delivered in the same round-trip?

HTTP standardizes how clients and servers exchange information on the web: a client sends an HTTP request, a server returns an HTTP response. A client can be anything from a browser to a mobile app to an AI agent. When a request succeeds, the server returns HTTP 200 OK. When a page doesn't exist, HTTP 404, meaning there is an error. When access is unauthorized, the server returns HTTP 401. These status codes are built directly into the protocol itself.

That question was first posed some 30 years ago, when the original HTTP spec was published, and with it status code 402: Payment Required. 402 sat between 401 (Unauthorized) and 403 (Forbidden) and like its neighbors, signals that the client must satisfy a condition before the server delivers the requested resource. 402 was designed for that condition to be a payment.

The core mechanism was simple:

1. A client requests a gated resource.

2. The server responds 402 with a price, accepted payment method, and recipient.

3. The client pays and retries with proof of payment in the header.

4. The server verifies and delivers the resource.

And yet over the years, 402 was never formally defined. There were a number of notable attempts: the W3C tried twice in the 1990s; Adrian Hope Bailie of Ripple proposed a concrete Pay header implementation in 2017, but none ultimately gained enough traction to be implemented. The simple reality was that humans already got accustomed to credit cards and thus the need was never acute enough to prompt a solution.

But time has passed, and AI agents are becoming a primary web client and user interface alongside browsers. The human is still in the loop, but agents equipped with real-time context and tooling make requests against the web at a far greater scale and frequency. When an agent encounters a resource it needs in a workflow, payment is simply its next function call, which either resolves and the task continues, or doesn’t and the task stops. The flow is elegantly simple: an agent hits a resource boundary, the server returns a price signal, the agent pays inline and proceeds with its task.

The x402 protocol was the first implementation of the 402 primitive to gain meaningful traction, launching in May 2025 under Coinbase before being contributed to the Linux Foundation as a vendor-neutral open standard. MPP, Tempo’s open-source framework built with Stripe, followed in March 2026, bringing fiat and card rails into the same protocol loop, as well as the first (formal proposal to implement HTTP 402 via IETF draft). Their differences raised the obvious questions: how do the two diverge, and which is better suited for which use case?

These are the right questions. They are also premature without more context. x402 and MPP are not the first attempts to build payments into the web at the protocol level. What differs across implementations is everything around that core loop: which rail settles the transaction, how proof-of-payment is structured, what metadata the headers carry, and how much complexity the client needs to handle.

The HTTP 402 Landscape

When Bitcoin emerged in 2009, it introduced a digital currency, with a native payment rail, that had no fixed transaction fees or intermediary. For developers curious about HTTP-native payments, the connection to 402 was immediate. As early as 2011, Bitcoin Core contributor Matt Corallo wrote in a thread on the Bitcointalk forum that he believed HTTP 402 “would be a great use case for Bitcoin”. His proposal suggested a server returning a 402 alongside an X-Bitcoin-Address and X-Bitcoin-Price header, with a browser plugin handling payment automatically in the background.

Early experiments were mostly small and independent efforts. In 2014, Benedict Chan demoed Zero Click: a server that returned a 402 Payment Required status code with a Bitcoin address and amount in the header, a Chrome extension ran in the background, automatically paid for the page and requested it again. In 2015, the anonymous author of Amphibian Abstracts published one of the earliest public 402 Bitcoin demos using custom headers (X-Payment-Types-Accepted: Bitcoin, X-Payment-Address-Bitcoin: putarealbitcoinaddresshere, X-Payment-Amount-Bitcoin: 1.234) passing payment type, address, and amount directly in custom HTTP headers. Neither Zero Click nor Amphibian’s demo was a formal protocol, but these experiments helped show the basic HTTP 402 loop was at least viable.

The 21 Bitcoin Computer

In 2015, Balaji Srinivasan’s 21co introduced the 21 Bitcoin Computer: a Raspberry Pi device featuring a built-in Bitcoin mining ASIC as well as a micropayments server accessible from a command-line interface (CLI). A core part of the product was the two1 open-source Python library that shipped alongside it, which allowed users to mine Bitcoin, use it to buy and sell API calls, set up world-readable machine-payable endpoints, and publish them to the 21.co marketplace from any Unix command line.

Two1’s module exposed a @payment.required(price) header that could be placed in front of any Flask or Django routes, two widely used Python web frameworks for building HTTP APIs. When a client would request to access a paid endpoint, the server provided a HTTP 402 Payment Required response header alongside a Bitcoin payment address and the required payment amount. On the client side, the class wrapped Python’s standard library and upon receiving a 402 response, it automatically handled the micropayment and retried the request. Notably, the HTTP 402 handshake itself was abstracted away from the developer.

A machine with a Bitcoin private key could possess, send, and receive money to another machine without a human intermediary in the loop. Fundamentally, this was all just developer tooling, but Balaji argued the implications ran deeper as part of a progression through three distinct webs: first the World Wide Web of documents connected by hyperlinks, then the social web connecting people through platforms like Facebook and LinkedIn, and then the Machine Web, where the links between nodes are payments between machines.

The line of thinking was simple: given that the web had already standardized how machines exchange information, and how people form relationships, its next problem to solve was to standardize how machines exchange money. 21co’s Bitcoin software could monetize APIs on a per-request basis without requiring developers to provide or accept credit cards, let any developer with some bitcoin call out to another endpoint as easily as importing a library, and unify fulfillment and billing into the same series of packets.

Beyond simple per-call payments, 21co implemented payment channels on a bar tab model: one deposit transaction opened a tab, high-frequency micropayments occured off-chain, and only two onchain transactions settled the whole session. The developer toolkit also enabled developers to chain paid APIs together and sell the composite pipeline, setting up a supply chain of machine-to-machine payments that could be triggered by a single client call.

As interesting as the ideas were, however, 21co’s Bitcoin computer proved to be ahead of its time. As Bitcoin network congestion grew through 2016-17, transaction fees made sub-cent micropayments economically unviable. The core concept, however, remained intact and inspired future HTTP-402 payment protocols.

L402

In March 2020 Lightning Labs launched L402, which remains the oldest active HTTP-402 implementation to date. L402 is an open-source payments framework that pairs the HTTP 402 status code with Bitcoin Lightning Network invoices and Google macaroons to enable clients to request, pay, and access web resources

L402’s implementation of HTTP 402 works as follows: when a client requests a paid resource, the server responds with an HTTP 402 status code as a payment signal, and includes everything the client needs to pay and gain access in that single response. This intuitive multi-step HTTP handshake is the same foundational structure that x402 and MPP have followed.

To better understand how L402 works, some familiarity with macaroons helps. A macaroon is a small piece of data that a server generates and hands to a client as proof that the client is allowed to access a specific resource, also known as a bearer token.

In L402, when a client, say an AI agent, wants access to a paid resource, the server generates a macaroon and Lighting invoice together. The invoice, denominated in satoshis (sats), is the payment request; the macaroon is the access credential which becomes valid to use once the invoice is paid. The server combines the two by embedding the invoice’s associated payment hash inside the macaroon. This payment hash is produced by the server taking a secret value, called the preimage, and running it through a sha256 hash function. By design, the only way to reproduce the preimage is to actually pay the Lightning Network invoice.

The client then utilizes a connected Lightning Network node or wallet client to route the payment and pays the invoice. Once paid, the Lightning Network reveals the preimage to the client, who then presents both the preimage and macaroon to the server, which runs one specific check: does the sha256(preimage) match the payment hash embedded in the macaroon? If yes, the payment is proven and the client is granted access to the resource. Importantly, the current spec under bLIP-0026 is token-format agnostic, meaning macaroons are no longer required, and any token that commits to a payment hash is accepted.

Putting together the complete L402 payment flow:

• A client (e.g. an AI agent) sends an HTTP request to a gated endpoint.

• The server responds with HTTP 402 Payment Required and a WWW-Authenticate header, which contains two values in a single response: the macaroon and a Lightning invoice.

• The client pays the Lightning invoice and receives the preimage.

• The client retries the original HTTP request with an Authorization:L402 header containing both the macaroon and the preimage.

• The server verifies the credential and provides the resource.

L402’s payment model is pay-per-credential rather than pay-per-call. A client pays a Lightning invoice once and receives a macaroon that is cached and reused for subsequent requests to the same service until it expires or is revoked. The broader L402 community spec extends the model further, defining offer types including one-time access, monthly subscriptions, and pre-purchased credit bundles, with payment methods covering Lightning, onchain, and credit cards.

The Current State of L402

L402’s original pitch was to be an alternative to credit cards and email signups for accessing paid APIs. Aperture, Lightning Labs’ Go reverse proxy, implements the full L402 lifecycle and has been in production since 2020 powering Lightning Loop (non-custodial swaps) and Lightning Pool (p2p liquidity marketplace). In practice, however, L402’s architecture maps more cleanly onto machine clients than human ones, and AI agents have become L402’s primary use case. A new agent-spec.md condenses the entire protocol into ~560 tokens for embedding directly into agentic context windows, meaning AI agents can now load the full L402 spec at runtime and implement the handshake autonomously.

The numbers, as of early 2026, indicate that L402 is live but still early. The new Github repo grew to 213 stars on Github since early 2025; Satring currently tracks 58 live L402 services.

The most significant near-term catalyst for L402 is Taproot Assets, a protocol developed by Lightning Labs that allows stablecoins and other assets to be issued on Bitcoin and then transferred over the existing Lightning Network. Today when an L402-gated server generates a Lightning invoice, it is denominated in satoshis; the client pays in Bitcoin; the server receives Bitcoin, a volatile asset. Integrating with Taproot Assets resolves this by allowing the invoice to be denominated in a stablecoin like USDT or USDC while still routing over Lightning’s existing payment channels and settling in milliseconds.

In practical terms for L402: an AI agent making a paid API call would encounter the same 402 challenge and the same macaroon handshake it does today; the only change is that it can pay the Lightning invoice in stablecoins.

Tether has committed to bringing USDT to Bitcoin with Lightning Network support via Taproot Assets, and once widely routed, L402 will be able to settle in fiat-denominated assets over Lightning rails. Lightning Labs CEO Elizabeth Stark has explicitly cited increasing demand for USD machine-to-machine payments from AI agents and the L402 protocol as a primary driver for bringing stablecoins to Lightning.

L402 is the oldest active HTTP 402 implementation, with five years of production deployments, a formalized spec under bLIP-0026, and a credible path to stablecoin settlement via Taproot Assets. It proved the HTTP 402 handshake worked and that AI agents are a natural fit. Built entirely on Bitcoin and Lightning, L402 represents one distinct approach to 402-native payments.

x402

In May 2025, Erik Reppel, head of engineering at the Coinbase Developer Platform, alongside colleagues Kevin Leffew, Dan Kim, and Nemil Dalal published the whitepaper for x402: an open-source web payments protocol built on HTTP 402.

Similar to L402, x402 facilitates payments between web clients and servers through a multi-step HTTP handshake, but where it differs is the rail and payment model. Though the protocol initially rolled out with USDC payments on the Base L2, it has since evolved to support payments in stablecoins or any ERC-20 token across several chains including Base, Solana, Polygon, BNB Chain, Avalanche, Sei, and Arbitrum. HTTP is the primary transport layer and the 402 status code is the native signal, though the same payment logic can run over MCP or A2A.

x402 supports two core payment schemes: a straightforward pay-per-call model via the exact scheme, which transfers a fixed amount per request; and a pay-per-use model via the upto scheme, which authorizes a maximum amount upfront but only charges for actual consumption of resources.

x402 plugs into existing web infrastructure as lightweight middleware, with a full reference implementation including core protocol libraries, server-side middleware for Express.js and Next.js, and client libraries for browser and Node.js environments. Server-side implementation takes a single function call, and clients can pay any supported endpoint without a prior relationship with the resource provider. An AI agent can hit a paid endpoint, receive a 402, construct a signed payload, and settle the payment without any custom payment logic needed on top.

Putting together the x402 payment flow:

1. A client requests a paid resource from a server

2. The server returns HTTP-402 with machine-readable payment instructions.

3. The client constructs a signed payment payload and resubmits the request.

4. The payment is first submitted and settled onchain.

5. The settlement proof is passed back from the Facilitator to the server to confirm payment.

6. The payload is verified, and the server fulfills the original request.

7. Once confirmed, the server returns a 200 OK response alongside the requested resource and transaction proof to the client.

X402’s stablecoin-centric architecture removed the per-transaction price volatility present in Bitcoin-denominated micropayments. Each request is treated as a standalone payment, as the client constructs a signed payment payload, attaches it to the HTTP request, and the server verifies it onchain before delivering the resource. An agent can hit an x402-gated endpoint it had never encountered before, complete payment and receive its resource, without an API key, account creating or prior billing relationship with the server; a particularly useful feature for agents, who lack persistent memory across sessions by default.

The Current State of x402

The x402 ecosystem, made up of clients, servers, facilitators, as well as supporting infrastructure & developer tooling, is actively growing. $50.7M in total volume and 172M total transactions have been processed via x402 to date, featuring 734k buyers and 148k sellers as well. Agentic market currently tracks 68 active services agents that can call directly and pay for via x402.

Interestingly, though AI agents are actively integrating x402, humans still account for the majority of x402 payments today.

In December 2025, x402 V2 shipped, introducing reusable sessions, Permit2 support for any ERC-20 token, automatic service discovery, and resource metadata in 402 responses.

On April 2, 2026, dubbed “4/02 Day,” Coinbase contributed x402 to the Linux Foundation and the x402 Foundation was formally announced. The governing body is co-founded by Coinbase, Cloudflare, and Stripe. Expressed support and membership spans AWS, American Express, Google, Mastercard, Microsoft, Shopify, Visa, Circle, Adyen, Ant International, KakaoPay, Polygon Labs, and the Solana Foundation, among others. Shortly after, AWS Bedrock published a reference implementation of x402 for financial services agents, making it the first major cloud provider to embed x402 directly into its infrastructure.

For a deeper dive into x402, read When Machines Move Money.

MPP

On March 18, alongside Tempo’s mainnet, Tempo and Stripe introduced the Machine Payments Protocol (MPP). Similar to L402 and x402, MPP is an open-source protocol that enabling clients to pay for web resources through a standard HTTP handshake. Unlike its predecessors, however, MPP introduces a session model that builds directly on Liam Horne’s work on State Channels: an agent locks funds on Tempo once to open a session, makes as many subsequent requests as needed using signed vouchers offchain, and the server periodically settles the accumulated balance in a single transaction back on Tempo. The spec is open-source and accompanied by an IETF Internet-Draft (draft-ryan-httpauth-payment), the first formal attempt to give HTTP 402 standardized semantics through the internet engineering standards body.

MPP directly builds on State Channels: two parties lock funds in a multisig contract, exchange signed transactions offchain however needed, and simply settle the net result onchain in a single transaction. This is, in fact, MPP’s key differentiator: session-based streaming micropayments.

A “session” intent lets agents authorize a spending limit upfront, then stream micropayments as needed without onchain transactions required per each individual request that follows. The first request opens a payment channel for that specific client/agent, while subsequent requests use off-chain “vouchers”. The server periodically settles accumulated vouchers in a single batch transaction.

Putting together the entire MPP payment flow:

1. The client sends a standard HTTP request (e.g. GET /api/resource).

2. The server (running mppx, MPP’s reference TypeScript SDK and server middleware) contacts Stripe, which creates a PaymentIntent and returns a deposit address from Tempo.

3. The server returns HTTP 402 with a WWW-Authenticate: Payment challenge header containing the amount, accepted methods, deposit address, and a challengeId.

4. The client then fulfills the payment, which can be done either by signing a stablecoin transfer on Tempo; completing a card payment via Stripe’s Shared Payment Token; or paying a Lightning invoice).

5. The client retries the original request with an Authorization: Payment header containing the payment credential.

6. The server forwards the credential to Tempo for onchain verification.

7. Once verified, the server returns 200 OK with the requested resource and a Payment-Receipt header.

Importantly, for session-based flows, steps 2-7 only happen on the first request. Subsequent requests skip the chain entirely: the agent sends a signed voucher, the server verifies the signature locally, and delivers the resource.

MPP also provides a native MCP transport binding, which AI agents use to discover and invoke tools. If an agent calls a paid tool on an MCP server, the payment handshake happens inside the tool call itself via JSON-RPC error code -32042 (the MCP analog of HTTP 402), meaning the agent pays and receives the result within the same function call.

MPP is rail-agnostic by design, supporting stablecoin payments on Tempo, a high-performance L1 offering ~500ms finality, sub-cent fees, and stablecoin-denominated gas fees; credit and debit cards via Stripe’s Shared Payment Token; and Bitcoin via Lightning. Anyone can define a new payment method by publishing a spec against the MPP framework without permission from its creators.

The Current State of MPP

At the time of writing, MPP has processed ~$103k in volume and ~710k transactions across 68k agents and 2.7k servers in total.

MPP launched with an impressive list of design partners including Anthropic, OpenAI, DoorDash, Mastercard, Visa, Nubank, Revolut, Shopify, and Standard Chartered.

At launch, 100+ MPP-compatible services were listed in the payments directory. Services are specifically designed to be consumed by agents; Claude chat completions, headless browser sessions, containerized compute, onchain data queries across 80+ networks, domain registration, and SEC filing search. Live integrations include Browserbase, QuickNode, Parallel Web Systems, and PostalForm. Cloudflare’s Agents SDK provides full MPP support.

Because anyone can publish a new payment method spec against MPP, the protocol’s future is no longer restricted to the capabilities of Tempo and Stripe.

Emerging Developments Around HTTP 402

x402 and MPP are the most active implementations of the 402 primitive today, but they are not the only ones. A broader ecosystem of teams has been building around HTTP 402, each approaching the same underlying problem from a different angle.

• Cloudflare implements HTTP 402 in its pay-per-crawl feature. When an AI crawler requests a page on a Cloudflare-protected site, Cloudlfare returns a HTTP-402 with a crawler-price header, the crawler retries with a crawler-exact-price header, Cloudflare serves the content and logs the billing event. Publishers set a flat per-request price and can allow, charge, or block any crawler independently. Importantly, pay-per-crawl is in closed beta, but the initiative demonstrates HTTP 402 running at Cloudflare-scale between web content owners and AI agents.

• EVMAuth, built by Radius Tech is a Solidity smart contract (deployable to any EVM chain) that extends ERC-1155 to paygate web resources behind token ownership. It integrates HTTP 402 directly: when a client requests a gated resource without the required token, the server returns 402 with instructions to purchase the access token onchain. The client buys the token, retries with proof of ownership, and gets access. Tokens can represent subscriptions, API credits, time-limited licenses, or any access tier. For agents, this means access rights are portable onchain assets.

• OKX’s Onchain OS Payment is built directly on x402; When a client requests a paid resource, the server returns HTTP 402 with payment requirements. The client pays onchain and retries with a payment credential in the header. Settlement runs on X Layer, OKX’s native L2, where OKX subsidizes gas fees for clients.

• H402: H402, built by BitGPT, is an open-source fork of x402 with a five-stage deterministic payment lifecycle: Quote -> Authorize -> Broadcast -> Validate -> Settle. It extends x402 to include Bitcoin and Lightning Network payments alongside EVM chains and Solana, and features USDT support. Notably, unlike x402, H402 charges a 0.25% protocol fee per payment.

• x402z, co-authored by Mind Network and Zama, is building an agent-to-agent privacy-based payment solution, specifically built on Fully Homomorphic Encryption (FHE). Summarily, FHE enables computation on encrypted data without requiring decryption; applied onchain this enables validators to validate transactions (e.g. sufficient balance, valid signature) without seeing the amounts or balances. x402Z is built on Zama’s FHE stack, uses ERC-7984 (Confidential Token Standard) for encrypted transfers, and is currently in closed testnet.

An Important Consideration: Security Implications of HTTP

The security risks of HTTP 402 payments were being debated in 2012, when early Bitcoin developers raised the concern that a malicious server could use a 402 response to silently trigger payments without user awareness. The counterargument then was that HTTPS mitigates interception and that payment authorization should sit in a dedicated client rather than the browser.

That debate was never quite resolved, but it’s important to consider now as HTTP 402 adoption starts to pick up via L402, x402, and MPP activity.

HTTP transmits data in plaintext, and any intermediary between client and server, a router, a proxy, a compromised network node, can read and potentially modify what is being sent. HTTPS was created to solve this by wrapping HTTP in TLS encryption, making data in transit unreadable to anyone intercepting it. For payments this matters because payment credentials, wallet addresses, signed payloads, and payment amounts all travel in HTTP headers.

Importantly, HTTP 402 does not mandate HTTPS. Payment credentials, wallet addresses, signed payloads, and payment amounts all travel in HTTP headers, and whether that exchange is encrypted depends entirely on server configuration.

Beyond transport security, today’s implementations carry additional known tradeoffs. Payment credentials travel as bearer tokens in HTTP request headers, meaning anyone who intercepts a valid credential can potentially reuse it. A signed payment payload could theoretically be extracted and front-run; wherein a signed payment payload could theoretically be extracted from the request and submitted onchain before the intended recipient processes it. For $0.003 API calls the economic incentive to exploit this is low, but for higher-value transactions it is a meaningful gap. The IETF draft for MPP defers detailed security analysis to a future revision entirely. These are known tradeoffs, not unknown risks, but the security model of HTTP 402 payments is still a work-in-progress in its current state. Ultimately, security risk may prove to be the biggest bottleneck to the widespread adoption of HTTP 402 payments.

Closing Thoughts

We at Shoal believe the most interesting question in agent payments is not which protocol wins, but whether the infrastructure AI agents transact on ends up being designed for machines, or whether it ends up being the same rails humans use with a smarter wrapper on top.

HTTP 402 is, at its core, a long-standing but mostly dormant part of the native web. It gained no traction with human-centric payments, but machines present a new opportunity. The status code’s first experiments and live implementations were based on moving value between Bitcoin miners, nodes, and content servers. Today’s implementations target AI agents, paying for goods and services on behalf of humans directly as well as in their own workflows.

The thesis for HTTP 402 adoption is straightforward: the efficiency gained from expressing economic intent via HTTP is too valuable to ignore. A world in which agent payments drive meaningful volume, where tens of thousands of agents are autonomously transacting at the speed of the web across thousands of services, is only beginning to materialize. The question is what the payment infrastructure for that world looks like. Encoding payments directly into the web with HTTP 402 is one answer to that question. Whether it is the right one remains to be seen.

Not financial or tax advice. The purpose of this post is purely educational and should not be considered as investment advice, legal advice, a request to buy or sell any assets, or a suggestion to make any financial decisions. It is not a substitute for tax advice. Please consult with your accountant and conduct your own research.

Disclosures. All posts are the author’s own, not the views of their employer. At Shoal Research, we aim to ensure all content is objective and independent. Our internal review processes uphold the highest standards of integrity, and all potential conflicts of interest are disclosed and rigorously managed to maintain the credibility and impartiality of our research.

Sources

Data - Artemis, Dune, Github, x402Scan, MPP Scan

• @nlevine19, x.com/nlevine19/status/2036450698271785350

• “Open Agentic Commerce and the End of Ads.” a16z crypto, a16zcrypto.com/posts/article/open-agentic-commerce-end-ads

• @yq_acc, x.com/yq_acc/status/2037579506429657198

• “The Intention Layer.” Fintech Brain Food, fintechbrainfood.com/p/the-intention-layer

• “The 21 Bitcoin Computer.” Earn.com, medium.com/@earndotcom/the-21-bitcoin-computer-1d28d652b57b

• “two1 3.5.0.” PyPI, pypi.org/project/two1/3.5.0

• “two1-python Payment Decorator.” 21dotco, github.com/21dotco/two1-python/blob/master/two1/bitserv/django/decorator.py

• “True Micropayments with Bitcoin.” Earn.com, medium.com/@earndotcom/true-micropayments-with-bitcoin-e64fec23ffd8

• “Buy 50 APIs with Bitcoin in the 21 Marketplace.” Earn.com, medium.com/@earndotcom/buy-50-apis-with-bitcoin-in-the-21-marketplace-1fbf5208e397

• “L402 Protocol Documentation.” l402-protocol, github.com/l402-protocol/l402/tree/main/docs

• “L402 Protocol Specification.” Lightning Engineering, docs.lightning.engineering/the-lightning-network/l402/protocol-specification

• “x402 GitHub Repository.” x402 Foundation, github.com/x402-foundation/x402

• “x402 Documentation.” Coinbase, docs.cdp.coinbase.com/x402/welcome

• “MPP Overview.” Tempo, mpp.dev/overview

• “State Channels.” Liam Horne, liamhorne.com/state-channels