Visa builds trust and payment infrastructure for AI shopping agents

Visa is building infrastructure for a shopping journey in which an AI agent can help a buyer discover products and initiate a purchase. Visa Intelligent Commerce addresses payment credentials, controls and authentication, while Trusted Agent Protocol helps merchants recognize approved agents. The useful distinction is between recognizing software that arrives at a storefront and authorizing what it may buy. A trustworthy agent identity is valuable, but it does not by itself establish the buyer’s intent, the order’s accuracy or the merchant’s ability to fulfill it.

01 / ProductA network role in the agent-driven buying journey

The Visa company overview places the company between financial institutions, merchants and the wider payment ecosystem. Its agentic-commerce work extends that role to software acting for a buyer. Visa Intelligent Commerce, or VIC, is a portfolio for agents, issuers, merchants and developers. It brings payment credentials and controls into automated buying, rather than presenting a consumer shopping assistant as the entire product.

The Trusted Agent Protocol overview describes a way to recognize approved agents through signed requests. Its underlying HTTP message-signature approach allows a receiving system to verify a request using published key material. That is a more useful basis for recognition than trusting a name supplied in a user-agent string. Verification establishes a specific technical signal; the merchant still chooses how that signal affects access to its store.

The detailed specification separates agent recognition, consumer information and payment information, including signatures that connect those elements. This matters because a browsing agent and a purchasing agent may need different permissions. A merchant can design separate checks for catalog access, cart creation and checkout, instead of treating every request from recognizable software as equally authorized.

02 / AudienceMerchants and builders with a real agent-commerce integration

Visa’s approach is relevant to merchants evaluating legitimate AI shopping traffic, payment providers adapting acceptance flows, and developers building purchasing agents. These teams share a coordination problem. The agent must communicate its role, the merchant must apply a suitable access policy, and the payment participants must understand the permitted transaction. A useful evaluation identifies which participant is responsible for each decision before selecting an integration tool.

For a storefront operator, DataDome provides adjacent context around distinguishing automated traffic and enforcing access policy. Cloudflare is relevant to the infrastructure through which requests may reach an application. These are architectural comparisons rather than equivalent payment products. Agent identification at the edge and payment authorization at checkout should exchange useful context without collapsing into one undifferentiated allow decision.

A merchant with unreliable stock records or unclear order confirmation should repair those foundations before automating more purchases. An agent can make an incorrect listing easier to act on, which magnifies the underlying problem. Start with a category whose price, availability, shipping rules and return conditions can be represented clearly. The quality of those records affects whether a technically valid transaction produces a satisfactory customer experience.

03 / WorkflowA proposed merchant workflow from signed request to confirmed order

Consider a proposed pilot for an online office-supplies merchant. Approved agents may search a bounded catalog and prepare an order, while the buyer retains a clear purchase-approval step. This is an illustrative implementation plan, not a system Sequenced has deployed. Define success through completed authorized orders, accurate fulfillment and understandable exception handling. An increase in automated page visits alone says little about whether agent commerce works for the business.

First map the request path. Identify the component that receives the agent signature, retrieves the appropriate verification material and communicates the result to the commerce application. Preserve the distinction between a missing signature, an invalid signature and a verified agent. Each state needs a deliberate response. A verification failure should not silently become a successful identity check because the catalog endpoint happens to return a page.

Next define what verified browsing permits. Product discovery may expose public descriptions and current availability without granting access to customer records or account changes. Use an explicit list of allowed operations for the pilot. Consider how the system behaves when prices change during a conversation, a product becomes unavailable or an agent retries a request. These are ordinary commerce conditions that remain important when the interface is conversational.

At cart creation, connect the chosen items to an order representation the buyer can inspect. Show quantities, total cost, delivery details and any material conditions before approval. The Visa and OpenAI partnership discussion describes consumer control alongside tokenization, authorization and fraud monitoring. For this proposed workflow, translate those ideas into a concrete approval record instead of treating a general instruction to shop as unlimited purchasing authority.

Keep the payment integration separate from request recognition. Confirm the participating agent, processor or acquirer and the actual services available to the merchant. A successful Trusted Agent Protocol check does not prove that every VIC payment capability is enabled. Use approved test environments and scenarios to establish how credentials, limits and confirmation travel through the intended route. The responsible payment team should own that acceptance decision.

After checkout, reconcile the order against the payment and fulfillment records. A timeout may leave the agent unsure whether an order completed; a retry must not casually produce a duplicate purchase. Give support staff a reference they can use without reading the entire conversation. Include cancellation and unavailable-stock cases in the evaluation. The operational question is whether the merchant can explain and resolve the outcome for a customer who never understands the protocol.

Review exceptions with both commerce and infrastructure owners. Track signature failures, rejected actions, duplicate attempts, customer corrections and completed orders. Investigate the cause before changing an access rule. A low completion rate could reflect inaccurate catalog information, unsupported payment access or an unnecessarily broad traffic block. The pilot should identify the limiting step rather than attributing every problem to the agent’s language model.

04 / PricingAccess and commercial scope differ across the portfolio

The public VIC page offers a partner contact route rather than a universal self-service tariff. It also explicitly says the product is in deployment and that the final version may not include every described feature. Treat that qualification as part of the product description. A commercial discussion should establish which functions are available to the proposed participants and market, with responsibilities and charges identified in writing.

The protocol terms allow implementation of the specification and sample code in production without a separate Visa Solution Approval submission. That permission should not be generalized to all payment APIs or services. The terms also require the current specification and timely implementation of updates. Budget for maintaining the integration as well as building it. These are product conditions to review with the responsible team, not a substitute for its agreement review.

05 / DistinctionsA trust layer that distinguishes the participants

The most useful design choice is the separation of agent, consumer and payment context. That gives an implementation a vocabulary for asking who is making the request, which buyer it concerns and how a payment is represented. It can make authorization boundaries more inspectable than a single opaque automation session. The actual benefit depends on how carefully the receiving merchant uses the verified information.

Visa’s MCP server and acceptance-toolkit announcement describes tools that connect agents to commerce functions, including invoice and payment-link workflows. The September 2025 announcement labels those offerings as pilots. Their inclusion in current portfolio material makes them relevant to investigate, but it does not establish general availability. Request a current access answer for the precise tool the proposed workflow requires.

06 / QuestionsRecognition is only one part of a completed purchase

The unresolved questions are practical: which agent partners participate, which payment capabilities are enabled, how the merchant receives buyer approval, and how support handles a disputed instruction. Public architecture pages cannot answer those questions for every account. Require a demonstration of the intended route and a clear explanation of unsupported cases. Keep prospective partnership features distinct from capabilities available in the merchant’s actual environment.

Cryptographic verification also cannot establish that a description is accurate, a recommendation is suitable or a shipment arrived. Those judgments belong to catalog management, customer approval and fulfillment evidence. A strong implementation preserves those records instead of relying on the reputation of the agent or network as a substitute. That makes the customer experience understandable when several companies participate in one purchase.

07 / DecisionBegin with a narrow acceptance decision

Visa is a strong AI-related selection because it addresses the infrastructure needed when agents move from recommendations to transactions. The immediate evaluation should be specific: recognize a class of legitimate requests, connect a permitted purchase to buyer approval, and confirm the available payment route. Expand when those responsibilities are observable and the commercial arrangement supports the proposed workflow.