Agent Payments

The infrastructure gap nobody solved yet.

There is a peculiar moment in every agentic workflow where the model reasons its way to a solution and then stops. It has found the flight combination, identified the API, located the data source, or found the tool it needs. Then it hits the one primitive the rest of the web was never designed to give it: the ability to pay.

The irony runs deep. The world's most capable reasoning systems — systems that can write code, plan logistics, synthesize research, and orchestrate complex workflows — cannot buy a $0.05 API call without a human stepping in to swipe a card. The intelligence layer arrived before the payment layer. Now the payment layer is scrambling to catch up, and the early solutions are revealing exactly how much conceptual debt has been accumulated.

This essay is about that gap — what makes it hard, what the first generation of solutions got right, what they got wrong, and the open questions the industry is only beginning to ask.

The scale of the mismatch

Payment infrastructure was not designed for machines. The entire stack — card networks, fraud models, authorization flows, dispute resolution, merchant agreements, interchange rates — was built to handle one specific actor type: a human holding a physical card, standing in front of a terminal, making a decision in real time.

The numbers expose the mismatch immediately. Visa and Mastercard charge merchants between 1.5% and 3.5% per transaction, plus fixed per-transaction fees. For a $50 dinner, that is $1.75 — invisible friction. For a $0.02 API call to a weather service, that fee structure does not just reduce margins; it makes the transaction mathematically incoherent. The fee exceeds the payment by an order of magnitude.

This is not an edge case. The emerging agent economy runs on micropayments: API calls at fractions of a cent, per-token compute billing, metered data access, sub-second service invocations. AI agents completed 140 million payments over nine months in 2025, averaging $0.31 per transaction. The median transaction in an agent workflow is not a software subscription — it is a metered resource invocation smaller than the rounding error in a traditional payment system.

Card rails were engineered for the wrong granularity by several orders of magnitude. This is not a fee negotiation problem. It is a structural mismatch that no amount of interchange optimization fixes.

The fraud model problem

Fees are the visible problem. The deeper problem is that the entire fraud detection stack — the invisible infrastructure that determines whether a transaction succeeds or fails — was built to recognize human behavior and flag deviations from it.

Fraud detection uses signals like: is this IP address associated with this cardholder's usual geography? Is the typing speed consistent with a human? Is the purchase pattern consistent with this person's history? Does the device fingerprint match? Is there a biometric confirmation? Is there a human present to confirm via SMS?

Agents do not have typing speed. They do not have a geography. They do not have a purchase history that looks like a human's. They operate headlessly, across data centers, often in batch, at velocities that would be flagged as fraud if a human account attempted them. The signals that catch human fraud fail systematically against autonomous agents — not because agents are adversarial, but because they do not look human.

The same properties that make agents efficient — speed, scale, lack of hesitation — are exactly the properties that card networks are trained to treat as suspicious. A fraud model tuned on human transaction patterns will, by construction, either over-block legitimate agent activity or under-detect actual fraud in agent transactions. There is no middle ground; the model was not built for this actor type.

The identity and liability problem

Beneath the fraud problem is a harder one: cards carry human identity. The Visa cardholder agreement is between Visa, the issuing bank, and a natural person. Every concept in that legal structure — cardholder consent, authorized use, dispute rights, chargeback liability — assumes a human actor who can assert intent, recognize an unauthorized charge, and initiate a dispute.

When an agent makes a payment, who is the responsible party? If the agent was manipulated via prompt injection — a malicious document that altered the agent's behavior and directed it to make unauthorized purchases — who bears the liability? The user who configured the agent? The platform that ran it? The model provider? The developer who built the integration?

Card networks have no framework for this. Their dispute resolution assumes a human who can say "I did not make this purchase." An agent that was manipulated into making a purchase did, in a narrow technical sense, make it. The authorization token was valid. The card credentials were legitimate. The fraud model was not triggered. But the user's intent was not served — and the infrastructure has no concept of the difference between authorized agent behavior and manipulated agent behavior.

What the card-in-hand approach gets right

