Intent Intelligence: Building Trust in Agentic Commerce

Introduction

Traditional systems are built around user actions where a person browses, decides, and executes each step of a transaction. As agents begin to act on behalf of users, that interaction model is changing. A user may define what they want once, while an agent interprets those instructions, evaluates changing conditions, and ultimately executes a purchase on the user’s behalf.

This requires a new model of establishing trust in the user, representing intent as clear boundaries, and enforcing those boundaries at execution. This is necessary to help limit transaction disputes, which are costly for everyone in the ecosystem. Because issuers are responsible for managing cardholder disputes, providing them with authenticated purchase intent information before the agent transacts can help issuers assess and mitigate dispute risk.

Below, we outline a new approach, Intent Intelligence, for capturing confirmed user intent and carrying that information through the transaction as durable guardrails designed to constrain agent action. Doing so helps ensure agents act within user-defined boundaries, provides additional signals for authorization and fraud prevention, and helps reduce costly friction such as disputes and chargebacks.

Intent Intelligence

Intent Intelligence is a suite of services to create, update, and cancel a user’s authenticated intent. Intent represents those instructions and constraints, such as maximum amount, merchant preference, time limits, and other parameters. The agent may ask follow-up questions until it has sufficient information to act. Once the user confirms the intent and selects a payment instrument, the intent can be authenticated. Supporting services may then enable the authenticated intent to be created, updated, or canceled throughout the lifecycle.

Intent Intelligence can be used for:

Intent	The user expresses constraints of a purchase for the agent to act on, and delegates final purchase authority to the agent	Broad Intent - for example, “build me a website, but don’t spend more than $100.” Specified Intent - “If the sneakers I want to purchase are restocked before April 15th, buy one pair in a US women’s size 8 for $200 or less.”
Cart	The user confirms an explicit cart, filled with the specific items they want the agent to purchase.	Order-Ready Cart - The agent fills a cart and the user signs off on it before the agent completes the purchase Proposed Cart - The user confirms a cart presented by the agent. The agent then fills the cart with the merchant and checks out.

Note that these scenarios all carry incremental risk to the purchase journey today. In the broad intent scenario, the agent must correctly interpret the desired goods and the constraints, find the merchant and item that best fit the intent, and accurately execute it when the constraints are met. In the first cart scenario, there is risk that after the user authenticates, the agent modifies the cart and checks out with items not authorized by the user. In the second cart scenario, the agent could make an error when filling the cart with the merchant.

In each scenario, controls can help account for and mitigate these agent risks. In addition, there is increased risk of fraudulent claims as users may attempt to dispute agentic transactions that they did authorize. Intent Intelligence is designed to provide these guardrails through data sharing that enables payment credential scoping and user sign-off.

Authentication

Once the user selects a card and confirms their intent with the agent, the intent information is shared with the issuer. The user must both authenticate their identity and sign off on the intent information captured by the agent. Intent sign-off can be performed via Passkey, or the issuer can decide to delegate sign-off to a third party, such as the agent or a wallet provider. Issuers may require incremental data to support sign-off delegation.

After authentication, an Intent ID and Proof of Intent Token are issued.

• Intent ID – A unique identifier representing the purchase intent record, used as the primary key for any subsequent intent requests (e.g., intent lifecycle activities)
• Proof of Intent Token – A JSON Web Token representing the high-level constraints of the intent

Create Intent API

The Create Intent API is used to share the user’s confirmed purchase intent, including merchant, maximum budget, and other preferences, to create a Proof of Intent Token. This implementation keeps users in control of agentic transactions by enabling spend controls and providing signals to protect against fraud and agent risk.

The Proof of Intent Token can be used to obtain a scoped payment credential and complete the transaction. Based on the user-defined intent constraints, the Proof of Intent Token:

• Expires on the date set and confirmed by the user
• Can be single-use or multi-use to generate payment credentials for use across one or multiple merchants

Ecosystem Roles & Responsibilities

The collection, storage, and sharing of user intent may vary depending on the agentic commerce integration model. Different participants may be responsible for capturing intent, obtaining user authentication, storing intent for future management, and sharing intent with issuers. Regardless of the model, the objective remains the same: to preserve the user’s authorized purchase intent and ability to manage their intent throughout the transaction lifecycle.

Agent

