Visa Intelligent Commerce: What It Checks When Agents Pay

Card fraud systems learned to trust patterns. A familiar device, a usual merchant, a normal amount at a normal hour. Agents scramble every one of those signals. A good agent shops at odd hours, from cloud infrastructure, at merchants the cardholder has never used, and it may be one of many agents acting for the same person.

So the industry is rebuilding trust in layers. The merchant needs to know the visitor is a real agent acting for a real user. The issuer needs to know the credential was issued for this agent and that the purchase fits what the user allowed. And whoever runs the agents needs to know, before it pays, whether this purchase fits its own limits.

This page covers what Visa Intelligent Commerce provides at each layer and what is left for the agent platform.

What Is Visa Intelligent Commerce?

Visa Intelligent Commerce is Visa’s platform for agentic commerce. It gives AI agents tokenized Visa credentials in place of card numbers, lets consumers set spending limits and conditions for agent purchases, and shares commerce signals with Visa for transaction controls and disputes. Visa’s companion Trusted Agent Protocol lets merchants verify agents.

Visa introduced Visa Intelligent Commerce on April 30, 2025, saying it “opens Visa’s payment network to the developers and engineers building the foundational AI agents transforming commerce.” The launch release lists what it offers:

• AI-Ready Cards: “Replaces card details with tokenized digital credentials.” They “confirm that a consumer’s chosen agent is allowed to act on a consumer’s behalf,” and “Only the consumer can instruct the agent on what to do and when to activate a payment credential.”
• AI-Powered Personalization: consumers share Visa spend insights, with consent, to improve recommendations.
• Simple and Secure AI Payments: “Allows consumers to easily set spending limits and conditions, providing clear guidelines for agent transactions. Commerce signals are shared in real-time with Visa, enabling Visa to effect transaction controls and help to manage disputes.”

In June 2026, Visa called Visa Intelligent Commerce “the company’s platform for agentic commerce” and announced token enhancements: richer token data on “the transaction type, where the token is being used and who is making the payment,” and a “token assurance signal” generated from each token’s provisioning and behavioral history. Visa says these “provide issuers with stronger signals for authorization decisions.”

How the Visa Intelligent Commerce APIs Work

On the Visa Acceptance Platform, Intelligent Commerce “enables your AI agents to process purchase intents and complete transactions on behalf of your customers.” The endpoints page, tagged pilot, lists six calls:

The /acp/ in these paths is Visa’s own prefix for its Acceptance Platform API. It is not the Agentic Commerce Protocol, whose checkout calls use /checkout_sessions.

The purchase intent carries the consumer’s instruction. The docs’ example: “Find and purchase all of these supplies. Keep the total purchase amount under $100.” Initiating one “enables Visa Acceptance Platform to verify that your agent is acting in accordance with the customer’s intent.” Its required fields include a mandates array, each mandate with a mandateId, a description, an effectiveUntilTime and a declineThreshold amount and currency. The instruction ID in the response “is needed to complete follow-on API requests, such as updating and cancelling the purchase intent.”

For agent builders, Visa announced a Visa MCP Server and the Visa Acceptance Agent Toolkit on September 4, 2025, both in pilot.

Each mandate bounds one instruction. A budget that spans many instructions, agents or employees sits with the platform, and so does the record of which instruction belongs to which task.

The Trusted Agent Protocol

Tokens cover the issuer’s side. The merchant’s side is a different problem: the merchant’s site sees traffic, and has to tell a legitimate agent from a scraper or a bot.

Visa introduced the Trusted Agent Protocol (TAP) on October 14, 2025, “developed in collaboration with Cloudflare” and “Built upon the foundational HTTP Message Signature standard.” It is published on GitHub. The repository describes “a standardized, cryptographic method for an AI agent to prove its identity and associated authorization directly to merchants.” Per the README:

Each signature is current and bound to its context. It “includes timestamps, a unique session identifier, key identifier, and algorithm identifier,” and it is “bound to your domain and the specific operation being performed” (browsing or payment).

It resists replay. “Each signature includes unique, time-sensitive elements that ensure every request is fresh and valid only for a single use.”

It can carry identifiers. With consumer consent, a verified agent can pass “verifiable consumer identifiers, Payment Account References (PARs) for cards on file, or other identifiers like loyalty numbers, emails and phone numbers.”

“Valid only for a single use” is a property the merchant has to enforce. A verifier that checks the signature and the timestamp but keeps no record of what it has already accepted lets the same signed request through twice inside the time window.

Intelligent Commerce Connect

