Agentic Payments Move Spending Authority Into the Runtime

Agentic payments are arriving before payment authority has an owner.

At LangChain Interrupt there was a constant return to a payment question for agentic AI: what to do with AI agents that need to spend money. Privy said the payment question kept coming up. Harrison Chase pointed at centralized least privilege, audit trails, and dynamic policies as the path that probably beats static allowlists.

The wallet signs. The runtime decides.

So let me just repeat that. The payment question that’s come up for agentic commerce, AI agents making payments, is delegated spend. And spending money, even as a new tool call, is not simply another tool call. It creates liabilities, dispute paths, budget pressure, user trust issues, procurement weirdness, and an audit trail the business needs to defend after the fact.

The Spending Bug Has a Perfect UX

In this integrated form, agents can research suppliers, compare offers, reserve resources, pay for APIs or other digital goods and services, issue refunds to customers, or book travel inside systems where humans already work. Thus, as previously noted, the integrated agent is far more powerful than AI-powered chat.

Money exposes the part of the architecture that hand-wavy autonomy hides.

Note that as soon as the agent stops being able to execute commands in the integrated workflow and instead fills out a human controlled checkout page (e.g. for purchases), then the workflow stops being integrated and turns into purely manual work. And as for spending money on behalf of a user with direct wallet access granted to the agent, the worst part is that the UI will make it look like the money was intentionally spent by the user (with a cool progress bar, for example), until it is revealed weeks later by the finance department that a prompt was entered incorrectly and money was spent by the AI agent.

Protocols are moving quickly. x402 frames itself as an open payment standard for internet-native payments. Coinbase describes x402 as direct programmatic payments over HTTP for human developers and AI agents, with no account setup and no manual payment flow. Cloudflare’s Agents documentation shows the machine-to-machine flow: client requests a paid resource, receives a 402 Payment Required response, retries with a signed payment payload, and gets settlement confirmation.

Good. Interfaces for agents need to be agent-operable interfaces, including payment interfaces. That’s why human checkout pages are so bad for autonomous work.

In sum, the hard work in enabling a resource to be paid for over the internet is left to the runtime (i.e. spending policy): what agent requested this spend, what was the purpose of the agent, what is the relevant budget, what merchants/services are in scope, who can retract a delegation of spend, who is the human to approve a spend, where will the settlement receipt of the spend of money be written.

Payment Intent Belongs in the Runtime

The core object is payment intent.

An agent shouldn’t be passing around payment authority, the agent should create a payment intent. The intent would include actor, task, merchant/service, amount, currency, purpose, budget, requested payment method, evidence gathered, and fallbacks for when the main method of payment fails. The runtime policy engine then determines the next steps for the payment intent based on its rules (approve the payment of metered API calls automatically, pay customer refunds to support leads, require approval from procurement for new vendors, reject transactions that were not for the intended task, etc). Those next steps could be yes, no, ask for human approval, or open a ticket.

This sounds boring because money likes boring.

The runtime spending policy needs a few plain fields:

• Amount and currency limits.
• Merchant or service scope.
• Delegated purpose.
• Budget window.
• Approval threshold.
• Wallet or signer scope.
• Revocation owner.
• Receipt destination.

This can be contrasted with the runtime spending policy that is required to be defined by the agent in Privy's x402 writeup here Privy's x402 writeup gets close to this shape for per-domain spend limits, agent-specific permissions, workflow-level approvals, and even for session signers for offline user workflows.

Wallet Ownership Changes the Failure Mode

Wallet architecture still matters. It just answers a much narrower question.

Privy's agentic wallet docs describe two control models: developer-owned wallets controlled by backend authorization keys, and user-owned wallets that grant an agent signer scoped policies while the user keeps ultimate control and revocation.

A developer-owned wallet for a backend agent paying for infrastructure, such as data enrichment, paid APIs, crawl credits, model calls, or transaction fees. The company owns the budget, the runtime owns the policy, and operational control of the revocation is sufficient (i.e. someone on the team can log into the management interface and cancel an agent).

