What is a payment mandate.
A payment mandate is a pre-authorized instruction that lets an agent execute a specific class of payment without further approval. The mandate is parameterized: it can name a maximum amount, a recipient or set of allowed recipients, a frequency window, and an expiration date. The primitive Google's AP2 protocol and several similar mandate-based payment systems are built on.
The "approve every payment" model does not scale to agents.
Human payment patterns assume one approval per transaction: you see the total at checkout, you tap to confirm. Agents that need to pay 200 APIs in an hour cannot work this way. The user cannot click 200 confirmations, and even if they could, the latency would kill the agent's usefulness. Some pre-authorization model is required.
Payment mandates formalize the pre-authorization. Instead of "approve every payment" or "approve nothing" (a static spend limit), a mandate says: "approve any payment that matches these parameters, up to this cap, until I revoke it." The user grants the mandate once; the agent executes against it many times. This is the structural primitive that turns the agent into an autonomous economic actor while still keeping the human in control of the boundaries.
Grant, present, settle, revoke.
- Grant. The user (or the user's delegate) creates a mandate via the protocol's UI, specifying the parameters: max amount per payment, max total over a window, recipient allowlist, expiration. The mandate is signed and stored by the protocol.
- Present. When the agent needs to make a payment, it presents the mandate to the recipient's payment processor as proof of authorization. The processor validates the mandate, checks the payment parameters are within the mandate's limits, and accepts the payment.
- Settle. The actual settlement happens on whatever rail the mandate specifies (stablecoin, card, ACH). Mandate validation is separate from settlement; one mandate can authorize payments across multiple settlement methods if the protocol permits.
- Revoke. At any time, the user can revoke the mandate. Subsequent presentations fail validation. In-flight payments may or may not complete depending on the protocol's atomicity guarantees.
The protocol layer holds the mandate; the agent never holds the user's payment credentials directly. This is the safety property that makes mandate-based systems different from "give the agent your credit card." Compromise the agent and the worst case is the mandate's parameter envelope, not the user's full payment power.
Three mandate shapes.
Per-call API access mandate
An agent is granted a mandate to spend up to $0.10 per call on any API in a defined allowlist, for up to $50 total per day. The agent calls APIs throughout the day; each call within the mandate's parameters settles without further approval. Spend over $50 in 24 hours blocks at the platform layer.
Vendor-specific subscription mandate
A research agent is granted a mandate to pay one specific data vendor up to $200/month, billed in stablecoin. The vendor's invoice triggers the mandate's pre-authorized payment automatically. The agent never has to surface the bill to a human.
One-shot capped mandate
A user grants an agent a single-use mandate to spend up to $500 on hotel booking from one trusted booking platform. The agent searches, picks an option within the cap, and books. Once the mandate is consumed, it cannot be reused.