What Is a Payment Mandate for AI Agents?
An AI agent payment mandate is a signed authorization record that lets a merchant, credential provider, network, or processor verify that a named agent can pay for a specific checkout under stated limits. In AP2, checkout mandates prove what the agent may buy; payment mandates prove how that checkout may be paid; a public identity record lets every verifier inspect the actor behind the signature.
The useful mental model is simple: the mandate is the portable authorization evidence, and the .agent identity is the public inspection anchor. The mandate carries hashes, amounts, payee data, constraints, expiry, and receipt references. The identity record tells verifiers which agent key, endpoint, operator, policy, and support path belong to that payment flow.
Mandate Types at a Glance
| Artifact | Who verifies it | Primary question | Identity fields to bind |
|---|---|---|---|
| Checkout mandate | Merchant or commerce verifier | Is this agent authorized to complete this checkout with these items, price, merchant, shipping terms, and expiry? | Agent name, merchant-signed checkout hash, public key, trusted surface, support route. |
| Payment mandate | Credential provider, network, payment processor, or payee verifier | Is this agent authorized to pay for the referenced checkout with this payment instrument and amount? | Agent identity, payee, payment instrument token, amount, execution window, receipt endpoint. |
| Receipt | Agent, user, merchant, finance, dispute reviewer | Was the mandate accepted or rejected, and which signed object does the result reference? | Issuer, reference hash, result, timestamp, order ID, error code, public incident contact. |
| Public identity record | Every party before accepting the flow | Which agent, operator, endpoint, key, policy, and support path should be treated as authoritative? | .agent name, agent.json URL, key IDs, proof links, lifecycle status, mandate policy. |
How Mandates Work as Verifiable Credentials
AP2 describes mandates as verifiable digital credentials, with SD-JWT VC as the specified format for the current payment use case. That gives the mandate three properties payment systems can inspect without asking an LLM to explain itself: tamper-evident claims, selective disclosure, and key binding.
The vct claim identifies the mandate type, such as mandate.checkout.1 or mandate.payment.1. The cnf claim can bind an open mandate to an agent key for autonomous use. Constraints define allowed payees, allowed payment instruments, amount ranges, budgets, recurrence, references, and execution dates. Receipts bind the verifier result back to the mandate hash.
Checkout Mandate vs Payment Mandate
A checkout mandate answers the commerce question: did the user authorize this agent to complete this particular checkout? The checkout object should already have merchant-signed purchase details, and the mandate should bind to that object through a cryptographic hash. The merchant verifies the mandate before completing the checkout.
A payment mandate answers the finance question: did the user authorize this agent to pay for that checkout with this instrument and amount? The credential provider, network, or processor verifies the payment mandate before returning or accepting a scoped payment credential. The payment mandate references the same checkout hash, so payment authorization cannot drift away from the approved cart.
What Verifiers Should Inspect
| Verifier | Minimum inspection | Reject when |
|---|---|---|
| Merchant | Checkout hash, line items, price, currency, shipping, merchant identity, expiry, and agent key binding. | The checkout hash differs, constraints do not allow the cart, the mandate expired, or the agent identity cannot be inspected. |
| Credential provider | Payment amount, payee, instrument, user consent path, risk signals, and whether the agent can use the credential. | The payment instrument is outside scope, the payee is not allowed, or the agent key is not bound to the authorization chain. |
| Payment processor | Payment credential scope, transaction ID, receipt reference, payment instrument, and processor policy. | The credential is not scoped to the checkout, the receipt cannot bind back to the mandate, or the flow lacks deterministic verification. |
| Agent owner or auditor | Public .agent record, mandate policy, logs, receipt route, support contact, and revocation path. | The public record is stale, the endpoint is unlisted, or the logs cannot connect the action to the mandate. |
Implementation Checklist
- Publish the agent identity before accepting autonomous checkout or payment flows.
- Bind the mandate to a stable agent key, public key ID, endpoint list, and policy URL.
- Include expiry, amount, currency, payee, instrument, execution window, and receipt route in the payment record.
- Keep checkout authorization and payment authorization separate, then link them with the same checkout hash or transaction ID.
- Use selective disclosure so verifiers receive only the fields required for their role.
- Return signed receipts for acceptance and rejection, with references to the mandate hash.
- Log mandate ID, verifier, result, timestamp, agent key ID, identity record version, and revocation status.
- Reject unknown constraint types unless a deterministic fallback flow is explicitly allowed.
Example Mandate Package
The compact example below shows the fields a verifier would expect to correlate. The full illustrative JSON file is included in this article folder as example-mandate.json.
{"agent":"procurement.agent","agent_json":"https://procurement.example/.well-known/agent.json","checkout_mandate":{"vct":"mandate.checkout.1","checkout_hash":"s6U4nT8VvCzZpJ9fZ0n_ExampleCheckoutHash","exp":1779314400},"payment_mandate":{"vct":"mandate.payment.1","transaction_id":"s6U4nT8VvCzZpJ9fZ0n_ExampleCheckoutHash","payee":"Northstar Office Supply","payment_amount":{"currency":"USD","amount":27999},"payment_instrument":"network token ending 4242"},"receipts":["checkout","payment"]}Where HeadlessDomains.com Fits
HeadlessDomains.com gives the mandate a persistent identity anchor. Bind mandates to a persistent .agent identity so verifiers can inspect the official agent profile, agent.json, public keys, endpoint list, payment metadata, mandate policy, receipt path, and support route before value moves.
This identity layer does not replace AP2, SD-JWT VC, x402, MPP, card network rules, or processor controls. It gives those systems a public actor record. A merchant can compare the mandate key to the .agent record. A payment provider can compare the payee and policy to the manifest. An auditor can connect receipts back to the same public identity after the transaction.
Related Reading
- Make Your Store Discoverable to AI Shopping Agents
- x402 vs AP2 vs MPP: Where Agent Identity Fits
- Agent Payments: Identity, Authorization, and Receipts
- Before Your Agent Pays an API
- Agent-to-Agent Commerce Trust Layer
- Canonical Identity for AI Agents
- The Agent Identity Stack
FAQ
What is an AI agent payment mandate?
An AI agent payment mandate is a signed authorization record that lets a verifier confirm which agent is allowed to pay, for which checkout, under which limits, and during which validity window.
How is a checkout mandate different from a payment mandate?
A checkout mandate proves that the agent is authorized to complete a specific checkout. A payment mandate proves that the agent is authorized to pay for that checkout with a scoped payment instrument.
Is a mandate the same as a payment rail?
No. A mandate carries authorization evidence. A payment rail or processor still handles credential issuance, payment verification, settlement, and receipts.
Why bind a mandate to a .agent identity?
A .agent identity gives verifiers a public record for the agent name, operator, keys, endpoint list, mandate policy, receipt route, and support path before value moves.
Can an agent reuse a payment mandate?
Only when the mandate permits reuse through explicit constraints such as recurrence, budget, payee, payment instrument, amount range, and expiration.