The problem no one talks about at AI conferences
Every developer building AI agents hits the same wall. Your agent needs to buy something — a Twilio SMS, a Serper search, a Fal inference — and you have no clean way to let it do that.
The options are bad. You either hardcode your personal Stripe key into the prompt (nightmare), build a bespoke billing layer for each service (months of work), or wrap everything in human-in-the-loop approvals that defeat the point of autonomous agents entirely.
This isn't a fringe problem. Autonomous agents are already being deployed by indie developers at serious scale — research bots, outreach agents, content pipelines. They all hit this wall.
The number: Juniper Research estimates AI agents will handle $93 billion in transactions by 2032. The infrastructure to process that doesn't exist yet. Three protocols are racing to fill the gap.
The good news: three serious payment protocols for AI agents are now live or approaching GA. They solve the problem in completely different ways. Understanding each one — what it's actually for, where it breaks down, and who it's built for — is the difference between shipping something and getting your credit card charged in ways you didn't expect.
<\!-- Protocol 1: x402 -->Protocol 1: x402
An open payment protocol built on top of HTTP 402 ("Payment Required"). Coinbase built it, Cloudflare ships it in Workers. The idea: any HTTP endpoint can require payment before responding, and agents can pay on-the-fly without pre-registration.
How it works
x402 extends HTTP with two new behaviors. When a resource costs money, the server returns 402 Payment Required with a X-Payment-Requirements header describing what's needed. The agent pays using the X-Payment header on the retry. The transaction settles on-chain (Base/USDC), and the server responds with the actual content.
Who it's for
Developers building agents that call many different services. x402 is the only protocol where you don't need pre-established accounts with each vendor — the agent just pays per call. For high-volume, low-value transactions (thousands of API calls at fractions of a cent), this is the cleanest model.
The catch: your agents need to hold crypto (USDC on Base). If you're in a regulated industry or your company has a "no crypto" policy, you're blocked. Settlement latency is also non-zero — Base finality is ~2 seconds, which matters if you're doing real-time agent interactions.
<\!-- Protocol 2: Stripe ACP -->Protocol 2: Stripe ACP
Stripe's Agent Commerce Protocol. Embedded into ChatGPT's shopping flows. Built for agents making structured purchase decisions in existing checkout systems — subscription upgrades, marketplace transactions, B2B procurement. Settles in fiat via Stripe's existing rails.
How it works
ACP is a structured protocol layered on top of Stripe's payment APIs. Merchants expose a machine-readable "catalog" of purchasable items. Agents authenticate via OAuth, browse the catalog, and initiate purchases through structured endpoints. There's no crypto — everything flows through Stripe's existing card rails.
Who it's for
The answer is in the integration: ChatGPT. ACP is designed for consumer-facing agents making structured commerce decisions — booking travel, upgrading subscriptions, placing orders. If your product lives in an ecosystem that's already plugged into Stripe (most SaaS), this requires zero new payment infrastructure on the vendor side.
The catch: ACP has a pre-authorization model. The agent needs a payment method registered in advance, which means there's a human signup flow before autonomous operation. It's also vendor-dependent — the merchant has to explicitly support ACP. Today that means big platforms. The long tail of APIs that agents actually call (Twilio, Anthropic, Resend) isn't there yet.
<\!-- Protocol 3: Visa TAP -->Protocol 3: Visa TAP
Visa's Token Attestation Protocol. Where x402 is a startup's take on agent payments and ACP is Stripe's, TAP is the incumbent financial system's answer. Built on the same tokenization rails Visa uses for Apple Pay — but extended so AI agents can carry their own payment tokens with spending constraints baked in.
How it works
TAP issues each agent a payment token — functionally similar to an Apple Pay token, but purpose-built for software agents. The token carries cryptographic constraints: max spend per transaction, approved merchant categories, time-boxed validity. When the agent transacts, Visa verifies the constraints in real time at authorization. The merchant sees a normal Visa charge.
This is the same tokenization infrastructure that processes billions of Apple Pay and Google Pay transactions today. For an agent, it means: works at any Visa-accepting merchant, globally, without the merchant needing to integrate anything new.
Who it's for
Enterprises. TAP's strength is its acceptance footprint — if your agent is booking a hotel, buying office supplies, or paying an invoice, TAP works wherever Visa works (which is everywhere). The constraints system gives compliance teams the controls they need: CFOs can sleep at night knowing their procurement agent can't spend more than $500 per transaction at unauthorized merchants.
The catch: You're not getting a TAP integration as an indie developer today. Enterprise rollout, bank partnerships, and a KYC process that assumes you have a legal entity and a compliance team. For small developers, this is a 2027 story at the earliest.
<\!-- Comparison -->Side by side
| Dimension | x402 | Stripe ACP | Visa TAP |
|---|---|---|---|
| Settlement | USDC on Base | Fiat via Stripe | Fiat via Visa network |
| Merchant setup | Any HTTP endpoint | Stripe integration required | None (universal acceptance) |
| Agent setup | USDC wallet required | OAuth + pre-auth card | Token issuance via bank |
| Best for | API microservices, high volume/low value | Consumer shopping, SaaS upgrades | Enterprise procurement, real-world spending |
| Dev accessibility | High — open source, npm install | Medium — Stripe account required | Low — enterprise contracts |
| Spending controls | Application-layer only | Stripe billing rules | Cryptographic, enforced by Visa |
The real problem: none of them are a complete stack
Every serious agent deployment uses multiple services. Your research agent calls Serper (might use x402), books a flight (needs ACP or TAP), and pays for a SaaS API (neither x402 nor ACP supports it well today). You end up implementing three different payment flows, managing three different credential stores, and getting three different billing summaries that you have to reconcile yourself.
That's where we are in 2026. The protocols exist. The SDKs exist. What doesn't exist is a unified layer that handles all three, enforces spending rules consistently, and gives you a single dashboard for where your agents are spending money and why.
This is what Trove is building. One SDK that speaks x402, ACP, and TAP. Programmable spending rules enforced before any payment leaves the wallet. Real-time cost attribution across every agent, every protocol, every vendor. Join the waitlist →
Want to see it in action? Build an AI Agent Wallet in 5 Minutes — a hands-on tutorial with real API calls.
What to watch
The protocol that wins won't necessarily be the best technical design — it'll be the one with the best distribution. x402's ace is Cloudflare Workers (millions of developers, zero friction to add 402 support to any edge function). ACP's ace is OpenAI (if ChatGPT Shopping becomes the default consumer agent, every merchant will implement ACP or get left out). TAP's ace is Visa's existing rails — the moment banks issue TAP tokens at scale, agents can spend at 80 million merchants without any new integrations.
The honest answer: all three will coexist, the same way credit cards, ACH, and PayPal all coexist today. The infrastructure question is who builds the abstraction layer above them — and that's the bet worth making right now.