AP2 v0.2 mandates: user intent, autonomous purchases and FIDO governance

What it is

Status as of 25 October 2026. The published AP2 specification identifies itself as v0.2. Re-check that revision, its authorization framework and FIDO's subsequent publications before implementation. AP2 supplies evidence of delegated purchase authorization inside a commerce protocol; it does not define the catalogue or checkout-update API.

Terminology matters. The v0.1.0 specification described an Intent Mandate for authorization when the user was absent, a Cart Mandate for a user-approved purchase, and a Payment Mandate conveying payment-specific information. In v0.2 there are two mandate types: Checkout and Payment. Each can be open, expressing constraints, or closed, authorizing a particular transaction. Do not combine old examples and current schemas without an explicit migration design.

Why it matters

The Checkout Mandate binds approval to the merchant's signed checkout. The Payment Mandate authorizes the associated payment. This gives different participants evidence relevant to their responsibilities rather than making the agent's narrative the authority to charge.

The authorization framework describes verifiable digital credentials using selectively disclosable signed JSON tokens, SD-JWT VCs. Signatures, key binding and constraint evaluation serve different purposes. A valid signature alone does not establish that the purchase satisfies the user's limits.

Governance also needs precise wording. On 28 April 2026, FIDO announced AP2's contribution by Google and further development through its Payments Technical Working Group, alongside Mastercard's Verifiable Intent contribution. That announcement establishes a standards-development process; it does not establish a final FIDO specification or certify an implementation.

How to apply

• Separate responsibilities. Identify the Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor and Trusted Surface. AP2 requires the Trusted Surface to be non-agentic and validation to run in deterministic code.
• Handle direct approval. In the documented human-present flow, the trusted interface displays the closed mandates and obtains consent. The credential provider checks payment authorization; the merchant verifies checkout authorization before completing the transaction.
• Handle prior delegation. For human-not-present operation, the user authorizes open mandates. Those mandates bind the agent's public key through cnf; the agent later supplies them with its signed closed mandates. Use narrowly scoped constraints and a suitable expiry.
• Fail closed on uncertainty. Verify the mandate chain, preserve claims fixed by open mandates, and evaluate every constraint. The framework treats unknown constraints as failures. unresolved_constraint can lead back to direct user approval; invalid_credential is a terminal verification error.
• Preserve the evidence trail. The example flows return Checkout and Payment Receipts. As an operational practice, retain the relevant mandate and receipt references with the order, under access controls, so an investigation can reconstruct the approval.

Pitfalls

The flow diagrams are explicitly non-normative examples, not a conformance test. Receiving a signed mandate is not evidence of delivery, nor a guarantee that a disputed purchase will be reimbursed. Specify operational responsibility for verification, receipt retention and unresolved transactions before enabling unattended purchases.