Agentic Commerce: When the Customer at Checkout Is an AI Agent
AI agents that search, compare and buy on a person's behalf are moving from demos to early products. Payments infrastructure was not built for a buyer that is software, and the industry is racing to adapt.
3
Questions every agent-initiated payment must answer: who authorized it, within what limits, and who is liable
1 : 1
Emerging design pattern: one scoped payment credential per agent mandate (illustrative)
0
Stored card numbers an agent needs to hold when tokenized, scoped credentials are used
For as long as online commerce has existed, the thing on the other side of a checkout page has been a person, or a bot pretending to be one. Fraud systems, authentication flows and dispute rules are built on that assumption. A human clicks buy; a human can be challenged with a one-time code; a human can later say, "I did not authorize this."
AI agents break the assumption. An agent asked to "book the cheapest refundable flight to Lisbon next Thursday" or "reorder printer toner when it runs low" may search, compare and complete the purchase without the person seeing a checkout page at all. Through 2025 and into 2026, card networks, payment processors and technology companies announced programs, specifications and protocols for exactly this scenario. The details differ, but the problems they are trying to solve are consistent.
Problem one: proving authorization
Today, a checkout proves authorization implicitly: the cardholder was present, entered details and perhaps passed a 3-D Secure challenge. When an agent pays, the merchant and issuer need a different kind of evidence, namely that a real person delegated this purchase to this agent, within defined limits.
The emerging answer is the mandate: a signed, machine-readable record of what the user authorized, such as a merchant category, a maximum amount, a time window or a specific item. The user approves the mandate once, using strong authentication such as a passkey, and the agent presents it at checkout. If the purchase falls outside the mandate, it should fail.
Problem two: credentials that agents can hold safely
Handing an agent a raw card number is a poor idea. Card numbers are reusable, broadly valid and valuable to thieves. The industry is converging instead on tokenized, scoped credentials: a network token or virtual card tied to a specific agent, and often to a specific mandate or merchant, with limits enforced by the issuer.
The safest agent is one that never sees a real card number, only a credential that is useless outside the task it was given.
This approach reuses infrastructure the industry already has. Network tokenization, domain restrictions and dynamic cryptograms were built for device wallets and card-on-file merchants. Extending them to agents is more an exercise in policy and identity than new cryptography.
Problem three: knowing which agents to trust
Merchants have spent years blocking bots. Now some bots are customers. Distinguishing a legitimate shopping agent acting for a verified user from a scraper or a credential-stuffing script requires agent identity: a way for an agent to present signed credentials identifying its operator, and for merchants and networks to recognize registered agents.
Expect this to look like the web's certificate infrastructure more than like a login. Agents present verifiable credentials; merchants check them against registries maintained by networks or other trusted parties; anonymous automation continues to be treated as risk.
Problem four: disputes and liability
The hardest questions are legal and commercial. If an agent buys the wrong item, is that a merchant error, an agent error or an unauthorized transaction? Existing card dispute categories were written for humans. Consumer-protection rules generally still apply, but mapping agent behavior onto them is unsettled.
Mandates help. A signed record of what the user authorized, and what the agent actually did, gives all parties evidence to work with. But the industry will need clearer rules, and probably new dispute reason codes, as volumes grow.
What merchants can do now
- Make product data machine-readable: accurate prices, stock, shipping options and policies in structured form, so agents can compare without scraping.
- Review bot-management rules so that registered agents presenting credentials are not blocked by default.
- Support tokenized credentials and passkey-based authentication, which serve human buyers and agents alike.
- Log the evidence: keep records of mandates and agent credentials presented with each order.
A measured outlook
Agentic commerce attracts a great deal of hype, and the volumes today are small. Most people are not yet ready to let software spend their money unsupervised, and early use cases, such as reordering, travel booking and subscription management, are narrow. But the infrastructure being laid now, including scoped credentials, mandates and agent identity, will determine whether the transition is safe. The payments industry has a rare chance to design for a new kind of customer before it arrives at scale rather than after the fraud does.
Found this useful? Pass it on.
Companies working on this
Ferrous Pay
Full-stack acquiring with network tokens and 3DS2 on by default.
Loomcart
A composable checkout that adapts payment methods to every buyer.
Brightwater Orchestration
Payment orchestration with smart retries and vaulted multi-acquirer routing.
Read next
Network Tokens and Passkeys: The Pincer Movement on Card-Not-Present Fraud