Docs · preview
Mandate
A mandate is the proof that a specific payment was authorized: by which policy, by which person if one was needed, for which exact request.
Properties
- Verified at issuance. All checks run when the mandate is created. The payment path only looks up and counts, so it adds single-digit milliseconds inside a rail’s authorization window.
- Single use. A
consumedstate moves fromissuedtoconsumedorexpiredexactly once. One consent cannot pay twice. - Bound to the request. The mandate carries the hash of the canonical request: payee, amount, currency, purpose, checkout reference. A different request needs a different mandate.
- Short lived. Default expiry 15 minutes; configurable per policy down to seconds.
- Idempotent. Every request carries an idempotency key. A retried tool call returns the same decision and the same mandate; it never mints a second one.
Human approval
When a policy requires a person, the mandate is not issued until that person signs. The signature is a passkey assertion or an authenticated link, and it binds the request hash. A chat reaction or an e-mail reply is not an approval; the record would say so.
Compiled into the rail
| Rail | The mandate becomes |
|---|---|
| Stripe Issuing (your account) | A single-use virtual card: amount = mandate amount, merchant lock, expiry = mandate expiry. The real-time authorization request is answered against the mandate. |
| Ramp | A spend limit for the exact amount and purpose; the virtual card is issued against it. |
| Mercury | A virtual card with a spend limit equal to the mandate. |
| Bill.com | An approval scoped to one bill, from an approver identity your administrator assigned. |
| UCP / AP2 checkout | The ap2.checkout_mandate proof the merchant requires to complete the checkout. |
Lifecycle
requested ─▶ decided ─▶ issued ─▶ consumed
│ └─▶ expired
└─▶ step_up ─▶ approved ─▶ issued …
└─▶ denied