Most discussion about agentic payments describes the same consumer future, where your AI assistant books your flights, orders your groceries, buys your concert tickets, and maybe negotiates with the airline’s agent or splits the bill with your partner’s agent along the way. It demos well and it’s easy to picture, which is why most of the coverage stops there.
That framing isn’t wrong, though it doesn’t paint the full picture and can be misleading. The consumer use cases are real, but they’re not where the volume is going to land first, and they’re not what enterprises should be planning around.
The bigger story is that enterprise AI agents are starting to spend money on behalf of teams, across vendors, at a frequency and granularity no human procurement process was ever designed for. This is already underway inside some of the largest companies in the world.
Across almost every sector, AI roadmaps are about to collide with payments stacks, and that goes for payments providers, fintechs, and financial institutions as much as anyone. That collision is the thing worth paying attention to.
What “Agents Spending Money” Actually Looks Like Inside a Company
The clearest way to understand the shift is to look at what enterprises are already doing with AI today and then extend the line by twelve months. Three patterns are showing up consistently:
- Ad operations: Marketing teams are handing campaign briefs to agents that go past generating creative and actually execute it. Inside that flow are five or six payments to five or six counterparties, all kicked off from a single prompt and a single budget envelope. Today most of this is stitched together with corporate cards and someone in finance reconciling it after the fact, which doesn’t scale past a handful of campaigns.
- Developer infrastructure: Engineering teams are letting agents provision cloud resources, call paid APIs, run inference, and pull data from third-party providers. Every one of those calls is a transaction. A single research agent hitting five APIs can generate forty or fifty discrete payment events, and multiplied across the engineering org that’s a payments problem your finance team has no system of record for.
- Procurement and operations: Ops and finance teams are pointing agents at travel bookings, contractor onboarding, vendor sourcing, and supply-chain top-ups. Each of those tasks ends in a commit, and the commit step is a payment. The approval chain that used to sit in front of that step wasn’t built to run at agent speed.
These three themes are already showing up inside customers we talk to every week. Agent capability isn’t the constraint. What’s missing is the payments layer that lets an agent transact with controls a CFO would sign off on.
Why the Existing Rails Don’t Work for This
Once you start looking at agentic spend as a real workflow rather than a consumer demo, the cracks in the existing payments stack show up fast.
Cards were built for a different problem. They assume a human at a checkout, a relatively small number of transactions per cardholder per day, and an interchange model that breaks below a couple of dollars per swipe. The unit economics don’t work, and the controls were never designed to be programmable in the first place. You can set a credit limit, but not a rule that caps spending at $200, scopes it to EU-based localization vendors, applies only below a $4 per-minute rate, and expires at midnight.
Bank transfers have the opposite problem. The controls are richer, but the latency, fees, and operational overhead make them useless for anything that needs to settle inside a workflow rather than overnight. Every transfer also assumes a person initiates it and, in most treasury setups, a second person approves it, which is the exact step agentic workflows remove.
What an agent actually needs to transact looks more like this:
- Programmable controls: Budget caps, scope limits, expiry windows, counterparty whitelists, and conditions the human defines and code enforces.
- Economics that work at small denominations: A fraction of a cent has to settle as a real transaction, because agent spend arrives as thousands of tiny payments rather than a handful of large ones.
- Composability: Payments have to nest inside workflows, because a single task can spawn a chain of agents and services that each need to transact and reconcile without a handoff to a person.
- Auditability: Every action, authorization, and dollar has to be accounted for in a form finance can actually close the books on.
Stablecoin rails, with the right infrastructure on top of them, hit all four. No other set of rails does today. This is why the infrastructure conversation is now about how to build on them rather than whether to.
Protocols Aren’t Enough Without a Wallet Layer
Most of the public discussion about agentic payments has focused on protocols. x402 and MPP have gotten a lot of attention in the last few months, and rightly so, because they’re how two pieces of machine code agree to exchange value over HTTP. Important plumbing, but still plumbing.
But protocols on their own don’t get you to enterprise deployment. The piece that decides whether an agent can actually transact, and the thing the team at Dynamic spends most of its time on, is the wallet layer underneath.
Any agent with spending authority needs a wallet to spend from. It needs a programmable and non-custodial embedded wallet with a policy engine attached, an identity layer that can prove which human authorized which agent for which scope, and the kind of key management institutions can defend in front of a board.
Issuing a corporate card to an AI agent is the wrong abstraction. The card model assumes a single accountable holder, a static credit line, and a fraud system designed for human behavior patterns. Agents don’t behave like humans: they make a hundred decisions a second, they spawn sub-agents, and they hand off tasks. The wallet they transact from needs to be built for that shape of activity from the ground up.
This is the layer most enterprises haven’t started thinking about yet. They’re focused on which model to use, which orchestration framework to standardize on, and which use cases to ship first, all of which are worth doing. None of it works in production, though, until the agent has somewhere to hold money, authorization to spend it, and rails to actually move it.
We’ve seen what this looks like when it gets built right. Papaya Global launched Banco Wallet with Fireblocks last year, paying contractors across more than 180 countries with embedded wallets that handle wallet creation, FX, and the payout itself. Workers see instant payouts, Papaya runs the experience, and the wallet layer stays invisible. Enterprise agentic infrastructure will need the same architecture, pointed at agents instead of contractors and running at far higher transaction frequency.
What’s Still Being Built, and Why the Timeline Is Shorter Than It Looks
The honest answer about agentic payments today is that the protocols work, the rails work, and the wallet infrastructure works. What’s still being built is the production-grade layer that connects them to the existing payments world enterprises already run on. For this to happen, three pieces have to come together:
- Security: Agents need institutional-grade key management (MPC), policy enforcement, and defense-in-depth controls built on the assumption that the agent will at some point try to do something it shouldn’t. This is what separates a pilot from a production system.
- Compliance: AML, KYC, travel rule, and jurisdictional coverage all apply, because agents transacting across borders run into the same compliance perimeter human payments do. The infrastructure has to handle that without a finance team manually reviewing every flow.
- Backward compatibility: Agentic flows have to work with the PSPs and merchant relationships enterprises already have, not alongside them. Asking the rest of the market to rewire around a new payment model is not a plan anyone can execute on.
Most enterprise rollouts currently in flight are twelve to eighteen months from the moment their agents need to pay for something. Companies that sorted out the payments layer early will put agents into production on schedule. The ones that didn’t could spend two quarters diagnosing why their agents can’t transact, and another two buying the infrastructure to fix it.
What This Means for Your Roadmap
None of this requires a dramatic response.
Start by mapping where AI agents are already operating inside your business and where they’re hitting payment-shaped problems. This might be found in procurement, ad operations, dev infrastructure, and customer management. Then ask whether your current payments stack could support those flows if volume went up 50x, because that’s roughly where the volume is heading.
Treat the wallet and policy layer as an architectural decision rather than a procurement exercise. It touches identity, treasury, risk, and engineering, so getting it wrong means rebuilding across four functions. The teams furthest along are staffing this the way they staffed cloud migration, with engineering in the room from the start.
None of this needs a new budget line this quarter. It needs someone senior enough to own the question of how your agents will pay for things, before the answer becomes urgent. If that person is you, the useful next step is a conversation about what your agents will actually need to transact. Book a call with our team to learn more.