Given all of this, the first generation of agent payment solutions did the pragmatic thing: they mapped the agent payment problem onto existing card infrastructure by issuing virtual cards scoped to agents.

AgentCard gives each agent a one-time-use virtual Visa card for each transaction. The card is created when the agent needs to pay, used once, and self-destructs. Unused holds release automatically after seven days. Every card creation requires human approval — via notification or email — before the agent can complete the transaction.

Crossmint's architecture goes further: per-transaction spending caps, daily limits, merchant category whitelists, human-in-the-loop thresholds for purchases above specified amounts, and auditable logs for compliance review. Robinhood's Agentic Credit Card allows spending limits, monthly caps, and a manual-approval toggle — the agent never sees the primary card number or account details.

This approach is genuinely useful. It works today. It requires no new merchant integrations, no new protocol support, no blockchain infrastructure. Every website that accepts Visa already works. The agent gets a payment credential; the merchant sees a legitimate card transaction; the user gets an approval workflow they can understand.

The insight is correct: the right unit of control is the transaction, not the session. Single-use cards that expire after one purchase eliminate the risk that a compromised agent credential gets used repeatedly. Each card is scoped to exactly one transaction, so the blast radius of any failure is a single purchase.

But the card approach is fundamentally a compatibility shim, not a solution. It buys time. It does not resolve the underlying mismatch between the card infrastructure and the agent actor model.

Why cards are still wrong

The first problem is economics. Virtual card issuance is not free. Card network fees still apply. The fixed costs per transaction still exist. If the goal is to enable an agent to call a metered API 10,000 times at $0.001 per call, a virtual card per transaction is not just expensive — it is operationally absurd. You would issue more cards than calls, and each card carries overhead that dwarfs the payment it covers.

The second problem is the approval model. Human-in-the-loop approval for each card creation is the right default for high-stakes purchases. It is the wrong default for routine agent operations. An agent booking flights benefits from approval. An agent paying for compute per inference call cannot pause its execution 10,000 times per minute to await a push notification. The granularity of human oversight that makes sense for consequential decisions becomes an impossibility at operational velocity.

The third problem is expressiveness. A card carries payment credentials. It does not carry task context, authorization scope, delegation chain, or intent. A merchant receiving a virtual card transaction knows the card number, the amount, and the merchant category code. They do not know that this payment was authorized as part of task X, delegated by user Y, within a budget of Z, subject to revocation condition W. The entire semantic layer that makes an agent transaction auditable and governable is absent from the payment instrument.

The fourth problem — the most subtle — is that cards encode human trust primitives. The chargeback system, the dispute resolution framework, the cardholder protections: these exist because humans make mistakes, get defrauded, and need recourse. They create real liability for merchants. As agents scale, merchants will need to distinguish between agent-initiated and human-initiated transactions — not just for fraud purposes, but for dispute routing, consent verification, and liability attribution. A card number does not carry that signal.

The native alternatives

The more principled response to the agent payment problem is to build payment infrastructure that treats machines as first-class actors rather than shoehorning them into human payment rails.

The most conceptually clean solution is x402 — a payment protocol built around HTTP's long-dormant 402 "Payment Required" status code. The flow is native to how agents already interact with the web: an agent sends a request; the server responds with HTTP 402, including price, accepted token type, payment address, and expiration; the agent executes the payment and retries the request with a payment proof header. No account creation, no pre-provisioned API keys, no human in the loop for routine operations. Payment is just part of the HTTP conversation.

x402 is stablecoin-native. Most implementations use USDC on Base or Ethereum: settlement is near-instant, fees are fractions of a cent, and the math works at any transaction granularity. A $0.001 API call is as viable as a $100 software subscription. Since the protocol launched on Solana, there have been over 35 million transactions and $10 million in volume — small numbers by financial market standards, but remarkable for a protocol that did not exist two years ago.

Coinbase's Agentic Wallets give each agent its own MPC-secured wallet with programmable session caps, per-transaction limits, gasless settlement on Base, and native x402 support. The wallet is agent-native from the start: it is not a human wallet with an agent credential bolted on. The custody model, the authorization surface, and the spending policy framework were designed for autonomous actors.

