Three proofs, not one login
A merchant or payment system needs to separate three questions: Is the principal authenticated? Is this a recognized agent? Is this exact transaction authorized? A valid answer to one does not answer the others.
Digital identity establishes a principal. Agent recognition establishes the calling software or provider. A transaction mandate binds the principal’s instructions to seller, amount, currency, purpose, and time. Production policy requires all relevant proofs to agree.
The shape of a useful mandate
A mandate should be understandable to a person and enforceable by a machine. It includes the principal and agent scope, the allowed action, monetary and temporal bounds, merchant or category restrictions, recurrence, approval triggers, and revocation state.
| Field | Example | Why it matters |
|---|---|---|
| Purpose | Renew production database capacity | Prevents unrelated use of the same budget |
| Amount | Up to USD 500 total | Creates a deterministic financial ceiling |
| Counterparty | Approved cloud vendors | Limits destination risk |
| Time | Expires 2026-07-31 | Stops forgotten standing authority |
| Cadence | One purchase | Prevents accidental recurrence |
| Step-up | Required if non-refundable | Keeps consequential choices human-visible |
Human-present and delegated flows
In a human-present flow, the agent can prepare the order while the principal approves the exact transaction. The approval should display seller, items, total, currency, terms, and rail-specific recourse. Biometric or strong account authentication may confirm the principal, but the approval record must still bind to the transaction.
In a delegated flow, policy evaluates the order against a pre-existing mandate. The user is not interrupted unless a threshold or ambiguity triggers step-up. Delegation should be revocable, observable, and narrow enough that compromise has a bounded blast radius.
Credential scope should mirror mandate scope
The safest credential is the one that cannot do more than the mandate allows. Seller-scoped payment tokens, transaction-bound signatures, short-lived wallet permissions, and limited-use network tokens reduce the damage from model manipulation or runtime compromise.
Do not hand a model raw card data, seed phrases, private keys, or long-lived API secrets. Keep credential issuance and signing behind a deterministic service that rechecks the approved decision and refuses mismatched transaction data.
Revocation and explainability are runtime features
A mandate can become unsafe before it expires: the principal leaves the organization, a merchant becomes blocked, a device is compromised, or budget policy changes. Revocation should propagate to credential services and pending transactions quickly, with a record of who changed what and why.
Every allow, deny, and step-up result should produce a concise explanation from deterministic rule facts. A model can translate that explanation for the user, but it should not invent the reason after the decision.
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.