How is user consent captured with agent transactions?
User consent is captured with agent transactions through a signed consent receipt the user issues. The receipt binds scope, amount caps, merchants, and a nonce so every agent transaction can be verified.
Short answer: Consent is a cryptographic receipt the user signs - not a Terms checkbox alone. Each agent transaction carries that receipt; merchants and issuers verify it before money moves.
In This Guide
Why Consent Verification Matters · What Must Be in a Consent Receipt · Consent Verification at Transaction Time · Consent vs. Terms Acceptance · Revoking Consent
Trust Signals & Evidence
Author: AffixIO (Kris & Becca Richens). See What is AffixIO.
Method: Consent verification converts “user intent” into a cryptographic receipt, then verifies that receipt at transaction time (signature, scope, constraints, expiry, and anti-replay).
Privacy: Stateless verification by design; no PII stored. See Privacy Policy.
Last updated: March 18, 2026
Further reading: consent receipts, consent framework, NIST Digital Identity.
Consent Verification Checklist (At Transaction Time)
When the agent presents a receipt, verify it meets the following requirements:
- Signature validity — issuer signature verifies (receipt was not tampered with).
- Scope match — the requested action is allowed by
consent_scope. - Constraint match — amount, merchant/category, currency, and time window are within receipt limits.
- Expiry — receipt has not expired (online/offline freshness policy).
- Revocation/TTL policy — receipt has not been revoked and revocation/TTL controls are satisfied.
- Anti-replay — receipt nonce has not been used before.
- Evidence output — return a binary result and reason codes suitable for audit/disputes.
See also: authorization model for how consent is combined with issuer policy.
Consent Verification Graph (Transaction Time)
This graph summarises what a verifier checks to decide whether consent evidence is valid for a proposed agent action:
Field semantics and replay rules are defined in the consent receipt spec.
Consent Failure Modes
| Failure mode | Evidence checked | Typical decision reason |
|---|---|---|
| Missing receipt | Receipt presence | RECEIPT_MISSING |
| Invalid receipt signature | Receipt signature | INVALID_SIGNATURE |
| Receipt out of validity window | Expiry (and optional not-before) | EXPIRED_RECEIPT |
| Scope mismatch | Consent scope | SCOPE_NOT_ALLOWED |
| Constraint mismatch | Amount/currency/merchant/category/time limits | CONSTRAINT_VIOLATION |
| Replay detected | Nonce / anti-replay state | REPLAY_DETECTED |
| Revocation model not satisfied | Revocation lists / TTL policy controls | REVOKED_OR_TTL_EXPIRED |
Why Consent Verification Matters
Without verifiable consent, businesses face:
- Dispute risk — Users claim they never authorized the transaction
- Compliance exposure — Regulators require evidence of consent for financial transactions
- Fraud liability — Unauthorized agent actions create financial and reputational risk
Consent receipts solve this by producing machine-verifiable evidence at the moment of delegation. See consent receipts for the full model.
What Must Be in a Consent Receipt
A valid consent receipt contains:
- Delegator ID — Pseudonymous identifier for the consenting user
- Agent ID — The agent receiving permission
- Scope — Allowed actions (pay, book, cancel, etc.)
- Constraints — Amount limits, merchant restrictions, time windows, geographic restrictions
- Nonce — Unique value for replay protection
- Signature — Cryptographic proof of issuance
- Expiry — When the consent expires
See the consent framework for implementation details.
Consent Verification at Transaction Time
When the agent presents a transaction, the verifier checks the consent receipt against the transaction context:
Consent vs. Terms Acceptance
| Aspect | Terms Acceptance | Consent Receipt |
|---|---|---|
| Scope | Broad (everything) | Per-action, per-constraint |
| Evidence type | Timestamp + checkbox | Signed proof object |
| Verifiable at transaction time | No | Yes |
| Replay protection | No | Yes |
| Offline verification | No | Yes |
See also: OAuth vs. consent receipts.
Revoking Consent
Consent can be revoked by the user at any time. Revocation is handled by:
- Expiry — Receipts have a built-in expiry timestamp
- Revocation list — Issuer maintains a revocation list checked at verification time
- Short TTL — Issuing receipts with short time-to-live (e.g., 1 hour) limits exposure
Ready to implement?
Explore the reference architecture or request a technical walkthrough.
Frequently asked questions
The user signs a consent receipt listing allowed actions, merchants, amounts, and expiry. The agent attaches it to each transaction.
They verify the receipt: valid signature, matching scope, satisfied constraints, and no replay.
Machine-verifiable receipt checks at checkout or in the payment API.
Expressed as a signed receipt, distinct from marketing or generic OAuth scopes.