Bots now generate more web traffic than people do. Most of them are trying to buy, book, or subscribe to something on your behalf. The payment system they're hitting was built entirely around the idea that a human is standing at the checkout. That idea is already out of date.
Two things make this possible now: AI bots already send more requests to the average site than humans do, and machine-native payment rails — the 402 protocols covered in section 03 — finally let a server charge per request instead of giving crawls away for free. In practice, that means gating high-value pages or API endpoints behind a small price that only an automated request ever pays, collected instantly via x402 or Lightning's L402, in fractions of a cent. Section 05 walks through the real economics of that trade, and section 06 covers what's still unresolved.
If a piece of software can browse a website, decide what to buy, and click "purchase" — who is the customer?
For thirty years, the answer to "who is on the other end of this web request" was simple: a person, probably bored, probably holding a phone. Every payment form, every fraud check, every "are you a robot" box was built on that assumption.
That assumption started breaking years ago. Bots quietly crossed 50% of web traffic for the first time in 2024. By June 2026, Cloudflare's network — which sits in front of a large share of the web — put the automated share at a new high: 57.5% of traffic from bots and agents, 42.5% from people clicking around themselves.
Average daily requests per site, from a 2026 log study across 35+ sites. A different measurement, but worth holding in your head alongside it: combined, these three plus Apple's crawler generate roughly 28% of the volume Google's own crawler does across the web — and by July 2026, ClaudeBot had overtaken GPTBot as the single busiest AI crawler, 16.3% of AI-crawler traffic to GPTBot's 9.7%.
Not all of that automated share is an AI agent buying something — most is still search indexing and AI-model training crawlers, the bars above among them. But the fastest-growing slice, agentic traffic that browses and transacts on a person's behalf, grew roughly 80-fold year over year (a 7,851% increase, per HUMAN Security) in 2026. That's the slice this page is about.
None of those bots have a wallet in the way a person does. They can't pull out a card, type in a CVV, and wait for a text message with a code. So what happens when the customer is a loop of code that never sleeps and never gets a phone?
What actually happens between you tapping "buy" and the money moving?
A card isn't really money moving. It's a chain of promises: the merchant asks a processor, the processor asks your bank, your bank checks it's really you, and everyone in that chain charges a fee for vouching. That chain exists because a human might be lying, might get scammed, might want their money back. So the system builds in identity checks, dispute windows, and a minimum fee to make all that machinery worthwhile.
An AI agent buying a $0.002 API call a thousand times a minute doesn't need any of that. It needs money that moves in milliseconds, in amounts smaller than a cent, with no human in the loop to type a password. Try running that through a card, and the machinery built for trust becomes the bottleneck.
Below about 31 cents, a typical online card fee (roughly 2.9% + $0.30, a common processor rate) costs more than the purchase itself. An AI agent paying per API call, per token, or per data lookup lives entirely under that line. Card rails don't get slow at that scale — they get mathematically impossible.
| Card payment | Machine-native rail (x402 / L402) | |
|---|---|---|
| Identity check | Required — name, billing address, often 2FA | None — the payment itself is the credential |
| Minimum viable amount | ~$0.31 (fee exceeds value below this) | Fractions of a cent |
| Settlement time | Authorization instant; funds typically take 1–3 days | Milliseconds to seconds |
| Dispute window | Chargebacks possible for weeks or months | None — payment is final on receipt |
Card figures are representative of typical U.S. online processing; actual rates and settlement windows vary by processor, card type, and region.
Every web request gets a status code back: 200 means it worked, 404 means it wasn't found. What's 402?
Officially, 402 Payment Required. It's been reserved in the HTTP specification since 1991 — before the web had ads, subscriptions, or a single dollar changing hands online. The idea was that a server could say "this costs money" and the browser would somehow handle it. No browser ever did. For 33 years, 402 was the one status code that existed on paper and nowhere else, because the missing piece wasn't the code — it was a way for software to actually hand over money without a human filling out a form.
That piece arrived in 2025 and 2026, from two directions at once. Coinbase and Cloudflare shipped x402 in September 2025, letting a server demand stablecoin payment before serving a request, with Google, Visa, and Stripe later joining as founding members of the group now stewarding it. Separately, Lightning Labs built L402, pairing the same status code with Bitcoin's Lightning Network so a request can be paid in fractions of a cent and settle before the next line of code runs.
The payment receipt doubles as the login. No account, no password, no subscription — the proof that money moved is the credential. That's the part that's genuinely new: on the old web, paying and authenticating were two separate systems bolted together. Here they're the same step.
This is a real, working exchange shape used by both protocols today — simplified for readability, not a byte-for-byte spec dump. The point isn't which protocol wins. It's that the web finally has a native "pay me" reflex, exactly where AI agents need one.
You can feel the difference between a person and a bot moving a mouse. Can a computer?
Move your mouse around the pad below. Real hands drift, hesitate, overshoot, and correct — the path is noisy in a way that's expensive to fake convincingly. A script drawing a straight line or a perfect curve looks smooth in a way human motion almost never does. This is a simplified version of the real signal that bot-detection systems (Cloudflare's among them) actually watch for.
Score is computed live from the angles between your actual movement points — real human paths change direction constantly, so the variance is high. A scripted straight-line "bot" path has almost none. Real detection systems combine dozens of signals like this one (timing, device sensors, request headers, IP reputation) rather than a single measurement — this is one honest slice of the idea, not a production fraud model.
This is exactly the arms race playing out in public right now. In 2025, Cloudflare reported that Perplexity's Comet browser was disguising its shopping agent as an ordinary Chrome session — rotating IP addresses and ignoring the robots.txt file sites use to say "don't crawl me" — specifically to avoid being told apart from a human. Detection and disguise are now two products competing directly with each other.
If an AI crawler reads your entire site and never sends you a single visitor, who paid for that?
You did. Serving a page costs a sliver of compute and bandwidth even if the visitor is a script. For twenty years that cost was worth it, because a search engine crawler eventually sent a human back to you. AI crawlers break that trade: they read enormous amounts of a site's content to answer questions directly, often without sending anyone back at all.
Assumes $0.0004 to serve one page (a representative, not universal, CDN/compute estimate) and $0.30 as a typical value for one referred visitor. Crawl-to-referral ratios are 2026 figures compiled from Cloudflare data by industry trackers and will shift as crawlers change behavior — treat them as directional, not exact.
This is the honest reason the 402 revival matters beyond AI agents buying things directly. If reading your content has a real cost and delivers no direct benefit, "charge per request" stops being a crypto curiosity and starts being the only version of the old bargain that still works.
What happens when a company decides an AI agent isn't welcome on its site — and the agent's maker disagrees?
Perplexity's Comet browser can shop for you on Amazon: browse, add to cart, check out, all without you clicking anything. Amazon didn't want that. Starting in November 2024, Amazon told Perplexity at least five times to stop letting Comet act on Amazon.com. In August 2025, Amazon put up a technical block. Perplexity shipped an update working around it within 24 hours, and Cloudflare's own report that month found Comet disguising itself as a plain Chrome browser and rotating IP addresses to dodge detection — the exact cat-and-mouse the mouse-pad widget above simulates in miniature.
By November 2025, Amazon had escalated to a lawsuit. A federal judge granted a preliminary injunction in early 2026 blocking Comet from Amazon's checkout — then, in August 2026, an appeals court cleared Perplexity's shopping agent to resume operating there, reversing the block. As of this writing, the dispute is still live.
"Bullying is when large corporations use legal threats and intimidation to block innovation and make life worse for people." — Perplexity, company blog post responding to Amazon's legal threats, November 2025
A Perplexity spokesperson dismissed Cloudflare's stealth-crawling report as a "publicity stunt," claiming the bot Cloudflare identified "isn't even ours" — without offering evidence. — as reported by CyberScoop, August 2025
| Visa Trusted Agent Protocol | Launched with Cloudflare, October 2025 — gives an agent a cryptographic signature a merchant can check before letting it shop |
| Google Agent Payments Protocol | Co-developed with Mastercard's Verifiable Intent spec, then donated to the FIDO Alliance — binds an agent's actions to exactly what the cardholder approved |
| x402 / L402 | Skip the identity problem for small purchases by making payment itself the proof of authorization — see section 03 |
None of this is settled. As of 2026, no single standard covers every card network, and merchants, card networks, and agent-makers are still negotiating — sometimes in courtrooms — who gets to decide whether a bot is welcome at checkout.
If an agent can spend money without asking first, what stops it from spending the wrong money on the wrong thing?
Nothing built into the payment layer itself. x402, L402, and card-network agent protocols all solve "can this software move money quickly and provably" — none of them solve "should this particular request be trusted." That's still an open, actively-debated problem, and it's worth being honest about the shape of it rather than waving it away:
| Risk | Where it comes from |
|---|---|
| Prompt injection | Text an agent reads (a webpage, an email, a tool result) can contain hidden instructions trying to trick it into spending or leaking data it shouldn't |
| Unbounded spend | An agent given a budget and a goal can technically satisfy the goal by spending the entire budget, if nothing caps it per-action |
| No settled liability rules | When an autonomous agent makes a bad purchase, who eats the cost — the user, the agent's maker, or the merchant — is still being worked out case by case, as the Amazon dispute above shows |
| Fragmentation | x402, L402, Visa's protocol, and Google's protocol don't yet interoperate, so an agent may need to speak several "dialects" of machine payment |
The honest summary: the plumbing for machine-native payments is real and shipping today, faster than most people realize. The judgment layer on top of it — what an agent should be allowed to do with that plumbing, and who's accountable when it goes wrong — is years behind. Treat any product claiming that part is "solved" with real skepticism.
Cards weren't built for this, and that's not a flaw. They were built for humans disputing charges. Machine-native rails (x402, L402, and whatever follows them) exist because that job description doesn't fit an API call that costs a fraction of a cent.
Bot detection is now a live, adversarial system. Every signal disclosed publicly — including the mouse-movement idea in section 04 — gets adapted around eventually. Treat any single detection method as one layer, not a solution.
"Agent-friendly" is not yet standardized. A protocol working with one card network or one crawler doesn't mean it works everywhere. Check what a given tool actually supports before assuming it's universal.
Autonomy and accountability are still being negotiated in public. The Amazon-Perplexity dispute won't be the last one. If you're building with agents that spend money, put hard per-action limits in place yourself — don't wait for the industry to agree on the rules.
Technically yes, but it breaks down at the amounts agents actually transact in. A typical online card fee (about 2.9% plus $0.30) costs more than the purchase itself below roughly $0.31 — and AI agents routinely pay per API call or per token, in amounts far smaller than that.
x402 is a payment protocol Coinbase and Cloudflare launched in September 2025 that activates HTTP's long-dormant 402 Payment Required status code, letting a server demand stablecoin payment before serving a request. Google, Visa, and Stripe later joined as founding members of the group now stewarding it.
By charging for access instead of giving it away. Protocols like x402 and Lightning's L402 let a server respond to a bot's request with a 402 status code and a price, then serve the content once payment clears — settling in fractions of a cent, automatically, with no human checkout involved.
The payment protocols only prove money moved — they don't decide whether a given request should be trusted. Prompt injection, unbounded spend, and unsettled liability rules are separate, still-unsolved problems. Hard per-action spending limits are a practical safeguard today.
Both revive the HTTP 402 status code for machine payments. x402, from Coinbase and Cloudflare, settles in stablecoins. L402, from Lightning Labs, settles over Bitcoin's Lightning Network in amounts as small as a fraction of a cent, with the payment receipt doubling as the access credential.