ACP vs. UCP vs. Visa Intelligent Commerce: Agentic Commerce Protocols Explained

ACP, UCP, and Visa Intelligent Commerce are not competing versions of the same thing. ACP and UCP are merchant-side commerce protocols that define how an agent discovers products and places an order, Visa Intelligent Commerce is a card network framework for agent-initiated payment credentials, and Web Bot Auth is the identity layer that lets a merchant verify which agent is knocking. Lane works across all four.

Lane is the payment infrastructure that lets AI agents transact with any merchant: agents integrate once and can order food, shop online, and book travel and reservations on a user's behalf, with the user's own card and explicit approval. That includes merchants that have adopted one of these protocols and merchants that have adopted none of them.

Why are there several agentic commerce protocols at once?

Because agent commerce broke in several places simultaneously, and different parties own different pieces of the break. Understanding the stack makes the apparent protocol war look much more like division of labor.

• Merchants had no agent-readable interface. Storefronts were built for humans with browsers. Checkout flows assume human data entry, so someone had to define a structured way for software to browse and order. That is what ACP and UCP address.
• Networks had no way to mark agent-initiated payments. Card messages assumed an attended human. Visa Intelligent Commerce exists so an agent-initiated transaction can be presented as exactly that instead of as unattributed card-not-present traffic.
• Nobody could tell which agent was calling. Merchants and CDNs saw anonymous automated requests and blocked them. Web Bot Auth gives an agent a cryptographic identity, which is a prerequisite for any of the layers above it to be trusted.
• The ecosystems have different centers of gravity. A protocol authored inside the OpenAI ecosystem and one authored inside the Google and Shopify ecosystem will reflect those distribution realities, which is why two merchant-side specs exist rather than one.

What is the Agentic Commerce Protocol (ACP)?

The Agentic Commerce Protocol is a merchant-side specification associated with OpenAI and Stripe. It defines how an agent can retrieve a merchant's product information and drive a checkout through structured endpoints instead of by operating a human interface.

• Who runs it. OpenAI and Stripe, with Stripe supplying payment rails on the merchant side. Its natural home is the OpenAI and ChatGPT ecosystem, which is also its largest distribution advantage.
• What it covers. Agent-driven merchant checkout: catalog exposure, cart and order construction, and completing a purchase through a defined interface rather than a rendered page.
• Strongest where. Merchants that want to be purchasable from inside ChatGPT and are comfortable with the merchant-of-record dynamics and payment relationships that come with the Stripe side of the stack.
• Honest limitation. ACP is a merchant-side protocol with an ecosystem attached. It is not an embedded white-label wallet for third-party agent platforms, so a builder shipping its own consumer agent still has to solve consent, credentials, and coverage on its own.

What is the Universal Commerce Protocol (UCP)?

The Universal Commerce Protocol is the merchant-side specification associated with Google and Shopify. Like ACP, it aims to make commerce agent-accessible through structured interfaces rather than through pages designed for people.

• Who runs it. Google and Shopify, which pairs a search and assistant distribution surface with a very large installed base of merchants on a single commerce platform.
• What it covers. Agent-accessible catalog and commerce operations, with the practical benefit that platform-level adoption can enable many merchants at once rather than one integration at a time.
• Strongest where. Merchants already on a platform that adopts it, and agent experiences that live close to Google's surfaces. Platform-mediated adoption is the fastest way to move a large number of stores.
• Honest limitation. Adoption still depends on the merchant and the platform enabling it, and a second merchant-side protocol means agent builders now have two specifications to track rather than one.

What is Visa Intelligent Commerce (VIC)?

Visa Intelligent Commerce is a card network framework, not a merchant API. It addresses how a payment credential works when an agent is initiating the transaction on a person's behalf, which is a different question from how the agent found the product.

• Who runs it. Visa, as the network. Participation runs through Visa's programs, including certification for enablers.
• What it covers. Agent-initiated payment credentials: how an agentic transaction is represented to the network, how tokens are requested, and how the agent-on-behalf-of-a-human relationship is expressed rather than hidden.
• Why it is complementary. A merchant-side protocol still needs a payment to clear. Network-level agentic credentials are what let that payment be authorized on better information than an anonymous card-not-present charge.
• Lane's standing. Lane is a certified Visa Intelligent Commerce enabler and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. Lane builds on VIC rather than competing with it.

Visa's Trusted Agent Protocol is a companion to Visa Intelligent Commerce: the credential framework says how to pay, the registry says who is knocking.

Where does Web Bot Auth fit?

Web Bot Auth is the identity layer beneath the commerce protocols. It uses HTTP Message Signatures, standardized as RFC 9421, plus a key directory so an agent signs each request with a private key and publishes the corresponding public key where a merchant or CDN can check it.

It matters because the default outcome for an anonymous agent is a block. Bot detection at the CDN layer, from providers such as Cloudflare, Akamai, and DataDome, cannot distinguish a legitimate agent acting for a real customer from abusive automation unless the agent can prove who it is. Lane's executor signs its requests with an Ed25519 key, publishes a self-hosted key directory, and passed Cloudflare's Web Bot Auth crawl verification.

How do ACP, UCP, VIC, and Web Bot Auth compare?

Where do the protocols overlap, and where are the real gaps?

