# The payment authorization pattern: giving an agent a wallet without giving it your bank account > Source: > Published: 2026-10-09 07:15:02+00:00 Agent-initiated payments stopped being hypothetical this year. Protocols for autonomous agent transactions are shipping with real adoption, and industry alliances are forming specifically around agent-driven commerce. If your agent roadmap touches purchasing, subscriptions, refunds, or vendor payments, even narrowly, you need an authorization architecture before you need a use case, because retrofitting one after the first bad transaction is much more expensive. For a worked example, read about [an agent that approved its own refund](https://orbiresearch.com/lab/agent-approved-own-refund). ── The naive version ── The naive approach gives the agent direct API access to a payment method, a stored card, a linked bank account, scoped to "this vendor" or "this category." It fails for the same reason unscoped file access fails: the agent's job is to interpret ambiguous instructions and act, and payment amounts are exactly the kind of number a misread instruction gets wrong. A scope restricts where money can go. It does nothing to restrict how much, how often, or whether a human should have seen this first. ── The pattern ── Separate "the agent can request a payment" from "the payment executes" with three independent limits, none of which the agent controls. 1. A hard ceiling per transaction. Set below the largest legitimate transaction you expect, not above it. The agent should never be able to construct a request that clears this ceiling, the limit lives in the payment layer, not in the agent's instructions. 2. A velocity limit, not just a size limit. One large payment and fifty small ones can both drain an account. Cap total spend per run, per day, and per vendor independently, the same way you'd rate-limit an API. 3. A human gate above a threshold, by default. Anything over your comfort ceiling routes to an approval queue instead of failing or executing. This is the same approval-queue pattern we've written about for other high-stakes actions, payments are simply the category where skipping it is most expensive. ── The wallet ── Don't connect the agent to your actual payment account. Fund a dedicated, capped wallet or virtual card that the agent transacts against, agent payment protocols and virtual-card issuers both support this now. The wallet's maximum balance becomes your real worst-case exposure, independent of any logic bug in the agent itself. If the wallet holds $500, a broken agent can lose you $500, not your operating account. ── Reconciliation ── Every agent-initiated payment needs a machine-readable record of why, which run, which instruction, which approval (if any) authorized it, logged before the payment clears, not reconstructed afterward from a payment processor's dashboard. When a payment looks wrong three weeks later, you need to answer "what did the agent think it was doing" without guessing. ── Checklist ── [ ] Does a hard per-transaction ceiling live in the payment layer, outside the agent's control? [ ] Is there a velocity limit, spend per run, per day, per vendor, not just a size limit? [ ] Does anything above your comfort threshold route to a human by default? [ ] Is the agent funded through a capped wallet or virtual card, never your main payment account? [ ] Is the "why" behind every payment logged at authorization time, not reconstructed later? ── End of pattern ── ◆ An agent that can pay for something is an agent that can be wrong about money. Build the ceiling before you build the use case. ORBIRESEARCH *Originally published on the [OrbiResearch Lab](https://orbiresearch.com/lab/agent-payment-authorization-pattern). We build production AI agents at [orbiresearch.com](https://orbiresearch.com).*