Machine-to-machine payments have a price floor: Coinbase Institute's October 7 paper puts the card's at $1.19, and every API seller should know their own

What the Coinbase Institute published on October 7, 2026

On October 7, 2026, the Coinbase Institute, the company's policy research arm, published Machine-to-machine payments in the AiFi era. Chief Policy Officer Faryar Shirzad shared it the same day. In his post he wrote that the internet was built to make money from people, through attention, ads, subscriptions and checkout. "AI agents are changing that. They can retrieve and use content without sending a human reader back to the publisher."

The paper's starting point is traffic. Citing Cloudflare data, it says bots made 60.4% of requests for web pages in August, against 39.6% from humans. Software that reads pages sees no ads and buys no subscriptions, and those are the two ways much of the web pays for itself. So publishers, data providers and API developers need a way to charge per use. That includes uses worth a fraction of a cent.

Its worked example is small on purpose. A delivery-routing program needs rainfall data for a stretch of road that the big weather services cover poorly. It buys one reading from a small sensor network. Using x402, the server answers with an HTTP 402 Payment Required that lists the price, asset, recipient and network. The agent signs a 0.01 USDC payment on Base and gets the data. The paper says payment and delivery take about two seconds and the network fee is under $0.001. Nobody opens an account or sends an invoice.

The policy ask is equally direct: "an open, interoperable payment layer, with safeguards that match the risks — not closed marketplaces that decide who can participate." The paper also proposes identity checks that scale with the money at stake. A program spending fractions of a cent on a $5 monthly budget shouldn't face the same checks as one moving tens of thousands of dollars.

One disclosure before the numbers. Coinbase incubated x402 and runs the most-used facilitator, so it has a stake in this argument. So do we: Payzum settles x402 payments through Coinbase's facilitator today. That's why the analysis below relies on arithmetic you can check yourself rather than on anyone's adjectives.

Machine-to-machine payments: the smallest payment each rail can carry

The paper calculates, for each payment method, the smallest amount at which fees fall to 5% of the payment. Here are its figures, with what each means for a seller billing per request.

Read it as a price floor, not a fee comparison

Most coverage read the table as "stablecoins are cheaper". The more useful reading is that every rail has a floor, and the floor comes from the fixed part of the fee. With a percentage fee p and a fixed fee f, the smallest payment that keeps total fees at 5% is:

floor = f ÷ (5% − p)

Plug in a standard 2.9% + $0.30 card price: $0.30 ÷ 2.1% = $14.29. That's exactly the top of the paper's card range. Now try shaving the percentage to 2.5% and keeping the $0.30: the floor only falls to $12. Remove the percentage entirely and the floor is still $6. The fixed fee is the floor. A seller can't negotiate their way under it. The only options are to move to a rail with a smaller fixed cost per payment, or to make each payment bigger.

This explains a pattern every API business already knows. Developer APIs bill monthly, sell prepaid credits or impose minimum top-ups, and their pricing pages are full of "per 1,000 requests". Nobody thinks a thousand is a natural unit. It's the smallest bundle that clears the card floor. When the customer is a person with a dashboard, bundling works. When the customer is an agent that finds you halfway through a task and needs one record, the bundle is the obstacle.

Your floor is the rail plus your processor

The paper's stablecoin floor of $0.002–$0.02 covers the network fee only. But sellers don't just pay the network. They pay whoever turns a 402 into a settled payment and a delivered response. Here's our own pricing as the honest example. Through Payzum's x402 proxy, roughly the first 1,000 transactions a month are free, then it costs about $0.001 per transaction plus gas. Apply the formula and Payzum's per-call fee alone reaches 5% at $0.02 per call:

The lesson isn't that sub-cent pricing is impossible. It's that the billing unit is a design decision. If a single row is worth $0.001, sell 50 rows for $0.05: a batch endpoint, a page of results, a day of readings. The paper's own example is priced at 0.01 USDC, not 0.001. Between roughly $0.02 and $1.19 sits a wide band where per-request stablecoin billing works and no card price does. For most data and API sellers, that band is where the agent business is.

Two floors the table leaves out

The dispute floor

The paper puts the cost of handling one card dispute at $15 or more, and close to $128 once every cost is counted. Set that next to a low-priced sale. At $1 a sale, one fully loaded dispute wipes out the revenue from 128 sales. At $0.10 a sale, it wipes out 1,280. Card economics assume disputes are rare relative to ticket size. Agent purchases are tiny and come in large numbers, so that assumption breaks.

An x402 payment in USDC on Base is final once it settles. There's no chargeback window and no dispute fee. That doesn't mean buyers have no recourse. It means the recourse is your refund policy: if a call failed or returned bad data, you send the USDC back. For a seller of machine-readable data, that's usually simpler than defending a dispute with screenshots.

The underwriting floor

