When a new technology category creates a payment problem, the fintech industry's first instinct is to wrap. Wrap the existing rails in a new API, add an abstraction layer, and sell the new abstraction as the solution. This has worked — well enough — for many transitions: mobile payments, embedded finance, buy-now-pay-later. The underlying rails stayed the same; the interface changed.
The agentic payments problem is different in kind, not degree. The issue is not that existing payment APIs are hard to use for agents. It is that the assumptions baked into those APIs at every layer — identity, authorisation, compliance, settlement — are structurally incompatible with autonomous agent transactions. No wrapper fixes a structural incompatibility.
What wrappers actually do
A payment API wrapper abstracts the complexity of interacting with underlying payment rails — card networks, bank transfer systems, real-time payment schemes — behind a simpler interface. Stripe is the canonical example: it wraps the complexity of merchant acquiring, card network rules, and bank transfer protocols into a clean API that developers can integrate in hours.
What Stripe does not change is the underlying model of a transaction: a human or business initiates a payment, the payment is authenticated (the card is present, or a human approves the charge), the funds move, and a settlement occurs. Every assumption in that model is human-centric.
The three failure points
Identity is the first failure point. Stripe's identity layer — and every equivalent API — ultimately resolves to a Stripe account held by a legal entity. When an AI agent calls the Stripe API, it is acting on behalf of that entity, using credentials issued to it. The entity is the customer; the agent is a credential holder. This works until the agent needs to transact with a counterparty that also needs to be verified — at which point the non-human identity problem resurfaces.
Authorisation is the second failure point. Payment APIs implement authorisation by issuing API keys, OAuth tokens, or similar credentials to the agent. The agent uses these credentials to initiate transactions. But credentials do not encode policy. An API key does not know that the agent should only pay suppliers in the EU, or only transact below £10,000, or only execute payments when a specific set of conditions is met. Policy has to be enforced at the application layer — which means every application that uses the agent must re-implement it. There is no programmable, portable, verifiable policy layer in any existing payment API.
Settlement is the third failure point. Existing payment rails settle in batches, at fixed intervals, between pre-registered counterparties. They do not support conditional settlement — "pay when condition X is met" — or streaming payouts — "pay £0.001 per second for the duration of this task." These payment primitives, which the agentic economy requires, do not exist within card network rules or bank transfer schemes. They would require changes to the rails themselves, not just the APIs that wrap them.
What would actually need to change
Solving the agentic payments problem requires infrastructure change at three levels. First, a new identity layer: a mechanism for asserting and verifying agent identity and delegation chains that is recognisable to counterparties, compliance systems, and regulators — without requiring a human to be present at each transaction.
Second, a programmable authorisation layer: a standard for encoding payment policy in a portable, verifiable format that travels with the agent. This is closer to a smart contract than an API key — a set of rules that can be verified by any counterparty without reference to the originating system.
Third, new settlement primitives: payment instruments that support conditional execution, streaming, and real-time finality without the batch-settlement constraints of existing rails. Stablecoins and programmable money offer one path here; real-time payment scheme extensions offer another.
The companies building in this space — and there are now dozens of them — are attempting various combinations of these three layers. None has assembled a complete stack. The infrastructure gap is real, and it will not be closed by wrapping Stripe.