Agentic Commerce: When AI Agents Become Cardholders

An AI agent booked a $1,400 flight, reserved a hotel, and expensed both to a corporate card — without a human touching the checkout flow. This is not a speculative scenario. It happened in 2025 at companies running agentic travel management tools, and the payment infrastructure wasn’t ready for it.

Agentic commerce — AI systems autonomously initiating purchases on behalf of users — is colliding with a payments stack built for one assumption: a human is present at checkout. That assumption is wrong now, and it’s about to be wrong at scale.

Agentic vs AI-Assisted Commerce

The distinction matters for how you think about the infrastructure problem.

AI-assisted commerce is what most merchants have already dealt with: autofill, product recommendations, AI-generated checkout copy, fraud signals trained on behavioural data. The human is still present, still approving the transaction. The payment infrastructure is unchanged.

Agentic commerce is categorically different. The AI agent initiates, approves, and completes the transaction. The human has delegated purchasing authority — either broadly (“book the cheapest flight”) or narrowly (“renew my SaaS subscriptions monthly”) — and is not present at the moment of purchase. The card number is in the agent’s context, not in a human hand.

The gap between these two categories is where every interesting problem lives.

What’s Actually Live

Three pieces of infrastructure launched in 2025 that make agentic commerce technically viable at scale:

Visa Intelligent Commerce provides a developer API allowing AI agents to request payment credentials scoped to a specific merchant, amount range, and time window. An agent building a travel itinerary can request a Visa credential authorised for “up to $2,000 at airlines between now and 72 hours from now.” The credential is issued as a virtual card with embedded controls — if the agent tries to use it at a supermarket or for $3,000, the transaction declines by design. Visa also introduced an agent-identity framework allowing merchants to verify that an inbound transaction originates from a known AI agent rather than a human.

Mastercard Agent Pay (announced April 2025) follows a similar delegation model. It uses tokenized payment credentials scoped to an agent session, with spending controls embedded at the token level. Mastercard has partnered with Microsoft, IBM, Stripe, Google, PayPal, and Cloudflare to integrate Agent Pay into agent runtimes (Mastercard, April–October 2025).

OpenAI Instant Checkout is the consumer-facing version of the same idea, launched in late 2025 via the Agentic Commerce Protocol (ACP) co-developed with Stripe (Stripe/OpenAI, October 2025). Users pre-authorise a payment credential (via Stripe or PayPal); AI agents in ChatGPT can then complete purchases at participating merchants without redirecting the user to a checkout page.

Each of these approaches the same problem from a slightly different angle: how do you give an AI agent the ability to pay without giving it unbounded access to a payment credential?

Why 3DS Breaks for Agents

3DS2 is the authentication protocol designed to make card-not-present transactions secure. The logic: when a card is used without a physical terminal present, verify that the person presenting the card is actually the cardholder.

The mechanism relies on three things that AI agents don’t have:

Device fingerprint. 3DS2 collects browser and device data (IP address, screen resolution, browser version, installed fonts, device ID) to assess whether the device is recognisable from prior transactions. An AI agent running server-side has a server IP, not a consumer device. The device fingerprint looks institutional, not personal, and flags elevated risk.

Behavioural signals. 3DS2 collects mouse movement patterns, typing cadence, and session behaviour. Automated agents don’t move mice or type — they make direct API calls. The absence of human behavioural signals pushes the transaction toward a frictionless decline or a challenge.

Challenge completion. When 3DS2 can’t authenticate frictionlessly, it issues a challenge: “enter the OTP sent to your registered mobile number.” An AI agent cannot read a text message. It cannot complete the challenge. The transaction fails.

The liability shift problem compounds this. Under current Visa and Mastercard rules, if a merchant processes a transaction with 3DS2 authentication and the transaction later turns out to be fraudulent, liability shifts to the issuer. Without 3DS2, liability stays with the merchant. Agents that can’t complete 3DS2 put chargeback liability back on the merchant for every agent-initiated transaction.

Some issuer implementations have begun offering frictionless 3DS2 approval for agent-initiated transactions from recognised agent credentials — but this is not universal. Operators cannot assume frictionless auth will apply.

MCC Coding Gets Complicated

When a human books a flight on Expedia, the transaction MCC is 4722 (Travel Agencies). The cardholder’s bank categorises it as travel spend. Corporate card policies recognise it as a reimbursable travel expense. The interchange rate applied is the travel rate.

