Quick answer: An agent payment mandate is the scoped consent a principal gives an AI agent to spend on their behalf — which agent, for which principal, up to how much per transaction, how much in total, at which merchants, in which categories, until when, provable and revocable. Two ways to get that into production: bolt the consent logic on in code you own and operate, or use a platform where the mandate is a first-class object. On Devotel Orbit the agent payment mandate console (Messages → Commerce checkout → Agent payment mandates) issues, authorizes, charges, verifies, and revokes scoped, spend-capped mandates over an AP2-style authorization layer — so the question for a buyer is not whether mandates are needed, but whether maintenance of consent is a feature you ship or invariants you maintain.
The trust problem the mandate answers
Let an AI agent transact and a skeptic appears immediately: regulators, card networks, and your own risk team all ask the same question — under what authority did that agent just spend the customer's money? "The agent decided" is not an answer an auditor accepts, and it becomes a worse one as soon as the first dispute lands.
The four properties that make an authorization defensible:
- Scope — the consent names the agent, the principal it acts for, and hard caps: a per-transaction ceiling, a cumulative total, optional merchant and category allowlists, and an expiry. Consent without numerals is a paper trail, not a control.
- Provability — every mandate carries a consent digest, and you can verify that digest when the charge is questioned. "The agent was allowed" has to be demonstrable after the fact, or it is a claim, not evidence.
- Revocability — principals withdraw consent, and they expect the withdrawal to take effect at the next spend decision, not at the next cache flush. A consent object with no live revoke is a liability with an audit trail.
- A checked spend path — every charge the agent attempts is dry-run authorized against the mandate before it commits: caps, allowlists, expiry, and consent status, re-derived on each call.
The buying decision hides one level down: either you bolt this consent layer onto a payments stack that was never shaped for it — consent lives in your database, your middleware enforces it, your team carries the invariants — or you start where the mandate is a first-class, addressable object with its own lifecycle. Both get to production. What differs is what you own afterwards.
What a native mandate looks like in Orbit
The agent payment mandate console (Messages → Commerce checkout → Agent payment mandates) is the operator surface for the AP2-style authorization layer, and it maps one-to-one onto the properties above:
- Issue. An operator creates the mandate: which agent, for which principal, the per-transaction cap, the cumulative cap, the currency, optional merchant and category allowlists, and an optional expiry. The issued mandate is a first-class object — it has an identity, a status, and a consent digest.
- Authorize. Before any commit, the agent's intended charge is dry-run decided against the mandate: amount against the per-transaction cap and remaining total, merchant and category against the allowlists, the mandate still active and unexpired with its digest intact. The decision is re-derived server-side on every call, not cached from the issue step.
- Charge. A charge that passed authorization commits and advances spend against the cap, and the mandate's spend counters move with it — a mandate that hits its total reads as exhausted, not as an error.
- Verify. The tamper-evidence digest can be re-checked at any time, so "consent was intact when the charge committed" is provable after the fact.
- Revoke. One action on the console (or the revoking API call) withdraws the consent, and every spend decision re-checks the mandate state on the next call — revocation is not a background sweep.
- Hand to the network. Where the payment networks ask for an agent token — Mastercard Agent Pay or Visa Trusted Agent Protocol — the console mints the network token against the mandate, so the scoped consent underwrites the token the network sees. The mandate layer and the network token answer different parts of the same question; the former underwrites the latter.
One boundary the console holds deliberately: nothing here moves money. An authorized charge is the green light to mint a pay-by-link or hand off to the payment network — mandate authorization decides whether a spend is in scope, and the existing payment rails settle it.
Scoped vs bolt-on: the comparison contour
Payment platforms are good at moving money, and some now ship agent-facing tokens or agentic-checkout pilots. What the category at large still does not surface is the mandate itself: consent scope as a first-class, addressable object you can issue, dry-run decide against, verify, and revoke. That capability is the comparison contour — scoped, native mandates on one side, bolted-on consent enforcement on the other:
- First-class object vs scattered state. With a native mandate model, the consent has an identity and a status — active, exhausted, revoked, expired — that every spend decision consults. The bolt-on equivalent is consent spread across application tables and middleware checks, where "what is the current consent state?" is a query you build and keep building.
- Re-derived decisions vs drift. A mandate model re-derives every authorization server-side against current mandate state, including the consent digest. With bolt-on consent, the enforcement predicates live in your middleware; code drift between the writer of the consent record and the readers of it is the failure mode your team owns.
- Provable and revocable vs best-effort. Digest-backed verification and immediate revocation are product behaviors of the mandate layer. Bolted on, provability is the audit table you designed and revocability is as immediate as your invalidation path — each an invariant you maintain.
- The empty-middle risk. The split responsibility is where agent-payment pilots die: the payments side assumes consent arrived from somewhere, the application side assumes the platform checks it. A native mandate layer closes that middle by making the mandate the shared object both sides consult.
None of this means a bolt-on build is wrong — a team that already operates a payments stack can deliver the same properties. The contour is about what you own afterwards: mandate issuance, dry-run authorization, digest verification, and revocation as shipped behavior, or as an internal subsystem with a permanent maintenance budget. On Orbit the mandate console sits inside the same commerce surface as pay-by-link, subscriptions, and direct carrier billing — and same account, same bill — so the consent layer is where the spending already is, not another subsystem to integrate.
Where this sits in the agentic storefront cluster
Mandates are the consent half of agentic commerce; the storefront post in this cluster covers the discovery half — publishing the agent-facing catalog a third-party shopping agent can find and drive. The pay-by-link explainer covers the settlement rail an authorized charge hands off to. Read together the three map one flow: an agent discovers the store, transacts under a mandate, and the spend settles over the payment rail. Start with the cluster post (Pay-by-link over every conversation channel), then come back here when the question turns to who authorized the agent to spend.
Frequently asked questions
What is an agent payment mandate?
A scoped, spend-capped consent under which an AI agent transacts on a principal's behalf: which agent, for which principal, per-transaction and cumulative caps, optional merchant and category allowlists, an expiry, and a consent digest. In Orbit it is a first-class object you issue, authorize against, charge against, verify, and revoke — not a flag in application code.
Does a mandate authorize the payment itself?
No. The mandate layer decides whether a spend is in scope — dry-run authorization re-checks caps, allowlists, expiry, and the consent digest before a charge commits. Settlement still goes over the payment rails: an authorized charge is the green light to mint a pay-by-link or hand off to the payment network, not the money movement itself.
How does the mandate model relate to Mastercard Agent Pay and Visa Trusted Agent Protocol?
Those are the card networks' agent-token programs: the token the network wants to see when an agent initiates a payment. A mandate answers the prior question — under what scoped consent the agent was spending at all. In the Orbit console you mint the network token against the mandate, so the scoped consent underwrites the token; the two layers complement rather than substitute for each other.
Why not just implement consent checks in my own code?
You can, and teams running an existing payments stack do — that is the bolt-on side of this comparison. What you then own is the invariant set: one canonical consent store, enforcement re-derived on every spend, provable consent after disputes, and revocation that takes effect on the next decision. Those properties are exactly what a native mandate layer ships as product behavior, which is the trade this comparison prices.
Where is the mandate console in the dashboard?
Messages → Commerce checkout → Agent payment mandates. The same commerce section also carries pay-by-link, direct carrier billing, and subscriptions, and the agent-facing storefront for third-party shopping agents — the consent, settlement, and discovery surfaces of agentic commerce in one place.
Resources
- Open the console: Messages → Commerce checkout → Agent payment mandates in the Orbit dashboard.
- The settlement rail an authorized charge hands off to: Pay-by-link over every conversation channel.
- The conversational commerce pillar these rails live under: Conversational commerce on Orbit.