UCP Mandate Evaluation — Lifecycle Profile
com.merchantstamp.mandate-evaluation
This page is the canonical reference for the mandate-evaluation lifecycle profile MerchantStamp proposes for the Universal Commerce Protocol (UCP) Checkout capability. It specifies what a business does when an AP2 mandate’s time-to-live (TTL) elapses during checkout completion. UCP’s contribution is the lifecycle semantics and the evaluation point — not a new receipt format. The outcome is expressed using the existing AP2/FIDO receipt construction.
Status & namespace
Proposed extension to the UCP Checkout capability, published under the vendor namespace com.merchantstamp.mandate-evaluation per UCP’s vendor-namespace-first rule, pending promotion to core. It defines lifecycle semantics only and reuses the AP2/FIDO receipt construction — it does not introduce a UCP-native receipt family. Normative keywords follow RFC 2119 / RFC 8174. The proposal resolves UCP issue #512 and was refined following review feedback in issue #515.
The gap it closes
The Checkout lifecycle has a processing state — complete_in_progress — entered after a business accepts Complete Checkout and before the order reaches completed. If the mandate’s TTL elapses while the session is already in complete_in_progress, the current specification does not define what happens. AP2/UCP Mandates only states that the business checks expiry at the complete request, and mandate_expired only means the exp timestamp has passed. Neither pins down the in-flight case. That is a Checkout state-machine question, and that is what this profile specifies.
Authorization vs. liveness
The profile separates two properties usually conflated under “TTL validity”:
Authorization
Did the buyer permit this charge? Settled the instant the business accepts Complete Checkout against a mandate valid at that instant. A processing delay the buyer did not cause does not unsettle it. PSD2 Art. 80 irrevocability is the cut-off.
Liveness
Is the grant inside its window right now? Liveness gates whether a payment MAY be entered into processing; it does not determine whether work already admitted stays authorized. TTL is a pre-agreed bound on when the grant may be exercised, not a live withdrawal signal.
The model
Evaluate mandate liveness exactly once, at the point of use (receipt of Complete Checkout), against binding transaction data, and freeze authorization there. A mandate valid at that instant runs to a terminal AP2 receipt regardless of later expiry; a mandate already lapsed at that instant never enters processing. This mirrors how Checkout already treats Eligibility Verification at Completion: a property resolved once, at a defined point, on binding data. No new lifecycle status is introduced — the extension only constrains which transition is taken out of ready_for_complete.
Two outcomes
The business MUST freeze authorization for the session, MUST record the evaluation as a verifiable attestation, MAY transition to complete_in_progress, and MUST run to a terminal state. Later expiry MUST NOT abort processing or shorten the settlement window.
The session MUST NOT enter complete_in_progress. It MUST terminate canceled with a mandate_expired message and MUST surface the lapse as the terminal artifact. Invariant: mandate_expired MUST NOT be reported once a session has entered complete_in_progress.
Receipts reuse AP2/FIDO
Both outcomes are expressed through the existing AP2 Checkout/Payment Receipt construction (or a minimal AP2-aligned profile of it) — not a separate UCP receipt family. UCP’s only normative requirement here is binding and mutual exclusivity: the recorded evaluation (positive case) and the terminal-lapse outcome (cancellation case) are the same evidentiary shape over one verification path, distinguished by the receipt’s type/reason; a verifier MUST be able to bind both to the same flow via the mandate reference + checkout_id; and for one checkout_id a business MUST NOT emit both a positive recorded-evaluation and an expiry/cancellation terminal artifact. Signing and verification reuse the AP2/UCP receipt and signature construction (ES256 recommended, JCS RFC 8785 canonicalization, detached-JWS) rather than a UCP-specific mechanism.
Capability profile
The business advertises its support so platforms can refresh a mandate before completion rather than race the boundary:
mandate_evaluationBoolean — whether the business evaluates mandate liveness at the point of use under this profile.min_remaining_ttlISO 8601 duration — the minimum remaining TTL a mandate must carry at Complete Checkout for the business to admit it.receipt/signing profileThe AP2 receipt and signing profile the business emits, so a platform knows what evidentiary shape to expect.Where MerchantStamp fits
MerchantStamp is implementing a UCP merchant server for long-tail merchants. In the agentic-commerce stack, MCP handles the agent-to-tool binding, AP2/FIDO provides cryptographic authority and the evidentiary receipt, and UCP owns the commerce lifecycle. This profile sits squarely on the UCP lifecycle layer: it specifies a state-machine transition and reuses AP2/FIDO for the receipt, deliberately avoiding any overlap with the layers above and below it.