MENU
Visa Intelligent Commerce (VIC) is Visa's framework for enabling AI agents to participate in payment and commerce workflows. Introduced in April 2025, it combines agent-specific payment credentials, user authentication, spending controls, and transaction validation so software can act on a user's purchasing instructions without receiving unrestricted card details. Visa has since expanded the initiative through agent APIs, merchant tools, Trusted Agent Protocol, and Intelligent Commerce Connect.
The initial agentic commerce announcement reflected a broader shift from AI-assisted product discovery toward software that can complete purchases under delegated authority. For companies evaluating agentic payments infrastructure, VIC is most relevant as a card-network layer for authenticated agent purchases rather than a complete billing or monetization system.
Visa Intelligent Commerce extends existing card-payment infrastructure to transactions initiated or completed by software acting on behalf of a user.
Visa describes four central functions: agent-specific tokenization, user authentication, payment controls, and transaction signals. Together, these functions are intended to connect a user's purchasing instructions with the credential eventually used by the agent.
VIC uses tokenized credentials rather than exposing the underlying card number directly to an agent.
When a supported Visa credential is enrolled, an agent can request payment credentials for a purchase covered by the user's authenticated instruction. Visa can then compare later credential and authorization activity with those instructions.
This approach separates ownership of the underlying card from the authority granted to the agent. The agent receives a credential for an approved purchasing context rather than general access to the cardholder's payment details.
Visa Intelligent Commerce combines several payment-security mechanisms:
Passkeys are relevant to the authentication layer. The FIDO Alliance describes phishing-resistant passkeys as cryptographic credentials that avoid reusable passwords and shared secrets.
These controls reduce the need for an agent to possess unrestricted payment information, but businesses still need to define how much commercial authority an agent should receive and when additional approval is required.
VIC does not replace the merchant's existing gateway, acquirer, or payment processor.
Instead, it adds infrastructure for agent identity, credentials, authentication, and transaction intent around an existing payment flow. The merchant can continue processing a Visa card transaction through its established payment stack.
A conventional gateway handles payment information between the checkout interface and the systems responsible for authorization and processing.
VIC addresses a different question: how can software acting for a customer obtain and use legitimate payment authority without simply receiving the customer's ordinary card credentials?
That distinction becomes important as merchants begin supporting both human and agent-initiated checkout.
Visa introduced Intelligent Commerce Connect in 2026 as part of the broader VIC portfolio.
It provides a single integration point for capabilities such as tokenization, authentication, payment initiation, and spending controls while allowing businesses to retain existing commerce and processing infrastructure. Visa describes the product as network, protocol, and token-vault agnostic, with pilots involving multiple commerce and payment companies.
For businesses already operating a card-payment stack, that can reduce the need to build separate integrations around every emerging agent protocol.
Payment credentials solve only part of an agent-commerce transaction. A merchant may also need to determine whether automated traffic represents an approved commerce agent.
Visa's Trusted Agent Protocol addresses that recognition problem.
Trusted Agent Protocol builds on HTTP Message Signatures and related web-authentication mechanisms. The underlying HTTP Message Signatures standard defines how components of an HTTP message can be cryptographically signed and verified.
Visa uses this approach to let registered agents transmit signals that merchants or infrastructure providers can validate. Those signals can distinguish different agent activities and associate the request with payment or consumer information.
Trusted Agent Protocol is primarily about recognizing an agent and the context of its interaction.
A merchant can use the signed information to determine whether the request comes from a registered commerce agent rather than relying only on an IP address or user-agent string. The merchant still controls whether and how the automated visitor can browse, purchase, or interact with the site.
This makes merchant readiness separate from payment credential availability. An agent may have valid payment authority, but the merchant's site still needs to support or permit the interaction.
Visa Intelligent Commerce is primarily oriented toward agents acting for consumers or businesses during purchasing workflows.
An agent might search for a product, evaluate options, identify a merchant, and proceed with a transaction under previously defined instructions.
VIC allows an enrolled payment credential to be represented through a token associated with the agent.
The user can authenticate the purchasing instruction and define controls around the transaction. The agent then operates within that authorized context rather than receiving unrestricted card access.
This model fits shopping, travel, procurement, recurring business payments, and similar workflows where the final merchant already accepts Visa.
For software that needs a reusable budget across purchases, delegate a spending budget provides another control pattern in which payment authority has a defined amount, duration, transaction limit, and revocation path.
Visa acceptance does not automatically mean every merchant experience can be completed autonomously by an AI agent.
Agents still interact with merchant-specific storefronts, inventory systems, checkout rules, fraud controls, and authentication requirements. Visa has therefore expanded VIC beyond credential provisioning into merchant-side infrastructure such as Intelligent Commerce Connect and Trusted Agent Protocol.
The practical implementation depends on both sides of the transaction: the agent must carry valid authority, and the merchant must recognize and process the agent's interaction appropriately.
VIC extends concepts already used in tokenized card payments into delegated agent transactions.
The central design principle is that an AI agent does not need ownership of the underlying credential. It needs permission to use a narrower credential under defined conditions.
Visa's current documentation describes authenticated user instructions as part of the VIC flow.
The user's instruction establishes the context for what the agent is authorized to purchase. Credential requests and subsequent payment activity can then be checked against that authorization.
The specific controls available can depend on the product, issuing institution, integration path, and market. VIC should therefore be evaluated based on the exact transaction and card population a product intends to support rather than assuming identical controls for every deployment.
A tokenized payment credential and an organization-wide spending system solve different problems.
VIC can establish authority around card purchases. Businesses operating multiple agents may additionally need shared funding rules, team allocations, or cross-agent budget ceilings.
Infrastructure for groups and budgets can place those policies above an individual credential, so organizational limits remain independent of agent reasoning.
The agent-commerce ecosystem now includes multiple standards covering different parts of the transaction.
These include protocols for agent identity, communication, commerce, payment authorization, and machine-native settlement. Visa's current strategy increasingly reflects this fragmented environment.
Intelligent Commerce Connect is described as protocol agnostic rather than tied to one agent-payment standard. Visa's broader research identifies protocols including TAP, x402, MPP, ACP, and UCP as parts of the emerging commerce stack.
That distinction is important because VIC itself should not be described as an x402 payment protocol.
Visa can participate in environments where x402 is used, but the underlying VIC card credential and Visa's separate stablecoin-settlement initiatives are different products and functions.
The original draft connected VIC directly to Visa's nine-blockchain stablecoin settlement program. These should be treated separately.
Visa's global stablecoin settlement pilot now supports nine blockchains and reached a reported $7 billion annualized settlement run rate in 2026. That program concerns how participating issuers and acquirers settle obligations with Visa and is not the same thing as an AI agent using Visa Intelligent Commerce to obtain a payment credential.
For an AI product, card purchasing and machine-native crypto settlement may therefore sit in different parts of the architecture.
Visa Intelligent Commerce builds on existing Visa tokenization, authentication, authorization, risk, and dispute infrastructure.
That provides a familiar card-network foundation, but enterprises still need to determine their own compliance responsibilities across the complete implementation.
VIC reduces exposure to raw card data by using tokenized credentials and authentication around delegated purchasing authority.
Trusted Agent Protocol addresses a different security concern: proving that an automated request comes from an approved agent. Together, the mechanisms cover payment credentials and agent recognition without treating them as the same identity layer.
Merchants and agent developers remain responsible for their own application security, authorization logic, data handling, credentials, and integration controls.
Visa's Developer Center currently lists VIC across multiple global regions but notes that the product remains in development and deployment and may not be available in every market.
The sandbox is free to use, while production pricing requires contacting Visa.
This is more accurate than assigning a universal implementation cost or describing the platform as limited only to U.S.-issued consumer cards.
VIC addresses a defined part of the agent-commerce stack: enabling agents to participate in card purchases under authenticated user authority.
Several factors should be reviewed before implementation.
Merchant workflow: A valid agent credential does not guarantee that every storefront or checkout flow is ready for autonomous interaction
Card and market availability: Access depends on the specific market, issuer, agent platform, and deployment path
Production terms: Public documentation does not provide one universal production price
Protocol architecture: VIC can participate alongside emerging agent protocols, but it should not be treated as identical to x402, MCP, or other machine-payment standards
Monetization scope: VIC focuses on purchasing through Visa credentials rather than metering and pricing the work of an AI API, model, agent, or MCP tool
The last distinction becomes particularly important for companies selling digital resources to software rather than building agents that buy from existing merchants.
Visa Intelligent Commerce provides a card-network path for agents that need delegated purchasing authority. Nevermined extends that model into a broader payments layer for agents that spend and AI services that need to monetize machine-accessible work.
Nevermined integrates Visa Intelligent Commerce into its card-delegation and x402 infrastructure.
A user can enroll an eligible Visa credential, establish a spending mandate, and provide an agent with scoped payment capability. When the agent needs to purchase a resource, Nevermined can use the Visa payment path while x402 carries the machine-readable payment interaction.
This connects a card credential to a request-level payment flow rather than requiring every AI service to implement conventional checkout.
Nevermined's card delegation controls support bounded purchasing authority across Visa Intelligent Commerce, Stripe, and Braintree payment methods.
A delegation can define the spending amount, duration, maximum transaction count, API-key scope, and revocation status. The user maintains control over the funding source while the agent receives only the authority required for its task.
That allows the same agent-payment layer to work with different card providers instead of tying authorization policy to one network credential.
Merchant checkout usually begins with a known product price. AI services frequently work differently.
A request may consume different numbers of tokens, tools, data calls, or minutes depending on what the agent asks it to do. Nevermined supports dynamic pricing patterns that can calculate prices from those workload variables.
This connects the amount charged to the work the AI service actually performs rather than forcing every machine-accessible resource into a fixed retail checkout model.
Nevermined uses x402 to make payment requirements part of the API or tool request.
The provider can return payment requirements, receive authorization, verify the applicable permissions, execute the workload, and settle the payment afterward. The x402 payment protocol supports both nvm:erc4337 for crypto and nvm:card-delegation for supported fiat/card payment providers.
This matters when running the workload itself creates measurable cost and the provider needs commercial authorization before execution.
Nevermined's groups and budgets add organization-level controls above individual agent transactions.
Teams can share an organization-funded payment method while placing separate spending limits around different groups. When a group reaches its budget, additional spend is blocked until the limit resets or an administrator changes it.
This separates financial governance from the reasoning process of any individual agent.
Nevermined's x402 implementation supports two payment schemes under the same payment protocol.
The nvm:card-delegation scheme can use supported card providers including Visa, while nvm:erc4337 uses smart accounts and session keys for crypto transactions.
That lets an AI service define its commercial interaction at the x402 layer while supporting different settlement methods underneath it.
Nevermined documents a working payment integration in five minutes for an agent API, MCP tool, or protected resource.
Teams can begin with payment authorization and settlement, then introduce workload pricing, card delegation, organizational budgets, and observability as the commercial workflow expands.
For businesses building autonomous commerce, Nevermined connects delegated payment authority with seller-side pricing, metering, request-level verification, and settlement.
Agent-payment systems can replace unrestricted card access with tokenized or scoped credentials tied to an approved purchasing context. The payment infrastructure can then enforce authorization rules before a transaction proceeds. For ongoing autonomous spending, card delegation controls can add explicit budgets, expiry, transaction limits, and revocation.
Agent authentication establishes which software is making a request and, in some systems, who that agent represents. Payment authorization determines whether that agent has permission to commit funds for the specific transaction. Production agent-commerce systems may need both because a recognized agent does not automatically have unlimited purchasing authority.
Not every agent purchase requires a new payment protocol because existing card networks can support transactions when the necessary agent credentials and controls are available. APIs, MCP tools, and other machine-native resources can benefit from payment requirements that are communicated directly in the request. The x402 payment protocol provides that request-level mechanism for supported card and crypto payment schemes.
Businesses should place financial limits in the payment infrastructure rather than relying on each agent to interpret a spending policy correctly. Individual agents can have bounded credentials while teams or departments operate under broader shared budgets. Groups and budgets provide one way to enforce those organization-level ceilings.
Card payments work well when an agent is buying from a merchant with an established card checkout process. AI APIs, models, datasets, and tools can additionally require usage metering, workload-specific pricing, request-level authorization, and software-to-software settlement. A working payment integration can place those commercial rules directly around the machine-accessible resource.
See Nevermined
in Action
Real-time payments, flexible pricing, and outcome-based monetization—all in one platform.