Stripe and Tempo's Machine Payments Protocol (MPP), launched in March 2026, introduces a "session" primitive. Think of it as OAuth for payments: an agent authorizes once and pre-funds a session with a spending cap. Every subsequent call triggers real-time automatic settlement against the session balance, without a separate on-chain transaction per call. This is the right abstraction for operational agent workloads — one authorization event covers many individual payments, which is how most agent use cases actually work.

Google's Agent Payments Protocol (AP2), announced in September 2025 with over sixty launch partners including Mastercard, PayPal, and Coinbase, takes a mandate-based approach. The user signs a cryptographic mandate — a verifiable record of what the agent is authorized to purchase, up to what amount, under what conditions. The mandate travels with the payment: merchants can verify not just that the card credentials are valid, but that the underlying authorization was genuinely granted by a user for this specific task. AP2 is deliberately rail-agnostic — it supports cards, real-time bank transfers, and stablecoins through an x402 extension.

Beneath all of this sits ERC-4337, Ethereum's account abstraction standard. Account abstraction solves the gas problem — an agent that holds USDC on Base cannot move it without also holding ETH for gas. Paymaster contracts under ERC-4337 allow a third party to sponsor gas, or allow gas to be paid in the same token as the transaction. This is enabling infrastructure rather than a payment protocol, but it removes the friction that would otherwise force every agent wallet to hold a balance in multiple tokens.

What the native solutions reveal

Looking at these protocols together, a clearer picture of the right abstraction emerges — and it is not a card.

The right primitive for agent payments is a mandate: a cryptographically signed record of what a user authorized an agent to spend, for what purpose, up to what limit, under what conditions, and for how long. The mandate separates the authorization decision (made by the human, once) from the execution decisions (made by the agent, many times). It can travel with the payment. It can be verified by the merchant. It can be audited after the fact. It can be revoked by the user without destroying the agent's capability to complete its current task.

Cards carry credentials. Mandates carry intent. That distinction matters for every layer of the stack: fraud detection, dispute resolution, compliance, audit, liability attribution. A merchant who accepts a mandate knows they are transacting with an agent acting within a defined scope of authority. A card number tells them nothing of the kind.

The open questions

The protocol layer is maturing fast. What is not maturing as fast is the conceptual framework for the harder questions — the ones that do not have obvious answers yet.

Where do budgets live?

A budget is not just a number. It is a policy: how much can this agent spend per task, per day, per month, per category, in aggregate? Who can change it? What happens when the agent approaches the limit? Does it stop and ask, stop silently, or escalate to a different execution path?

Today, budgets are typically enforced at the card or wallet level — a maximum charge on a virtual card, a session cap in an MPP authorization, a per-transaction limit on an Agentic Wallet. These are enforcement mechanisms. But the policy that determines those numbers lives somewhere else: in application configuration, in a system prompt, in a user preference screen, or sometimes nowhere — in the developer's head.

There is no standard for expressing agent spending policy in a way that can be consumed by payment infrastructure, understood by the agent, enforced at the transaction layer, and audited after the fact. The budget exists in fragments across multiple systems that do not talk to each other. A task-scoped budget constraint expressed in a system prompt cannot be verified by the payment network processing the transaction.

Where do approval policies live?

The distinction between "human in the loop" and "human on the loop" is easy to describe in the abstract. A human in the loop approves every transaction before it executes. A human on the loop sets policy, monitors outcomes, and intervenes on exceptions. Most agent payment systems offer one or both as toggles. But the interesting question is not which mode to use — it is where the policy that determines when to switch modes actually lives.

Today, approval thresholds are typically encoded in application code or configured per-card at issuance. They are static. They do not reflect the agent's current state, the current task's risk profile, or the user's current context. An agent booking a flight for a business trip should face different approval requirements than an agent autonomously subscribing to a new SaaS tool. But both might use the same approval threshold configured when the agent was set up.

