What Is an Agent Payment Mandate?
A reader asking what is an agent payment mandate is asking about scoped payment authority: a signed record that tells a verifier which agent may pay, for which checkout, using which instrument, amount, payee, time window, and receipt path. The mandate turns agent payment approval into inspectable evidence instead of a chat transcript or an inferred browser session.
In AP2, the payment mandate follows the checkout mandate. The checkout mandate proves the approved purchase context; the payment mandate proves authority to fund that approved checkout. A shared checkout hash or transaction reference keeps authorization, payment, and receipts aligned.
Agent Payment Mandate at a Glance
| Question | Plain answer | Verifier use |
|---|---|---|
| Definition | Signed, scoped authority for an agent payment. | Confirms that the payment was authorized for the referenced checkout. |
| Presented by | The shopping agent, wallet, credential holder, or agent runtime. | Separates agent action from vague user intent. |
| Verified by | Credential provider, network, processor, merchant, or dispute reviewer. | Checks key binding, checkout reference, payee, amount, limits, and expiry. |
| Why attach identity? | The mandate says what may happen; identity says which agent and operator stand behind the action. | Connects payment evidence to a public profile, keys, endpoints, policies, and support path. |
How a Mandate Differs From Nearby Artifacts
A mandate is not the product catalog, the payment rail, or the identity profile. The mandate is the permission object that lets a verifier decide whether a payment action is inside scope. Rails such as x402 and MPP can move payment instructions through HTTP flows; the mandate explains why this agent is allowed to use the payment path for this checkout.
| Artifact | Primary job | Common mistake |
|---|---|---|
| Checkout mandate | Proves that an agent may complete a specific cart or checkout. | Treating cart approval as payment authority. |
| Payment mandate | Proves that an agent may pay for the approved checkout with stated limits. | Treating a payment credential as proof of agent authority. |
| Payment rail | Carries payment instructions, verification, settlement, or receipt flow. | Assuming the rail alone identifies the authorized agent. |
| Public identity record | Publishes the agent name, operator, keys, endpoints, policy, and receipt route. | Leaving verifiers to trust an unanchored agent string. |
What Verifiers Check
The AP2 payment mandate structure shows why verifiers inspect more than a yes-or-no permission flag. A useful mandate package should expose the mandate type, issuer, key binding, checkout reference, payee, amount, currency, instrument scope, expiry, constraints, disclosures, and receipt references.
- Confirm that the mandate type and version match the protocol path the verifier accepts.
- Compare the checkout hash or transaction reference to the checkout being paid.
- Verify the signature, key identifier, and agent key binding against the trusted issuer or public agent record.
- Check payee, amount, currency, instrument, recurrence, spend limits, and expiration.
- Return a receipt that refers back to the mandate so finance, support, and dispute review can inspect the same chain of evidence.
Example Mandate Shape
The compact example below is illustrative, not a complete AP2 token. The point is the relationship: one public agent identity, one checkout reference, one payment scope, and one receipt route.
{"agent":"procurement.agent","agent_json":"https://procurement.agent/.well-known/agent.json","payment_mandate":{"vct":"mandate.payment.1","transaction_id":"checkout_hash_8f31","payee":{"name":"Northstar Office Supply","website":"https://merchant.example"},"payment_amount":{"amount":27999,"currency":"USD"},"payment_instrument":{"type":"card_token","description":"network token ending 4242"},"exp":1779314400},"receipt_endpoint":"https://procurement.agent/receipts"}Where HeadlessDomains.com Fits
HeadlessDomains.com gives agent payment mandates a persistent identity anchor for the agentic web. A .agent name or another Headless Domains identity can point to the official agent profile, agent.json, SKILL.md, public keys, payment metadata, endpoint list, mandate policy, support contact, and receipt route.
That identity layer does not replace AP2, x402, MPP, processor controls, or merchant risk checks. The identity layer gives those systems a public actor record. Before value moves, a verifier can compare the mandate key and endpoint to the published identity record instead of trusting a display name, marketplace label, or copied checkout link.
Where to Go Next
For the broader commerce setup, read Make Your Store Discoverable to AI Shopping Agents. For adjacent payment context, continue with Agent Payments Require Identity, Authorization, and Receipts, x402 vs AP2 vs MPP, and Before Your Agent Pays an API.
Before accepting autonomous payment flows, publish the identity record first, bind mandate keys and receipt paths to that same profile, then test the verifier path from mandate to checkout to receipt.
FAQ
What is an agent payment mandate in one sentence?
An agent payment mandate is signed payment authority that tells a verifier which agent may pay, for which checkout, with which instrument, amount, payee, and validity window.
Is a payment mandate the same as a checkout mandate?
No. A checkout mandate proves approval for the cart or checkout. A payment mandate proves authority to fund that approved checkout.
Who verifies an agent payment mandate?
A credential provider, network, merchant payment processor, merchant, wallet, or dispute reviewer can verify the mandate, depending on the payment flow and protocol.
Does a mandate replace x402, MPP, or processor controls?
No. Rails and processors still handle payment transport, verification, settlement, fraud controls, and receipts. The mandate supplies scoped authorization evidence for the agent action.
Why bind the mandate to a public Headless Domains identity?
A public Headless Domains identity lets verifiers inspect the agent name, operator, keys, endpoints, policy, and support route before accepting a payment action.
Can an agent use a payment mandate without a browser?
Yes. Headless Domains are headless names for agents and workflows, so agents can use command-line and API workflows rather than relying on browser-native DNS resolution.