The agent is typically responsible for collecting the user’s purchase intent, interpreting the user’s instructions, and translating them into structured intent data. As part of this process, the agent may ask follow-up questions to clarify missing information or resolve ambiguities before the intent is confirmed.

After the user confirms the intent, the agent may store the intent to enable future lifecycle management, such as allowing the user to view, modify, or cancel an existing intent. Where issuers permit delegated sign-off, the agent may obtain user sign-off on the intent. The agent may submit the intent directly to the issuer.

Vault Provider

Some implementations may introduce a token vault as an intermediary between the agent and the issuer. A vault provider may securely store user intent, manage the intent lifecycle on behalf of the ecosystem, or facilitate user authentication where delegated by the issuer. The vault may also transmit the confirmed intent to the issuer.

Digital Wallet

When a digital wallet is part of the purchase journey, the agent or vault may share the confirmed intent with the wallet provider. Depending on the implementation, the wallet may become responsible for authenticating the user, obtaining delegated sign-off, transmitting the intent to the issuer, and maintaining the intent record for future customer servicing and lifecycle management.

Issuer or Network

In any implementation model, issuers should receive the purchase intent information to perform risk assessment, authorize delegated execution, and scope payment credentials against the approved intent. Because issuers are responsible for managing cardholder disputes, access to authenticated purchase intent information before a transaction occurs places them in the best position to identify and mitigate dispute risk before execution. This access also enables issuers to evaluate subsequent disputes against the intent confirmed by the cardholder.

They may also choose to delegate certain functions to the payment network. Issuers may also retain the intent record to support subsequent payment credential issuance, validate future payment requests against the authorized intent, and provide customer service capabilities that allow cardholders to review, manage, or revoke their authorized intents.

Intent Data and Controls

The agent (or other party with intent data) shares data elements including:

Purchase Summary	A summary of the purchase intent with the user including relevant details. Any personal details irrelevant to the purchase should be removed. For example, if a user prompts, “I want to buy a flight for my mom’s birthday on July 12th,” the agent will confirm the date and airline of the flight with the user. The purchase summary shared in the intent payload would be “Flight on July 12th,” with other personal details withheld.
Max Amount	The maximum amount the user is willing to pay
Intent Expiry	The latest date by which the intent can be actioned
Merchant Data	If the user has indicated a merchant preference
Item-Level Conditions	If the fulfillment of one item is conditional on the fulfillment of another. For example, flight insurance should only be purchased if the flight tickets were purchased. If no conditions are specified, each item is fulfilled independently.
Maximum Number of Transactions	An intent may require more than one purchase, such as shoes from one vendor and socks from another. The agent indicates the expected maximum number of purchases in the intent payload which maps to the maximum number of payment credentials that can be issued.
Order Context	Captures additional cart details to enhance authentication, authorization decisioning, and dispute adjudication. The order context type should be “Intent” when it reflects a user’s defined parameters and preferences for the purchase, and “Cart” when it reflects the product(s) approved to be purchased. Note: An item reference ID and merchant reference ID are requested for each item and merchant. These are intended for reference within the same request body, not as stable ecosystem identifiers.
Purchase Criteria	Indicates whether the user requested that the agent make the purchase after certain constraints are met, and what those constraints are. Examples include “buy this for me when it restocks” or “make this purchase on Cyber Monday.”

Once this data is shared and user sign off on the intent is obtained, issuers may perform risk assessment and complete an additional step-up as needed. Because the issuer is responsible for managing cardholder disputes, this intent information can help identify potential dispute risk before execution and provide evidence of the parameters authorized by the cardholder if a dispute later arises. Once risk assessment is complete, the Intent ID and Proof of Intent Token are created and should be used as controls in subsequent steps of the purchase journey, such as scoping the payment credential and validating that a purchase request maps to an authorized intent.

Sample Data

Note: Required data elements may vary based on implementation and use case.

Sample 1: Order Context – Item Details

Item-level data representing the items the user requested and approved at intent creation.

Sample 2: Order Context – Merchant Details

Merchant-level data representing the merchant(s) the user requested and approved at intent creation.

Sample 3: Purchase Criteria

Specific constraints under which the user approved the purchase.

Conclusion

Intent is critical to ensuring credibility and control throughout the emerging agentic commerce ecosystem. Thoughtful implementation of Intent Intelligence can help prevent avoidable disputes and aid in dispute resolution, helping to foster trust and confidence as AI-powered transactions become increasingly automated.