The third floor isn't measured in dollars. It's who gets to accept cards at all. As coverage of the paper notes, a developer running a data service alone, or a small archive, usually has to show a registered company, a record of past payments and a website, and often has to guarantee the account personally, before a card processor will take them on. The sensor network in the paper's example is exactly the kind of seller that fails that test.

An x402 seller still has to be someone. Payzum runs KYC on merchants. But there's no card acquirer pricing your chargeback risk, and because Payzum is non-custodial, there's no balance it holds and no reserve to keep back. Payment goes from the agent's wallet to yours.

60.4% bots: the number that matters is smaller

The 60.4% figure is real, but read what it measures: requests for web pages. Across all traffic, including apps, video and API calls, the bot share on Cloudflare Radar is much lower. And most of those bots are crawlers and indexers, not agents with a budget and a wallet. x402 doesn't turn a crawler into a customer. What it does is give you a price you can quote to the requests that are able to pay, and an answer for the ones that aren't.

The rainfall example shows which requests are worth pricing first. It isn't "anything a bot touches". It's data that's scarce where the agent needs it: a fresh reading, a licensed dataset, a niche record the big providers cover poorly, compute that costs you real money. A simple ladder works for most sellers. Keep a free sample or summary, charge per call for the full record, and offer a bulk endpoint for the agent that wants a lot. The first independent audit of x402 sellers pointed the same way: the sellers who kept earning sold something specific, not generic access.

What the paper leaves to the seller

Much of the paper is about the buyer side: how an agent proves who stands behind it, how its budget is set, and how checks scale with spend. Those are real questions, but they're mostly answered by the buyer's wallet and spending controls. The seller's job is shorter:

• Publish a price per unit that clears your floor.
• Return a 402 that tells the agent what to pay, in which asset, on which network and to whom.
• Deliver only after the payment checks out. In x402 the payment arrives before the response, so there's no credit risk and no invoice to chase.
• Have a refund policy for failed or bad responses, because there's no chargeback system to fall back on.

The paper also flags that stablecoin activity is concentrated in a few dollar tokens. For x402 on Base, that token is USDC, which means the seller is holding dollars, not a volatile asset.

How to price an endpoint for agents with Payzum, step by step

1. Pick the endpoint and the unit. Start with one endpoint where your data or compute is the scarce input. Use the formula above to choose a per-call or per-bundle price that clears your floor.
2. Configure it in the Payzum dashboard. Enter your existing endpoint, the API key or bearer token it already expects, and the USDC price. You don't write code or implement the protocol.
3. Payzum publishes an x402 URL. When an agent calls it, Payzum returns the 402 with the price, USDC on Base, and your wallet as the recipient.
4. The agent pays and gets the response. Payzum settles the payment through an external facilitator (Coinbase's, today), then proxies the paid request to your real endpoint with your key and returns the response.
5. USDC lands in your wallet. Settlement is non-custodial, direct to an address you control. Watch which units sell and adjust the price or bundle size from the dashboard.

Your existing customers keep their API keys and plans. The x402 URL is an extra door for agents that don't have an account with you, and it can be live the same day. The x402 page has the overview, and the docs cover the setup.

Who should move first

• Niche data providers. Sensor networks, local weather or traffic feeds, price and inventory data. These are the paper's own example. Each reading is worth cents to an agent, and card rails can't price a single reading. See selling market data to AI agents for the trading-agent version of this market.
• Publishers and archives carrying crawler load. If agents read your pages without sending readers back, a per-article or per-bundle price is a way to get paid for what they already take. It also gives your crawler policy a third option besides "block" and "allow free".
• API startups whose calls are worth $0.02 to $1. Enrichment, inference, validation, search. This is the band where per-request stablecoin billing works and card pricing can't price a single call. Compare it with your current setup in x402 vs API-key billing.

Card checkout vs prepaid credits vs x402 via Payzum

Common objections

"Agents can just use our API keys and a monthly plan."

Agents whose owner already signed up can, and nothing here replaces that. The issue is the long tail: the agent that finds your endpoint in the middle of a task, needs ten calls, and has no human around to fill in a signup form. For that buyer the signup is the wall. An x402 URL lets it pay without one.

"Sub-cent pricing isn't worth the trouble."

For single calls at $0.001 through any processor with a per-transaction fee, we agree. That's what the table above shows. The fix is the unit, not the rail. Sell a batch at a price that clears your floor. The paper's own example is a cent.

"Isn't Coinbase talking its own book?"

Partly, yes. It created x402 and runs its biggest facilitator, and Payzum settles through that facilitator too. But the floor formula doesn't depend on who publishes it. A $0.30 fixed fee sets a $14.29 floor at 2.9%, whoever writes the paper.

"Is Payzum the facilitator?"

No. Payzum is the middleware in front of your API: it returns the 402, has the payment settled by an external facilitator (Coinbase's today), and proxies the paid call to your endpoint. You don't run a node, hold keys for anyone else or implement the protocol.