ACP and UCP genuinely overlap: both are merchant-side commerce interfaces, and a merchant adopting one is solving roughly the same problem it would solve by adopting the other. VIC and Web Bot Auth do not overlap with either, because they answer different questions.

• Gap one: merchants that adopted nothing. The largest gap is the simplest. If a merchant supports no agentic protocol, no amount of specification support helps an agent buy from it. This is the execution gap.
• Gap two: consent. None of the merchant-side protocols define how a specific human approves a specific basket in a builder's own app, with a record that survives into a dispute. That is a wallet and consent problem, not a catalog problem.
• Gap three: who bears the payments burden. A protocol does not give an agent builder a card vault, network standing, or a PCI program. Those remain required to actually move money.
• Gap four: cross-protocol translation. A builder that wants to work everywhere ends up supporting several specifications with different shapes, plus a fallback for everything outside them. That work does not disappear because the specs exist.

What do these protocols mean for a merchant?

For a merchant, the protocols are a distribution question. Adopting an agent-readable interface makes the store purchasable inside assistants, and the choice usually follows whatever platform the merchant is already on.

1. 1

   Start with your platform. If your commerce platform supports a protocol, adoption is mostly configuration. Platform-mediated support is the cheapest path to being agent-purchasable.

2. 2

   Decide your bot policy deliberately. Blanket blocking of automated traffic also blocks legitimate agents buying on behalf of real customers. Verifiable agent identity is what makes a selective policy possible.

3. 3

   Understand the payment relationship. Different protocols come with different assumptions about who the merchant of record is and which rails the payment runs on. That is a commercial decision, not only a technical one.

4. 4

   Expect to support more than one. There is no sign of consolidation to a single merchant-side protocol, so the realistic plan is coverage across whichever surfaces send you demand.

What do they mean for an agent builder?

For an agent builder the calculus is different, and less comfortable. A merchant only has to serve the agents that come to it. A builder has to buy from whichever merchant the user names, which means protocol support alone is never sufficient.

• Users name merchants, not protocols. A user asking for dinner from a specific restaurant or a specific product does not know or care which specification that merchant implements. An agent that can only transact at adopting merchants fails most requests.
• You still need a wallet and consent. Reading a catalog is not paying. Approvals, tokenized cards, and an authorization record are separate infrastructure, and they are what users and issuers actually respond to.
• You still need to be allowed in. Verifiable agent identity determines whether requests are served at all. Being a known, cryptographically verified agent is upstream of every commerce protocol.
• Multiplying integrations is the trap. Supporting several specs plus a fallback, per merchant category, is how a small team accidentally becomes a payments and integrations company.

Where does Lane fit across ACP, UCP, and VIC?

Lane is deliberately protocol-agnostic. The bet is that no single standard wins outright soon, so the useful position is translation plus execution rather than allegiance.

• Lane translates across protocols. Lane supports ACP and UCP on the merchant side, so a builder integrates Lane once instead of implementing each specification and tracking its revisions.
• Lane builds on the network layer. Lane is a certified Visa Intelligent Commerce enabler, and Mastercard Agent Pay support is in progress as Lane expands across Visa and Mastercard rails.
• Lane implements verifiable identity. Lane operates as a known, cryptographically verified agent under Web Bot Auth and is registered in Visa's Trusted Agent Protocol registry alongside Cloudflare. Platforms that integrate Lane inherit that identity.
• Lane fills the execution gap. When a merchant supports none of the protocols, Lane still completes the purchase against that merchant, which is the case that covers most of the commerce users actually ask for.
• Lane owns the consent layer. A user prompt becomes a structured, line-item purchase contract the user approves natively with a biometric or passkey, and the agent cannot buy outside the approved terms.

Protocols pave part of the road for the web's newest users. Something still has to drive the rest of it.

How much of commerce do these protocols actually cover today?

Lane's view, based on what Lane sees in production traffic, is that protocol coverage remains a small slice of the commerce agents get asked to perform. Lane's data suggests a handful of merchants, including DoorDash, Amazon, Uber Eats, and Uber, drive roughly 99% of agentic commerce demand, and merchant protocol adoption does not line up neatly with that concentration.

The lesson Lane draws is not that the protocols are unimportant. It is that a builder cannot ship a product whose coverage is defined by a specification adoption curve. The requirement is a path that works at the merchants users already use, today, with protocol support as an optimization where it exists rather than a precondition.

How should a builder choose?

1. 1

   Start from your users' merchants. List the merchants your users will actually name. Check how many support any agentic protocol. That number is usually the end of the pure-protocol strategy.

2. 2

   Separate the layers before evaluating. Catalog and ordering, payment credential, agent identity, and user consent are four different problems. A vendor or spec that solves one is not a substitute for the others.

3. 3

   Prefer translation over allegiance. Betting on one merchant-side protocol ties your coverage to someone else's adoption. Translating across them keeps that risk off your roadmap.

4. 4

   Insist on a consent record. Whatever you choose, make sure a specific human approval is bound to a specific purchase and carried to the card networks, so disputes work through the user's bank as normal.

ACP and UCP are how merchants become readable to agents, Visa Intelligent Commerce is how agent payments become legible to the networks, and Web Bot Auth is how an agent proves it is itself. The gap none of them closes is the merchant that has adopted nothing, which is still most of them, and closing that gap is the reason Lane exists.