Payment Gateway

Mandates and Verifiable Intent Explained (Part 3 of 5)

Published:
October 7, 2026
Author:
Sascha Huwyler
TL;DR

EMVCo's draft framework uses Verifiable Intent to make a consumer's approval provable. A checkout mandate covers what is bought; a payment mandate covers how it is paid. Open mandates set limits for an agent, closed ones hold final values. Up to three signed layers link the card issuer, the consumer and the agent, and each party sees only what it needs.

Agentic Payments Series, Part 3: Proving What the Consumer Approved

A mandate is a structured record of what the consumer approved. VI uses two kinds, each shown to a different party:

Checkout mandatePayment mandate
AnswersWhat is being boughtHow it is being paid
ContainsItems, quantities, prices, merchant identity, a merchant-signed record of the cartPayment credential reference, payee, amount and currency
Seen byThe merchantThe payment network, acquirer and issuer

Source: EMVCo, EMV® Agentic Payments – Framework for Specifications (v1.0 Draft)

The two form a Mandate Pair. They are shown to different parties but share a common reference, so each party can confirm it is looking at the same transaction without seeing the other half.

Open and closed mandates

A mandate is either open or closed, and this maps to the two execution modes.

  • A closed mandate holds final values: exact items, merchant, payee and amount. In immediate mode, the consumer approves these directly.
  • An open mandate holds limits instead of final values. In autonomous mode, the consumer approves the limits, and the agent later produces a closed mandate with the final values it chose.

When the agent pays, verifiers check that the closed mandate falls within the open one.

Constraints: the limits themselves

Open mandates carry constraints. The framework describes two families:

  • Checkout constraints: which merchants the agent may use, and which products and quantities it may buy.
  • Payment constraints: which payees may be paid, a minimum and maximum per transaction, a validity period, and a total budget across purchases.

Per-transaction limits can be checked on the spot. A total budget needs a running total, which the framework says is typically kept by the payment system.

The chain of trust

VI builds each approval as a chain of up to three signed credentials:

  1. Layer is issued by the payment credential provider, such as a bank, and stored in the consumer's wallet. It links the consumer to their card. The framework names the EMV Digital Payment Credential as a potential candidate for this layer.
  2. Layer is the consumer's approval, signed in their wallet. In immediate mode, the chain ends here.
  3. Layer exists only in autonomous mode. The agent signs it when making the actual purchase, using a key the consumer authorised in Layer 2.

Each layer is tied to the one above, so a credential cannot be lifted out and reused elsewhere.

Showing only what each party needs

VI uses selective disclosure: each party receives only the parts relevant to its role. The merchant sees what was bought, not how it was paid. The payment side sees the payment details, not the cart. If a consumer approved several possible merchants, the agent reveals only the one it used.

Linking payment to checkout

The framework describes two points where payment is tied to checkout. At approval time, the payment mandate references the checkout mandate the consumer approved. At purchase time, both mandates carry the same reference derived from the merchant-signed cart. If the cart changes after the merchant signed it, the reference no longer matches.