The deeper problem is that approval policy is currently separated from the agent's task context. The payment system does not know what the agent is trying to accomplish. The agent's task context does not know what the payment system's policy is. The approval decision gets made at a layer that has incomplete information — usually the payment infrastructure layer, which knows the transaction amount and merchant category but has no access to the agent's task state.

What happens in multi-agent chains?

As orchestration patterns mature, the payment problem compounds. An orchestrator agent spawns subagents. Those subagents may spawn further subagents. Each level in the hierarchy might need to make payments. Who authorized the subagent's spending? Does the subagent's spending authority derive from the orchestrator's? Should the orchestrator's total budget constrain the sum of all subagent spending, or does each subagent get its own budget?

The correct analogy is RFC 8693 — the OAuth 2.0 Token Exchange standard — applied to spending authority instead of access tokens. Just as a delegated access token should carry equal or narrower scope than the parent token, a subagent's spending authority should be derived from and bounded by the orchestrator's. The delegation chain should be visible, auditable, and constrained at each hop.

None of the current payment protocols express this. AP2 mandates are user-to-agent. They do not have a multi-hop delegation model. MPP sessions are single-agent. Agentic wallets are single-agent. The multi-agent payment problem is largely unsolved, and it is going to matter as soon as orchestrated agent systems move beyond toy examples into production deployments.

Who is the agent, and does the merchant care?

Merchant compliance requirements — KYC, AML, OFAC screening, beneficial ownership verification — were built around legal entities and natural persons. An AI agent is neither. A wallet controlled by an agent on behalf of a user has a human somewhere in the chain, but that human may be several degrees of delegation removed from the transaction.

Regulatory frameworks have not caught up. The IMF's April 2026 note on agentic payments identified a core tension: probabilistic AI decision-making is fundamentally incompatible with the deterministic requirements of payment compliance infrastructure. AML rules, sanctions screening, and transaction monitoring systems expect well-defined principals executing deliberate transactions. An agent executing a chain of microtransactions to complete a task looks nothing like that.

For routine consumer payments, this may be manageable — the agent's spending traces back to a verified human, and the KYC responsibility stays with the human account. But for agent-to-agent payments — where an agent pays another agent for compute, data, or labor — the question of who is the beneficial owner of the transaction becomes genuinely unclear, and existing compliance frameworks have no answer.

What does dispute resolution look like?

Chargebacks exist because humans make mistakes, get defrauded, and need recourse. The chargeback mechanism assumes: a human cardholder recognizes an unauthorized charge, contacts their bank, asserts they did not authorize the transaction, and the merchant bears the cost if they cannot prove authorization.

For agent payments, "unauthorized" is a spectrum. The agent had valid credentials. The transaction was executed. The agent was following its instructions — but those instructions may have been the result of prompt injection, a hallucination, or a misinterpretation of the user's intent. Was the transaction authorized? The payment network says yes. The user says no. The agent cannot say anything.

A mandate-based system partially addresses this: the mandate defines what was authorized, and a transaction outside the mandate scope is clearly unauthorized. But for transactions within the mandate scope that the user disputes as contrary to their intent, there is no current framework for adjudication. The dispute resolution primitives have not been built.

The prompt injection tax

The payment problem and the security problem are the same problem. An agent that can be manipulated via prompt injection — a malicious instruction embedded in a document, webpage, or tool response — can be made to make unauthorized payments. The payment system cannot distinguish between an agent following the user's intent and an agent following an injected instruction that overrides it.

Card-based solutions partially address this through human approval gates: if the user must approve each card creation, a prompt-injected spend requires the user to approve an unexpected transaction, which they might notice. But approval gates are not scalable — and agents designed to operate at volume need payment authorization models that do not require per-transaction human confirmation.

The deeper requirement is that payment authorization must be grounded in a verifiable statement of user intent — not just a token that proves credentials exist. If a mandate encodes "purchase flight tickets for my trip to New York," a prompt-injected attempt to purchase something else should fail at the mandate verification layer regardless of whether the user approved the mandate initially. The spending authority should be semantically scoped, not just numerically capped.

