Agentic Payments Series, Part 2: What Intent Services Do

In a normal online purchase, the approval and the payment happen together. In agentic commerce they can be far apart. A consumer might approve a travel budget on Monday, and the agent might book a flight on Wednesday and a hotel on Friday, with different merchants.

Each of those payments needs to be checked against the same original approval. Someone also has to know how much of the budget is left. EMVCo's press release describes this as a need for a shared intent "state" that persists across participants.

What an Intent Service does

The framework lists six functions:

1. Registration: records an approved intent and gives it a stable reference.
2. Retrieval: lets authorised participants look up its current status and details.
3. Lifecycle coordination: tracks status for the intent as a whole and for each purchase under it.
4. Interoperability reference: provides identifiers that can travel through payment flows without exposing the full checkout contents.
5. Pre-transaction support: supplies information for checks before payment, such as risk assessment or issuing a payment credential.
6. Post-transaction support: supplies information for disputes, audit and reconciliation.

Registering an intent does not mean a payment is approved or guaranteed. It only makes a consumer approval, given elsewhere, available for reference.

Intents and orders

The framework splits tracking into two levels. The intent is the consumer's overall approval. Orders are the individual purchases made under it, such as a flight, a hotel and a car rental from one travel request.

Each order has its own status and expiry. The intent's status can be derived from its orders, which allows for partial outcomes, for example a trip where the flight was booked but the hotel failed. The framework gives example statuses such as REGISTERED, APPROVED, COMPLETED, PARTIALLY_COMPLETED, REVOKED, SUSPENDED and FAILED, but stresses these are illustrative, not a fixed list.

Keeping track of limits

Some limits can only be checked with a running record. The framework gives three examples of state an Intent Service might hold:

• Whether a single-use approval has already been used
• Cumulative spend against a budget
• How many times a recurring purchase has happened, and within which dates

The framework notes that coordinating this state across several Intent Service Providers would be complex. In its current scope, that coordination is left to the agent.

What Intent Services are not

The framework describes Intent Services as a registry and coordinator, not a decision-maker. They do not originate intent, authorise payments or enforce rules. They carry cryptographic artefacts, such as signed consumer approvals, without needing to interpret them.

The framework names payment systems and card issuers as examples of who might operate an Intent Service. It does not prescribe who must.