On April 8, 2026, Visa added Intelligent Commerce Connect, described as “a network, protocol, and token vault-agnostic ’on ramp’ to agentic commerce.” Through one integration on the Visa Acceptance Platform it “enables secure payment initiation, tokenization, spend controls, and authentication,” and lets merchants accept payments initiated via “Trusted Agent Protocol, Machine Payments Protocol (MPP), Agentic Commerce Protocol (ACP), and Universal Commerce Protocol (UCP).” Visa said it was in pilot with select partners at launch.

The protocol list matters for planning. A merchant may see the same buyer’s agent arrive through several protocols, and a platform may run agents that pay through several. Spend state has to sit somewhere that all of them read.

Visa Intelligent Commerce vs Mastercard Agent Pay

The two networks built parallel pieces:

Cloudflare, which partnered with both networks, wrote in October 2025 that “Both Trusted Agent Protocol and Agent Pay leverage Web Bot Auth as the agent authentication layer,” and that, to start, each network would host a key directory for its own registered agents. A platform whose agents pay on both networks has two sets of credentials and network-side limits, and one fleet budget of its own that both paths have to read. For the Mastercard side, see Mastercard Agent Pay.

Who Checks What

Lay the pieces out by who answers each question:

The first three rows sit with Visa, the issuer and the merchant, inside their systems. The last two are yours. Call that authorization-time context: everything the decision to submit a purchase has to read, at the moment it submits.

A Worked Failure: The Travel Desk

The numbers below are illustrative, built to show the mechanism.

A company runs a booking assistant for its employees. Each trip gets a policy budget, and each employee has a monthly travel cap. Several agents work a trip at once: one books flights, one books the hotel, one handles ground transport. Each reads remaining budget from a reporting table refreshed every 60 seconds from booking confirmations.

An employee’s trip budget is USD 1,800.00. At 14:10:00 the table shows USD 1,150.00 committed. The flight agent finds a fare change and rebooks for an extra USD 420.00. Within the same minute the hotel agent upgrades a room for USD 390.00. Both read USD 650.00 remaining. Both submit. Both authorize: the tokens are valid, the merchants verified the agents, and neither purchase alone breaks anything the network was told.

At 14:11:00 the table refreshes. The trip is USD 160.00 over policy, and finance finds out at month end.

Then a timeout. The ground-transport agent submits a booking, the merchant is slow, and the agent’s retry logic signs a fresh request and submits again. The first request had gone through. The employee now has two car bookings. TAP did its job: each signed request was fresh. The platform had no record that it had already made this purchase.

Neither failure is Visa’s to catch. Both are race conditions on state only the platform holds.

How to Hold the Platform’s Side

Put the budget check, the reservation and the purchase intent in one transaction, keyed so that a retry finds the first attempt instead of making a second.

on purchase(trip_id, employee_id, agent_id, merchant, amount, intent_key):
  BEGIN
    insert purchase_intents(intent_key, trip_id, agent_id, merchant, amount, 'reserved')
        -- intent_key is unique: a concurrent retry waits here, then conflicts
    if the insert conflicts: ROLLBACK; return the existing intent's result   -- do not buy twice
    reserve amount on trip_budget(trip_id)     where committed + reserved + amount <= cap
    reserve amount on monthly_cap(employee_id) where committed + reserved + amount <= cap
        -- always trip, then employee, so concurrent agents can't deadlock
    if either reservation fails: ROLLBACK; escalate to a human
  COMMIT
  sign the TAP request, submit with the agent's token
  on result: in one transaction, mark intent authorized or declined,
             and move or release the reservation

A retry signed as a new request is a new purchase. A retry that carries the task’s intent key finds the first one.

Derive intent_key from the trip, the item and the agent’s task, not from the attempt, so a retry produces the same key. On the merchant side, a TAP verifier that tracks the idempotency of signatures (a store of the nonces it has already accepted, kept until each signature’s expires time; TAP’s sample verifier reads both from each signature) is what makes “single use” true.

If you run one agent per user with one card and no shared budgets, the consumer-set limits and the issuer’s checks may be all you need. The platform’s ledger matters once several agents spend against the same money.

Where Tacnode Fits

Tacnode holds the agent platform’s decision context: what each agent reads before it submits, and what it records after. Authorization stays with Visa and the issuer, and the token and signature checks stay with the parties the protocols assign them to.

Trip budgets, monthly caps, per-agent limits and purchase intents are state the platform owns. Held in the Tacnode Context Lake™, they are covered by full ACID transactions: two agents cannot both reserve past a trip budget, and a retry with the same intent key finds the first purchase, because each reservation and purchase intent is a committed write. Derived reads such as committed spend per employee this month or declines per merchant this hour are computed on demand against the latest committed data, in the same snapshot as the reservation. Authorization results come back as writes and feed the next decision.

That closes the context gap for one decision: the agent submits knowing what the fleet has already committed. For the same pattern on other rails, see Mastercard Agent Pay, x402 and ACID for agents.

FAQ