This is technically hard. Semantically scoped payment authorization requires the payment infrastructure to understand what the agent was trying to accomplish — a capability that the payment layer does not currently have and may not be able to implement deterministically.

The architecture that is emerging

Looking at where the industry is converging — across x402, AP2, MPP, Agentic Wallets, and the design space they collectively define — an architecture is taking shape, even if no single implementation fully realizes it yet.

At the bottom is a settlement layer: stablecoins on programmable blockchains, with near-zero fees, near-instant finality, and transaction granularity that works at micropayment scale. This is not controversial anymore. Ninety percent of onchain agentic commerce in Q1 2026 was settled in USDC. The stablecoin layer is the clear winner for machine-to-machine payments.

Above that is a session and authorization layer: pre-authorized spending sessions with caps, time bounds, and category restrictions. This is what MPP's session primitive and Agentic Wallets' programmable policies do. One authorization covers many transactions. The human decision happens once; the agent executes within the authorized envelope.

Above that is a mandate and intent layer: cryptographically signed records of what the user authorized, for what purpose, with what constraints. This is what AP2 is trying to build. The mandate travels with the payment, allowing merchants and auditors to verify that the transaction was genuinely within the scope of user authorization — not just that valid credentials were presented.

Above that — and this layer barely exists yet — is a policy and governance layer: where budgets are defined, where approval thresholds are set, where multi-agent delegation chains are expressed, and where the compliance obligations are met. This is the layer that will determine whether agentic payments can scale to enterprise deployment.

What has not been built

The settlement layer is good. The session layer is taking shape. The mandate layer is early but directionally right. The policy and governance layer is almost entirely absent.

There is no standard format for expressing agent spending policy — the budget, approval thresholds, merchant restrictions, task scope constraints — in a way that is consumable by payment infrastructure, verifiable by merchants, and auditable after the fact. Policies exist in application code, in system prompts, in card configurations. They are not portable. They are not verifiable at the payment layer.

There is no standard for multi-agent spending authority delegation — how an orchestrator's budget gets divided among subagents, how spending rolls up to the user's aggregate authorization, how revocation at the orchestrator level propagates to subagents. The RFC 8693 analogy is obvious and correct. The implementation does not exist.

There is no standard for semantically scoped payment authorization — a mandate that encodes task intent, not just numeric limits. This is the hardest problem, the one that sits at the intersection of payments and the trust problem for agentic AI. It may require new primitives that do not map cleanly onto anything in the existing payments stack.

And there is no agreed answer to the liability question. When an agent makes a payment that the user did not intend — through hallucination, prompt injection, or misinterpretation — who bears the cost? The user? The platform? The model provider? The developer? The payment network? The merchant who accepted the payment? This question will eventually be answered by regulators, by case law, or by industry consensus. Right now it is answered by nobody, which means it is answered by the person with the least leverage in the chain: usually the user.

Why this matters beyond payments

Agent payments are not a narrow technical problem. They are the place where the agent infrastructure conversation intersects most directly with the real world. An agent that cannot pay is a research prototype. An agent that can pay — reliably, at scale, with appropriate authorization and auditability — is an economic actor.

The design decisions made in the next two years will determine whether that economic actor is legible, auditable, and under meaningful human control — or whether it is an opaque system making financial decisions that nobody fully understands, on behalf of users who trusted it with their money.

The card approach, for all its limitations, forced a useful discipline: it required human approval gates and single-use scoping. The native protocol approaches are more powerful and more scalable. The open question is whether they also remain legible — whether the semantic layer that cards handle poorly (not at all, actually) gets built into the native infrastructure before the native infrastructure scales past the point where retrofitting it is possible.

The right outcome is not agents that cannot pay. And it is not agents that can pay without any meaningful authorization framework. It is agents that can pay — fluently, at machine speed, at micropayment granularity — within a mandate structure that expresses genuine user intent, enforces it at the payment layer, and creates an audit trail that means something after the fact.

That infrastructure exists in fragments. Building it into a coherent whole is the work.

Reading