· 8 min read

Mastercard Just Built Card Rails for AI Agents to Pay Each Other in Fractions of a Cent. Before You Build "Sell to the Agent," Read the Fine Print.

AI Building in Public Lessons

On June 10, Mastercard launched Agent Pay for Machines, an open protocol that lets AI agents transact on their own, including micropayments worth fractions of a cent, settled across Mastercard's card and account rails. It shipped with 31 named launch partners, among them Stripe, Cloudflare, Coinbase, Adyen, the Solana Foundation, and Polygon. The framing writes itself: your next customer isn't a person, it's an agent, and you'd better be ready to take its money.

I want to take the technology seriously and the timeline skeptically, because those are two different things and the hype collapses them on purpose. The plumbing is genuinely being built. The business of getting paid by machines is, for a solo operator in June 2026, almost entirely a press release. The useful move is small, cheap, and not what the keynote wants you to do.

What Agent Pay for Machines actually does

Underneath, AP4M is four steps in sequence. It credentials a registered agent so the network knows what it is. It permissions what that agent is allowed to spend. It transacts across Mastercard's existing card and account rails. And it settles, in either traditional currency or stablecoins. The agent's credentials and spending permissions live on public blockchains: Mastercard names Polygon, Solana, and Base.

The part that's actually new isn't "an agent can pay." Agents have been able to fire a Stripe charge for a while. It's the economics at the bottom end: continuous, programmatic, sub-cent payments between agents, at a value and frequency that conventional card processing can't handle profitably. A tenth of a cent per API call, thousands of times an hour, between two pieces of software, is a transaction shape the card networks were never built for. AP4M is Mastercard trying to make that shape work inside the rails that already move trillions a year, rather than ceding it to crypto-native systems entirely.

That's a real piece of infrastructure. Thirty-one launch partners is a real coalition. None of that tells you when, or whether, it pays your bills.

"Agents are buyers now" is doing a lot of work

The seductive read is that a new customer segment just appeared (autonomous agents with budgets, shopping on behalf of humans) and the early movers who make themselves purchasable will eat it. There's a version of the future where that's true. There is not, today, a version of the present where a meaningful number of agents are out there spending real money at solo operators who set up the right endpoint.

Look at what's actually live versus announced across the broader agentic-commerce push. The consumer-facing flows that exist (agents buying physical goods from large merchants inside a chat assistant) run through a handful of big platforms and their enterprise partners. The sub-cent machine-to-machine economy AP4M is built for is the part that's newest, which means it's the part with the least real volume behind it. "Launch partner" means "agreed to build," not "processing your revenue." The gap between a protocol existing and a protocol mattering to your MRR is usually measured in years, and the people telling you otherwise are usually selling the protocol.

So the honest position isn't "ignore it." It's "the infrastructure is ahead of the demand, and you make money on demand, not infrastructure."

The one cheap thing actually worth doing

Here's where I'll give you something to do instead of just a warning, because there is a genuinely smart, low-cost move, and it happens to be good hygiene regardless of whether agent payments ever arrive.

Make your service consumable per call and priced per unit. That's it. If what you sell is an API, a data feed, a tool, or anything a piece of software could invoke, structure it so that a single discrete unit of value has a single discrete price: a clean endpoint, metered usage, a price per request or per result rather than only a $29/month human-shaped plan. You don't need to integrate AP4M. You don't need a wallet or a stablecoin or a blockchain anything. You need your product to be the kind of thing that could be bought one call at a time, by a human script today or an agent later.

The reason this is the right amount of effort is that it's not speculative work. Per-call, per-unit pricing is what makes your service usable in automations, cron jobs, and other people's pipelines right now: the actual paying customers of 2026. If the agent economy shows up, you're already shaped for it. If it doesn't, you've still built the more composable, more integrable product. There's no version where clean unit pricing is wasted, which is exactly the bar a speculative trend should have to clear before you spend a weekend on it.

Why "build for agent buyers in 2026" is a trap

Contrast that with the maximalist version: rearchitect your business around agents as the primary customer, build the wallet integration, wire up AP4M, lean into stablecoin settlement, write the launch post about how you're "agent-native."

That's a trap for a solo operator, and not a subtle one. You'd be spending your scarcest resource, focus, on a customer that doesn't exist at volume yet, using a standard that will change three times before it matters, to chase revenue you can't point to on a dashboard. Every hour on agent-payment integration in June 2026 is an hour not spent on the humans who'll actually pay you this quarter. The agentic future might be real and still be a terrible thing to build your Tuesday around.

The pattern to avoid is treating infrastructure announcements as demand signals. Mastercard shipping rails tells you Mastercard believes in the category. It does not tell you a single customer is waiting on the other end for you specifically. Those are wildly different facts, and the launch post is engineered to make you feel the second one while only proving the first.

What I'd actually do

Spend thirty minutes understanding AP4M well enough to not be surprised by it, and then go back to your real work. The concrete action item is the unit-pricing one: if your product can only be bought as a monthly human subscription, give it a per-call, per-result price too, because that's good for your 2026 customers and incidentally future-proofs you for agent ones. Skip the wallet, skip the integration, skip the agent-native rebrand. Revisit when you can name an actual agent that wants to pay you, not a protocol that theoretically could route the money.

The honest counter-take: I could be early-wrong rather than right. If agent-to-agent commerce inflects faster than I expect (and card networks putting their weight behind it is exactly the kind of thing that pulls a timeline forward), the operators who were already purchasable, already metered, already clean at the unit level will be the ones who catch it without a scramble. But notice that's the same advice. The hedge against being wrong about the timing isn't to bet big on agents now; it's to make the cheap, dual-use move that wins either way. Build the clean unit price. Skip everything else until the buyers are real.

Author

Lukas

Sources

More AI articles →

Stay in the Loop

Get new posts delivered to your inbox. No spam, unsubscribe anytime.

Newsletter coming soon. Set PUBLIC_CONVERTKIT_FORM_ID in .env to activate.

Related Posts