> ../patterns/payment_authorization.md
§ 01 · Why this matters now
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.
── The naive version ──
§ 02 · The naive version, and why it fails
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 ──
§ 03 · 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 ──
§ 04 · What the wallet actually holds
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 ──
§ 05 · Reconciliation is not optional
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 ──
§ 06 · 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