User-owned wallets with agent signers also fit into the delegated action model. In these cases, users are delegating others to perform action(s) on their behalf. In these cases, users fund their own workflows, and the agent or signer is granted bounded authority to complete tasks on their behalf. (In these cases, the user should always have the ability to revoke the agent or signer).

Both models need runtime policy. A developer-owned wallet with no spend controls turns into a company credit card taped to an agent’s back. A user-owned wallet with no scoped delegation turns into a consent problem just waiting to turn into a customer dispute.

Approval UI Is Runtime Infrastructure

Approval is a runtime state transition. The modal is just where a human sees it.

That is why agent UI belongs in runtime infrastructure. So when a user approves a spending action, they are approving a proposed transaction with a matched policy. The evidence the agent used, the budget impact, and the scope of authority being granted should all be visible to the user approving the spending. The user should be approving a bounded payment intent, not a vague agent plan.

That is the part that everyone tries to treat like an SDK integration and therefore payments “work”.

Receipts Beat Trust

A payment-capable agent needs a way to have those payments recorded as receipts as first-class data within the agent’s runtime.

When making payments, the payment response should be written back as evidence to the same stream as the rest of the work done by the agent. Cloudflare’s x402 flow ends with a PAYMENT-RESPONSE header that contains settlement confirmation.

That was also true for tool calls: agent traces need to cross the boundary of work, the side effect of which is that the trace becomes much more valuable. In the case of payments, the side effect is value transfer (i.e. money moving out of or into an account). Therefore, for all but the cheapest of actions, traces of agent work must include payment receipts.

The ledger doesn’t have to be pretty or shiny. It has to answer the boring set of questions of work done quickly.

• What did the agent intend to buy?
• Which policy allowed it?
• Which signer executed it?
• Which rail settled it?
• Which human approved it, if approval was required.
• Which task, ticket, customer, or account owns the receipt?

The Card Networks See the Same Boundary

We should pay attention to how existing payment networks already frame the problem. For example, while Visa Intelligent Commerce, enabled by crypto, frames agentic checkout around approved AI “agents” for consumers to manage their card(s) online, for merchants, it frames around similar but additional factors such as fraud/dispute protections, merchant acceptance, and especially “trust in transaction” for each payment context (visa online, in app, etc.), all already handled for them by existing payments networks. PayPal also recently announced integration of Mastercard’s Agent Pay into PayPal wallets Mastercard Agent Pay will integrate with PayPal's wallet to enable merchants to accept payments from AI agents acting on behalf of users that have added their payment methods to the wallet.

The runtime layer has to own the authority model before this becomes the normal pattern.

Build the Spending Policy First

Define the payment intent schema. Include purpose, merchant scope, amount, budget, evidence required, approval required, signer scope and receipt destination. Treat as an object from day one. Use for backend logic as well as for generating form fields for human fill-in-the-blanks approval actions.

A path for runtime control of payments above and beyond enterprise wallet offerings is to first implement a policy engine, write policies as simple rules which Finance and Security can understand, and test against various scenarios. Service allowlists are only a first input, but purpose, budget window, task owner, customer account, and approval state all impact payments.

Make approval a runtime event: The approval should pause the payment intent, show the policy match, capture a bounded decision, and then resume or reject the workflow. In other words, do not make “approve agent action” a button.

Test out denial paths. If all a payment system can test for is successful settlement, the team is asking for a weird Friday afternoon. Denied payment, expired approval, revoked signer, duplicate retry, failed settlement, disputed transaction, and exhausted budget all need first-class paths.

Agentic payments are going to make agents feel useful since they are able to buy data, pay for API calls, issue credits, book services… for companies within specified policy. That is real work.

The agent runtime becomes a spending control plane.

Companies will get agentic payments right by starting from a different vantage point than existing payment ‘solutions’ and beginning with a plain set of questions for every transaction: who is delegating the spend; what policy will be enforced on that spend; where is the approval for the spend delegated; and what receipt will prove that the transaction was for the business.

Then the wallet can sign.