By now you’ve probably had your fill of AI agent content. Software paying software, entire economies running on autopilot, you know the pitch. You’ve also heard the guardrails, permissions and prompt injection sermons, which payments don’t really change so much as make more expensive. As if an agent wiping a production database wasn’t exciting enough. Moreover, I’m not going to relitigate any of it. Its not like people could be talked out of giving an LLM their treasury key by a blog post.
What I did fall into is how much agentic payments work is happening that isn’t x402. x402 gets the limelight, especially in crypto circles, and fair enough. But between the integrations, facilitators and hackathons, a lot is going on next to it. Google has AP2. Stripe and Tempo have MPP. Algorand just shipped AC2. Visa and Mastercard are building their own thing, and then there’s OpenAI’s ACP and Google’s UCP.
That’s a lot of acronyms. My first reaction was “great, a standards war,” because the only thing our industry enjoys more than building protocols is building slightly different ones for problems that already have protocols.
Turns out that’s not entirely fair. Some of them overlap, and there’s some corporate positioning going on (when isn’t there?), but they mostly aren’t solving the same problem. Which is how I ended up down this hole.
(Everything below is as of October 2026. Check back in a month and half of it will have a v2.)
A little more than HTTP 402
Coinbase’s x402 is the one most people know. It takes HTTP’s long-neglected 402 Payment Required and turns it into an actual payment flow: hit a paid endpoint, get the payment requirements back, authorize, retry, get your response. Simple, and a genuinely nice abstraction for machines paying machines. There’s more to the spec, but the docs will do it better than I would. And if you do go exploring, the crypto foundations will lure you in with SDKs, hackathons and grants like the witch in Hansel and Gretel. So go on, hack away.
x402 took off for pay-per-request: your agent needs an API, a dataset or some inference, and pays as it goes. Stripe and Tempo’s MPP shares the 402 approach but leans into sessions, metered usage and multiple payment methods. Sessions matter when you’re streaming inference for twenty minutes, where funding a session and settling usage as you go beats treating every tiny call as its own payment.
Before anyone objects: yes, x402 isn’t stuck on fixed prices anymore, since its newer spec has an upto scheme for usage-based payments. And MPP’s charge flow maps onto x402’s exact flow, so MPP clients can pay x402 services. These two aren’t headed for a cage match over who owns 402. Honestly, this is just billing models. A single API call, a streaming session and a subscription are different problems, even if an agent is the customer every time. We’ve had different billing models for different services for decades, and watching the industry rediscover that for autonomous software is mildly entertaining.
Then it stops being about moving money at all. Google’s AP2 isn’t a settlement network. It’s about proving authorization, through signed mandates: an Intent Mandate for delegated stuff (“buy this flight if it drops under €300”), a Cart Mandate when you approve a specific purchase live, and a Payment Mandate that tells the payment network an agent is involved. So instead of taking the agent’s word that it was allowed to buy something, everyone gets something to verify. It doesn’t solve intent, though. A mandate proves a purchase was authorized under certain constraints. Whether those constraints captured what you actually wanted is a different question, and I suspect we’ll be on that one for a while.
Algorand’s AC2 (built with Pera Wallet) attacks it from the credential side. The agent asks for a signature, you approve on your own device with a FIDO2 passkey, the signature goes back over an encrypted WebRTC connection, and the agent never touches the key. It’s chain-agnostic, and Algorand pitches it for approving x402 payments and signing AP2 intent mandates, so it’s a layer, not a rival. The catch is that it currently prompts for every signature. Delegation is promised for the next iteration, and that’s the part I want to see, because credential isolation that turns into a constant approval bottleneck is just a very secure way of annoying yourself. It’s also a v1.
And here’s what I didn’t appreciate at first. One protocol can define what an agent may buy, another how that gets signed, another how the payment executes, and they don’t have to come from the same organization. Whether they’ll actually fit together that neatly is another matter. We’ve all seen enough architecture diagrams where the arrows between boxes do far more work than the implementations ever will.
The traditional players aren’t sitting this one out
While crypto was busy making payments native to the internet, the card networks came at agentic commerce from the other direction. Visa’s Trusted Agent Protocol and Mastercard’s Agent Pay both lean on HTTP message signatures (via Cloudflare’s Web Bot Auth) so merchants can tell a legitimate agent from a bot. Mastercard also extends its tokenization infrastructure to agent-initiated transactions.
I find that significant, because it means this won’t be exclusively wallets sending stablecoins to paid endpoints. There’s a huge amount of existing infrastructure that merchants aren’t about to abandon, and these companies have spent decades on identity, fraud and disputes. The incentives differ too. Crypto-native protocols care about programmable settlement and tiny payments, while networks care about making agents legible inside what merchants already run. Neither is better. They’re starting from different places.
The crypto side does sometimes act like faster, cheaper settlement is the missing piece of every payment problem. If you’ve ever reconciled an ambiguous transaction, or dealt with a payment that succeeded while the rest of the operation failed, you know moving the money is usually the easy part.
And then there’s commerce
OpenAI and Stripe’s ACP handles structured checkout between agents and merchants. Google’s UCP, built with Shopify and retailers like Etsy, Wayfair, Target and Walmart, goes wider: discovery, checkout, orders. Both are a different breed from x402. They’re about talking to merchants’ existing systems, not an endpoint collecting a payment.
Unlike the cleaner splits above, ACP and UCP overlap quite a bit. Though Stripe co-authored ACP and also sits on UCP’s tech council, so it’s hedging, which is what everyone does when nobody knows who wins.
I’d love for merchants to integrate once and support whichever agent shows up. But I’ve done enough integrations to know how fast a “standard” interface becomes provider-specific exceptions, optional capabilities and creative interpretations of the same spec. I’d be surprised if the first few years of agentic commerce didn’t involve a lot of adapter code. It’s also a little funny to standardize agentic checkout while we’re still arguing about what a well-behaved agent should be allowed to do. But waiting for the lower layers to settle was never our style.
The part nobody demos
None of this is developing as one coherent stack. Everyone is approaching it from whatever infrastructure they already own: settlement from Coinbase, consumption patterns from Stripe and Tempo, authorization from AP2, credentials from AC2, merchant-side trust from the card networks, interop from ACP and UCP. I don’t think that’s bad, but I wouldn’t assume it composes cleanly either. Two protocols can solve different problems and still make incompatible assumptions about identity, trust, or what an “authorization” even is. Publishing a spec is easy. Getting independently built systems to agree on who verifies what, and what happens when it goes wrong, is the actual job.
I got stuck on the part after the transaction, partly because I am working on an insurance and refund model for paid x402 services. The awkward question: what does an agent do when it pays for something and gets a perfectly valid, completely useless result? The payment protocol did its job flawlessly, and you still paid for hallucinated data. Refunds aren’t new, but at fractions of a cent you can’t run a dispute process per response, and having another model grade the first one isn’t the trustless verification I’d bet on. I am leaning toward optimistic refunds with abuse detection and selective verification. That’s its own post.
What I’m fairly sure of is that this gets much more interesting once these systems carry real volume outside hackathons. We’ve all seen the demo where an agent finds a service, pays, and gets a response. I want to hear about recovery, reconciliation, delegated permissions, and failures across independently operated systems. Not launch-announcement material, but then again, most good infrastructure isn’t.
Anyway...
I went in expecting a few alternatives to x402 and came out reading about mandates, signing flows, card tokens and commerce specs and what-not. I’m not convinced there even needs to be one winner. There’s too much existing financial infrastructure for everything to collapse into a single protocol. What I’d rather see is agreement on the boundaries, so developers can combine these without reverse-engineering each other’s assumptions.
If you’ve made it through the rambling, I hope a few things landed on your radar beyond x402. Especially if you’re building in this space, because the interesting part might not be the payment at all. It might be how you delegate spending authority, keep credentials out of an agent’s runtime, or deal with merchants who have no intention of rebuilding their stack for your shiny new agent.
Some of these will end up as boring plumbing nobody thinks about, which is usually how you know infrastructure made it. Until then, there are plenty more specs to read, integrations to build, and presumably grants to apply for. And if all else fails, rename it ‘agentic’ and raise a seed round. Seems to be working for half the industry. Or you could skip all that and ship a ninth protocol that finally unifies the other eight. I’m sure that’ll go great.
Top comments (0)