It was well before the 2014 Atlantic article that the phrase "the original sin of the internet" surfaced. Marc Andreeson was using the phrase at this time, and Cory Doctrow and others had been using it too. So what is it? In short, the inability of the early Internet to accept payments over a wire. That's it. This is what mostly led to the Attention Economy, as it spawned a free-to-look Internet that supported itself via ads, just like your local alternative weekly blog/newspaper.
What does it mean to be entirely ad-supported? Well, a lot. Your content can't offend the advertisers or they'll stop paying you. Your advertisers may have different political beliefs than you do. They may pressure you to run ever more attention-catching ads that give you the ick. They may demand more and more and more of your site's limited and valuable visual real estate. Pages can take forever to load, tanking user patience and interest, decreasing traffic. They may demand ever more aggressive and invasive cookies, harvesting user data and installing borderline spyware, launching so many blinky, crappy pop-ups that your user can't even find that article, recipe, or North American Chinchilla Association webpage they were originally looking for.
Remember when your Google search results weren't mostly ads for crap you didn't need? I can barely remember that time either.
So as you can imagine, the recent HTTP 402-linked payments protocols have been causing quite the stir. And we have been patiently waiting for this feature for thirty years since it was first codified in 1996.
The idea here is that by enabling protocol-level micropayments--that is, NOT some big subscription or annual fee processed by a credit card company--we can move to an à la carte model that bypasses the need for those annoying ads. Read just the article you want to read. Access an API on a per-hit basis, not in packages or tiers. Less waste, fewer strings attached.
Will it work? Only the future can tell us.
But in the meantime, let's look at the options laid out before us and try to sort out which protocols seem less vulnerable to Enshittification and single-company control and centralization.
x402: An open standard for internet-native payments (Coinbase 2025)
This paper was the first I delved into. Coinbase--a big US crypto on/off-ramp, highly regulated, well-resourced. Should be a pretty sound protocol, right?
The paper does a great job of starting off with examples of why this technology is helpful. In fact, it gets pretty repetitious throughout.
Then it drops the bomb: the proposed implementation of x402 is firmly situated on top of Coinbase's proprietary Base chain (an Ethereum Layer 2), and transacts in stablecoins. If you're not a crypto person, these refer to tokens pegged to the dollar and other 'stable' currencies, as opposed to those scammy memecoins you've heard about. CumRocket coin, anyone?
Then Coinbase gives us a nice chart showing the relative merits of their monopolistic implementation. It looks like there's a clear winner! Wait....but they've forgotten something, which I've helpfully added here:
I've labeled my own compared payment rail "HTTP 402" just to differentiate it from Coinbase's proprietary x402 solution in the chart, and Optimism is just one example of numerous Eth L2s. They look quite similar except that a generic HTTP 402 middleware solution using some other Eth L2 is missing the Coinbase wrapper. Base network operators collect the very tiny, usually 1/100th of a penny fee, and Base gets the traffic on its payment rails. This is all fine, I guess, if you're cool with one entity semi-centralizing governance, fees, etc. on these transactions. It's ultimately benefitting the Base ecosystem.
The paper continues to extol the virtues of their new x402 offering, but misses a few glaring issues with both HTTP 402 in general, and with Coinbase's implementation:
If an article is paywalled behind x402, users can still screengrab or copy-paste the paid digital content.
Coinbase mentions no KYC needed--but maybe that's not great for compliance purposes? E.g. a fraudulent seller can't get banned?
Chargebacks are actually a feature for buyers, not a bug, in the case that you're sold on something fraudulent. In this paradigm, someone can steal your money because blockchain transactions are final. Ideally you'd go to customer support and request a refund, but--oops!--your agent didn't sign a EULA for x402. No refunds!
All of the features on the Base x402 implementation would also be available on many other Ethereum L2s or even other blockchains. They aren't particularly linked to Base.
There is nothing stopping me from creating my own x402 honeypot that has high relevance signals to agents or humans, but offers nothing after payment.
One of the other "features" the paper cites on page 8 is that x402 has no compliance overhead. Well, did you know that credit card companies won't let you purchase authentic torture videos due to some very important international obscenity laws? No need with x402--time to open up that anonymous streaming site!
Charging even a tiny fee + gas for every single transaction is neither economical nor efficient in terms of cost, latency, or congestion if traffic explodes, even on your shiny, speedy L2 payments chain.
Then the paper gets into some implementation details, which are less interesting. To their credit, the protocol itself is open-source and the absence of guardrails may appeal to some, alongside the nearly-meaningless fees. Coinbase Dev Platform also offers a nice x402 dev toolkit with everything you need to cede power over your transactions to the x402 Foundation half-owned by Coinbase and split with Cloudflare get started with an exciting x402 project.
2. MPP: Machine Payments Protocol (Stripe + Tempo, 2026)
Not to be outdone, Stripe and its partner (that is, investment recipient) Tempo, a rapid payments chain, announced MPP, the Machine Payments Protocol, about one year later.
It's a similarly 402-based protocol that seems to have been designed with less of a first-to-market architecture. For you design dweebs, FTMA is a DSA too. The documentation reads less like an ad for Stripe/Tempo, even including a page on x402 in the same directory level on Stripe's documentation site.
The first thing that stood out was that MPP supports both crypto payments and what crypto people call "fiat" payments, or payments in cash-equivalent and/or non-crypto. In Stripe's docs, this refers to standard credit cards (and probably debit cards), "wallets" (Stripe provided no specifier between crypto wallets vs, say, Apple Wallet) and "other payment methods that shared payment tokens (SPTs) support". Upon further investigation, these SPTs work like gift cards for the specific seller, issued by Stripe, and only issued to the value of the transaction.
Unfortunately, there are fees: 1.5% on crypto micropayments, and nothing published at all on credit card-backed micropayments, Stripe's standard being 2.9% + $0.30 per Tx, which doesn't seem viable for micropayments. Perhaps that's where the Shared Payment Tokens come in under the hood?
Now, there's still centralization here. Stripe is an intermediary, albeit a very tightly-ran ship of an intermediary. However, the MPP implementation is proprietary though the standard is open. To the credit of x402's creators, x402 is open source. This is far more "open internet"-coded. But it's trying to do a different, more lightweight and permissionless thing. Even the business structure--the x402 Foundation--implies a 'public good' framing by Coinbase and Cloudflare, the latter of which has some specific opinions on agent traffic. You guessed it--there are politics surrounding the sudden dusting-off of old HTTP 402.
So Stripe's HTTP 402 solution also has a mostly-or-entirely-centralized entity that can influence payments policy and centralization. What does that buy us?
Fraud protection via Stripe's risk detection
In-protocol spending limits can be set for your agent
Credit cards and any sort of payment integration from Stripe is accepted on MPP
Compliance framework is assumed as this isn't a pure crypto project--so we probably can't buy illegal/harmful content on MPP.
Designed for high-frequency interactions from agents via sessions as aggregation mechanism, rather than per-transaction blockchain writes; still settled to Tempo chain just as x402 settles to Base chain, but more efficient write strategy.
Make no mistake, Stripe is still Big Banking. And Coinbase is Crypto Big Banking. Whether you go with x402, MPP, or some other 402-based payments solution probably depends more on your personal philosophy and the nature of your project. Stripe is appealing to big, legit corporate actors, while Coinbase developed a protocol more in line with the libertarian spirit of cryptocurrencies and the Open Internet. However, both settle to institutionally-held blockchains and are therefore subject to the risks of centralization and governance capture.
Of course, there's nothing preventing you from forking x402's repo and wedging in your own preferred settlement chain, or creating your own middleware libraries on top of HTTP 402.
My biggest issues with the x402 whitepaper were relevance density, lack of technicality, lack of attention to the dangers and downsides in general, lack of attention to the centralization and centralized settlement issues, and the overall marketing influence that felt inherent in the paper. This could have been so much better and it pains me to read such a poorly-constructed whitepaper. It just felt dilute and myopic.
Stripe didn't even offer a whitepaper for MPP, though it should. Hey Stripe! If you're reading this, please offer something beyond lightweight documentation with cute toy examples!
Here we have two enormous financial institutions with widespread buy-in from other enormous institutions--Anthropic, OpenAI, Visa, AWS, Cloudflare, etc.--strategically positioning themselves and their product offerings for an agentic economy. Heck, even Google just bolted on x402 to their A2A (Agent-to-Agent) protocol. This is the evolution of payments, of internet commerce, of digital economics, and represents a major step in the Agentic Economy, which will only continue in its exponential acceleration.
I originally wrote this article after researching agentic payment options for my side project, aean.ai, an agentic contracts, compliance, and portable trust/reputation platform. My bet is that as agents become more autonomous and specialized, we'll need compliance, legal accountability/liability, and trust. Will I be implementing HTTP 402 payments? Almost certainly.