Agent wallet and payment infrastructure map
Between an agent deciding it wants to pay for something and the money arriving, six things have to be true. Almost every product in this market occupies one or two of these layers and is described in language that implies it covers all six.
The Agentic Authority Stack
Defined in full on the hub. Read it from the base up: each layer assumes the one beneath it has been answered. Authority sits at the bottom because identity, credentials, rails and commerce all presuppose that somebody decided this action was permitted. Most real incidents are a layer being assumed rather than implemented.
Commerce protocols
Two open specifications now cover discovery through checkout, sponsored by the two largest agent distribution surfaces. Both are Apache 2.0, both are actively revised, and neither subsumes the other.
For anyone building authority infrastructure the important property of this layer is what it declines to do: both protocols defer the question of whether the buyer authorised the purchase to something else.
OpenAI and Stripe's checkout and delegated payment specifications, date-versioned, reached through ChatGPT.
Google and Shopify's discovery-to-post-purchase protocol, composing with A2A, AP2 and MCP.
The tool-access and agent-to-agent substrates both commerce protocols are designed to sit on.
Rails and settlement
Mostly the rails that already existed, plus one that did not. Cards carry the overwhelming majority of agent-initiated consumer spend and bring their governance with them. Bank transfers carry business-to-business value. Stablecoin settlement over x402 carries the payments that are too small and too frequent for either.
The distinguishing question for an authority layer is whether the rail has a natural enforcement point. Cards do — an issuer sits in the path. Stablecoin transfers do not: once the key signs, the payment is final and nobody was consulted.
Visa Intelligent Commerce and Mastercard Agent Pay: tokenised credentials, network-enforced constraints, existing dispute rights.
HTTP-native pay-per-request settlement in stablecoin, foundation-governed, live across several chains.
Account-to-account transfer, and standing authorisations that permit variable future collections.
Wallets, and what the word is hiding
“Agent wallet” is used for at least four different things, and the differences are the whole design.
- A credential vault. Holds the user's payment methods and releases scoped tokens to an agent on request. The authority question is pushed onto whatever decides to release the token.
- A funded balance. A prepaid float or an on-chain account the agent can spend from directly. Simple, and the exposure is the balance — which is why the responsible version keeps the balance small and the top-up controlled.
- A signing key. The agent holds a key that authorises transfers. Whoever holds the key holds the authority, so custody design is the authority design.
- A policy-bound spender. The agent holds nothing. It proposes; something else evaluates, approves, and issues a one-time artifact that an executor redeems. The agent cannot spend, only ask.
The first three bound the loss. Only the last bounds the decision, and it is the only one that yields an answer to “why did this payment happen?” that does not depend on reconstructing an agent's reasoning after the fact.
What you actually integrate
Four common shapes, and what each one obliges you to have.
The agent buys from consumer merchants
- Reach: a commerce protocol (ACP for ChatGPT surfaces, UCP for Google's), usually via your commerce platform rather than directly.
- Credential: a scoped token from the buyer's payment provider, or a network agentic token, rather than a card on file.
- Admission: expect merchants to want a verifiable agent identity — Visa TAP signals or Web Bot Auth signatures.
- Authority: a policy evaluated before checkout, because the credential will not carry purpose or cumulative budget.
The agent pays suppliers or renews business subscriptions
- Rail: corporate card or bank transfer. Card rails give you enforcement at authorisation; transfers give you reach and no enforcement point.
- Credential: per-vendor virtual cards remain the pragmatic default, with an approval flow for anything off the approved list.
- Authority: this is where policy earns its keep — approved counterparties, purposes tied to budget lines, daily and monthly limits, operating hours.
- Evidence: assume you will have to show which policy version authorised each payment, and that a log you can edit will not be enough.
The agent pays per API call or per unit of content
- Rail: x402 over stablecoin is the only thing designed for payments this small and this frequent.
- Containment: fund the wallet thinly and top it up under control. The failure mode is a loop, not a fraudster.
- Authority: velocity and cumulative budget matter far more than per-transaction limits here.
- Reality check: settlement is final and there is no dispute mechanism. Whatever you would want to unwind, prevent instead.
The agent moves money inside your own systems
- No external protocol applies. This is an internal authorisation problem wearing a payments costume.
- The controls that matter are the ordinary ones: least privilege, idempotency, an approval step above a threshold, and an audit trail that binds approval to execution.
- The execution boundary is the design decision: keep whatever decides separate from whatever can move money, under different credentials.
The comparison tables put numbers and columns on the trade-offs above; the authority landscape covers who is building the top layer, and the tracker records how each layer got to where it is.
Last reviewed 8 September 2026. Corrections: hello@mnd8t.com.