When an AI agent books the same flight, potentially on the cardholder’s behalf via Expedia’s checkout integration — but routed through the agent platform’s payment infrastructure rather than directly through the merchant — the MCC assignment gets murky.

If the agent processes through its own merchant account, the MCC might be 7372 (Computer Programming, Data Processing) or 5045 (Computers and Peripherals). That’s a different interchange rate. It doesn’t categorise as travel under corporate card policies. The reimbursement process breaks. The cardholder disputes the “computer services” charge not recognising it as a flight booking.

This is not a theoretical edge case — it’s already happening. The fix requires either: the agent routing through the underlying merchant’s acquirer relationship (preserving MCC), or the agent obtaining a travel agency MCC (4722) for their own merchant account. Neither is straightforward operationally.

Authentication Alternatives Being Built

The industry is building around 3DS rather than trying to force it to work for agents:

Delegated authentication. Visa and Mastercard both support delegated authentication — the cardholder authenticates once with their bank, and the authentication credential is then delegated to a trusted party (the AI platform) for a defined period. Subsequent agent-initiated transactions use the delegated credential rather than running 3DS on each transaction. This is the cleanest technical solution but requires the issuer to support delegation.

Scoped virtual cards. The approach used by Visa Intelligent Commerce and Mastercard Agent Pay — generate a virtual card number with embedded controls (merchant, amount, time window). The controls at the token level replace authentication at the transaction level. If the controls are tight enough, the issuer approves without challenge.

API-key-based payment tokens. Some B2B payment platforms are building purpose-built agent payment credentials that look more like API keys than card numbers — machine-to-machine credentials with defined permissions, rate limits, and audit trails. These bypass the card network entirely and use A2A rails, which don’t require 3DS.

What Operators Need to Do Now

If you’re a merchant: Audit whether your checkout flow mandates 3DS universally. If you’re running 3DS on 100% of CNP transactions, agent-initiated traffic will fail or carry elevated challenge rates. Consider whether your payment provider supports agent credentials (Visa Intelligent Commerce, Mastercard Agent Pay) and whether those credentials can be configured for frictionless treatment.

If you’re a PSP or platform: Agent-initiated transactions will look anomalous in your ML fraud models. Server-side IPs, absence of device fingerprints, scripted session behaviour — all of these push fraud scores up. You need a way to identify agent-initiated traffic and apply appropriate model features, not consumer-behaviour features.

If you’re building an AI agent with payment capability: Don’t store raw card credentials in your agent context. Use the scoped delegation frameworks (Visa Intelligent Commerce, Mastercard Agent Pay, or your PSP’s virtual card API). Scoped credentials limit blast radius if the agent is compromised, and the built-in spending controls are the cleanest available approach to the 3DS problem. Clearly disclose to users when an agent has payment authority and what the spend limits are — this is already an expectation from regulators and will become a requirement.

The Liability Question Is Still Open

The most important unresolved issue is chargeback liability for agent-initiated transactions. If a user grants an AI agent payment authority, the agent buys something the user later disputes — who is liable?

The card network rules were not written for this scenario. A chargeback for “unauthorised transaction” typically means the cardholder didn’t authorise it. But if a cardholder authorised an agent to act on their behalf, and the agent made a purchase the cardholder now regrets — is that an unauthorised transaction? The cardholder authorised the agent, not the specific purchase.

Visa and Mastercard are both running working groups on this. The likely resolution: merchants will be required to verify agent credential provenance before processing (to confirm the agent has genuine delegated authority), and liability will sit with whoever issued the agent’s payment credential without appropriate controls. But this is not yet settled policy.

For operators building agentic payment infrastructure in 2025-2026, the practical guidance is: assume merchant liability for agent-initiated transactions that lack verified delegation credentials, and price the risk accordingly.

The Size of This

Payment volume initiated by AI agents is currently a rounding error. Visa predicts millions of consumers will use AI agents to complete purchases by the 2026 holiday season (Visa, January 2026). By 2028, agent-initiated commerce is expected to represent a material portion of CNP transaction growth. The infrastructure is being built now, during the rounding-error phase, specifically because retrofitting it during the material-portion phase will be far more expensive.

Operators who understand the authentication gap, the MCC problem, and the liability uncertainty today are the ones who will have clean implementations when volume scales. Everyone else will be debugging production issues at the worst possible time.