The payments layer Stripe can’t build — using Base for sub-dollar and agent-to-agent flows

This is the third post in the QuackBuilds architecture series. The first covered the catalog and the autonomic generation layer at a high level. The second walked through the long-running compute tier — Oracle ARM and Coolify — that handles what serverless can’t. This one is about the payments layer, which is the piece that makes the whole economic model work, and the piece I expect the most pushback on. So let me start by trying to defuse the pushback, because I think the technical case is stronger than the cultural one.
Most developers reading this have integrated Stripe at some point, and Stripe is genuinely excellent at what it does. If you’re charging twenty dollars a month for a SaaS subscription, or seventy dollars for a one-time purchase, or any of the standard shapes that dominate online commerce, Stripe is the right answer and you should not overthink it. The reason QuackBuilds doesn’t use Stripe is not that I dislike Stripe. It’s that the products I’m building live in two payment shapes that Stripe was never designed for, and that no traditional payment processor can serve well, because the limitation isn’t software — it’s the underlying card network economics.
The first shape is sub-dollar payments. If you’ve ever tried to charge five cents for something on the open web, you already know this story. Stripe’s fee structure starts at thirty cents plus 2.9 percent per transaction, which means a ten-cent payment costs you thirty-three cents to process, and you lose money on every transaction. This is not a Stripe problem. It’s a Visa and Mastercard problem, baked into the card network’s settlement model decades before microtransactions were a use case anyone was thinking about. The workaround the SaaS world settled on is to bundle: charge ten dollars a month instead of charging per use, accept that some users will pay for capacity they don’t need, and live with the fact that genuinely small payments are infeasible. That bundling tax is invisible most of the time, but it shapes the entire shape of what gets built. Tools that would naturally cost a few cents per use either don’t exist or get crammed into a subscription wrapper that distorts their economics.
The second shape is agent-to-agent payments. This one is more speculative, but it’s where the architecture is heading and it’s the reason I made this choice rather than waiting. If part of QuackBuilds’ eventual design is autonomous agents that scaffold and ship apps, and those apps in turn might consume APIs, call models, hire other agents to do subtasks, then the payment layer needs to support a software process initiating a payment without a human in the loop. Stripe is built around the assumption that there is always a human approving a transaction — a card on file, a customer who agreed to a subscription, a user clicking a button. Agents don’t fit that mental model. They have budgets, not credit cards. They make decisions in milliseconds, not minutes. They need to pay other agents that may not have a Stripe account at all. The card network can’t serve this use case, and even if it could, the per-transaction fee structure would make most agent-to-agent calls economically irrational.
Onchain payment rails solve both problems by accident, because they were designed under different assumptions in the first place. A USDC transfer on Base — Coinbase’s Ethereum L2 — costs a fraction of a cent in gas, settles in two seconds, and doesn’t care whether the sender is a human, a bot, an agent, or another contract. The address format is uniform across all of them. There is no signup flow, no merchant account, no underwriting, no chargeback risk, no minimum transaction size. A five-cent payment costs functionally the same as a five-thousand-dollar payment, which is the property that makes microtransactions economically possible in the first place. The fee shape is essentially flat where the card network’s fee shape is regressive against small payments.
The integration on the developer side is less exotic than people expect. I’m using a combination of OnchainKit (Coinbase’s React component library for Base) and the underlying viem library for direct contract interaction. Adding “pay with USDC” to a frontend is genuinely a few components and a wallet connect — comparable in complexity to adding a Stripe checkout button, and arguably simpler because there’s no backend webhook handling or session management to worry about. The user signs a transaction in their wallet, the funds arrive at my treasury address two seconds later, and the frontend can confirm the payment by watching the chain. No backend strictly required, though I do run one for accounting and to trigger any post-payment workflows. For users who don’t already have a wallet, MoonPay and Coinbase’s onramp let them buy USDC with a card directly inside the flow, which softens the onboarding problem considerably from where it was even two years ago.
The honest tradeoffs, because I keep promising not to write puff pieces. Crypto onboarding is still a real friction tax, and pretending otherwise is dishonest. A user who already has a wallet pays in two clicks. A user who doesn’t has to either install one or use a card-onramp, both of which are slower than a Stripe checkout for the user’s first payment. I think this friction is decreasing fast — Coinbase’s smart wallet flow, in particular, has gotten genuinely close to “sign up with email” — but it’s not zero today and it would be silly to claim otherwise. The other honest tradeoff is regulatory ambiguity, which varies by jurisdiction and changes constantly, and which I navigate by keeping the payment surface small and well-understood (USDC, a stablecoin, on a Coinbase-operated L2) rather than by getting clever. I’m not running a token sale. I’m accepting digital dollars on a fast network. That framing matters both legally and culturally.
The architectural payoff is worth restating, because it’s the reason all of this is worth the integration cost. With onchain rails in place, every app in the QuackBuilds catalog has access to a payments layer that supports any transaction size from a fraction of a cent upward, supports payment from humans and agents alike, settles in seconds, and costs essentially nothing to operate. Combined with the zero-fixed-cost compute tier from the previous post, what emerges is a stack where shipping a new app, hosting it, and monetizing it can all happen at near-zero marginal cost. That cost shape is what makes the catalog model — many small tools, each potentially cheap or free — economically viable in a way it simply isn’t on a traditional SaaS stack. The technology is, in a real sense, downstream of the economics. I picked Base because the cost curve made the product I wanted to build possible. If Stripe had built a microtransaction product five years ago, I’d probably be using that instead.
That closes out the architecture series for now. Three posts, three layers — the catalog and generation vision, the long-running compute tier, and the payments rail. The next thing I write will probably be from the other direction: not how it’s built, but how it gets used. What a single app in the catalog looks like end-to-end, why I chose to build it, what I learned shipping it. If there’s a specific app from the catalog you’d want that writeup to be about, drop it in the comments and I’ll pick the most-asked.
— @itsevilduck / quackbuilds.com