Agent Commerce Protocols Explained: ACP, UCP, AP2, MCP, A2A, TAP for DTC Operators

Agent Commerce · Protocols

Six protocols are competing to define how AI agents transact with merchants. Most operators do not need to read the specs. Most operators do need to know which one to act on this quarter, which to watch, and which to ignore until further notice. The brands that get the prioritization right ship one Stripe configuration change and move on. The brands that get it wrong sink a quarter of engineering time into a spec that is either two years from adoption or solving a problem the merchant does not own.

This post is the operator's map. Six protocols, three priority buckets: act now, watch, skip. The depth weighting matches the priority: one protocol gets the bulk of this post because it is the one that asks a DTC team for actual work in 2026. The other five each get a section that explains what the protocol is, who owns it, and the one sentence of operator-side action it asks for, if any.

The six-protocol map at a glance

Each protocol solves a different layer of the same problem: how does an autonomous agent transact with a merchant it has never seen before, without that merchant building a one-off integration per agent vendor.

The six agent-commerce protocols

Six specs, six sponsors, three action tiers. Only one of them asks a DTC operator for real work in 2026.

ACP

Act now

Agent Commerce Protocol

Lets ChatGPT and other agents understand and act on commerce intent against a merchant catalog.

Sponsor: OpenAI

UCP

Watch

Universal Commerce Protocol

Google's commerce intent layer, scoped to Shopping-side surfaces. Merchant onboarding has not shipped publicly.

Sponsor: Google

AP2

Watch

Agent Payments Protocol

Cryptographically signed mandates that let an agent authorize a payment on a buyer's behalf.

Sponsor: Google

MCP

Skip

Model Context Protocol

Standard interface for AI models to fetch context from external systems. Developer infrastructure.

Sponsor: Anthropic

A2A

Skip

Agent-to-Agent

Lets agents from different vendors discover and coordinate. Almost no DTC surface area.

Sponsor: Google

TAP

Skip

Tokenized Asset Protocol

Visa-level payment-rails primitive for tokenized agent transactions. Your payment processor handles this.

Sponsor: Visa

ACP: the only protocol you act on this quarter

Agent Commerce Protocol is OpenAI's framework for how AI agents express, negotiate, and execute commerce intent against a merchant. It is the layer that turns a conversational request inside ChatGPT ("find me running shoes under $150 with at least 4.5 stars and free return shipping") into a structured, machine-readable transaction against a real merchant catalog. ACP is the protocol that decides whether an agent can actually buy from you, not just see that you exist.

The reason ACP is the act-now protocol for DTC operators is the implementation channel. OpenAI built the spec, but the merchant-side integration ships through Stripe for the majority of DTC stacks. Stripe is rolling out ACP-format product feed support to merchants in tranches; some accounts have it today, others are queued. The work on the operator side is configuration, not engineering: connect your product feed, set the constraints (return policies, shipping windows, inventory thresholds), and confirm the feed validates against the ACP schema Stripe exposes in your dashboard.

The cost of being late on this is concrete and asymmetric. Brands with ACP-formatted feeds surface inside ChatGPT's transactional flows with structured pricing, real-time inventory, and accurate fulfillment information. Brands without ACP show up as web-scraped guesses. When an agent surfaces three competitors against the same query and one is ACP-formatted, the agent has higher confidence in the ACP-formatted result, which weights it higher in recommendation ranking and reduces the friction at the buy step. The brands going first are not paying for an experimental feature; they are paying for the recommendation slot.

The operator move in 2026 is concrete. If you are on Stripe, open your dashboard and search for agent commerce or ACP. If the surface is live in your account, walk through the setup wizard: connect the product catalog, validate the feed shape, set the return and shipping policy fields, confirm the test flow processes a sample agent transaction. If the surface is not live in your account, message your Stripe account manager (or post in the Stripe support channel if you are self-serve) asking for ACP feed access. Both paths are first-week work, not first-quarter.

Three details are worth getting right inside the ACP feed itself. First, return policy precision. Vague policies ("30-day returns may apply") perform worse in agent surfaces than precise ones ("free returns within 30 days, prepaid label included"). The agent surfaces what the feed declares; ambiguity in the feed translates directly to less confident recommendations. Second, GTIN and brand fields. Same issue as covered in the OAI-SearchBot post for visibility: the agent disambiguates your SKU from a competitor's using these fields. Third, real-time inventory. Static inventory snapshots that lag your actual stock level lead to recommendations against out-of-stock items, which is the worst failure mode in agent commerce because it kills buyer trust in the entire surface.

ACP is also the protocol where the math from the cost piece matters most. Paid OpenAI Ads bidding lives downstream of ACP support: if your feed is in ACP format, the paid bid can include the structured fields the auction wants; if your feed is not in ACP format, the auction is operating on incomplete information about your product, which changes both your eligibility and your conversion downstream of the click. Two operators bidding the same CPC with the same AOV will see different effective CACs purely because the ACP-formatted brand converts more of the agent traffic that reaches the page.

UCP and AP2: the watch list, until Google Shopping ships

Universal Commerce Protocol and Agent Payments Protocol are Google's two specs covering the same surface ACP covers, scoped to Google's own agent and Shopping ecosystems. UCP is the intent layer (what the agent wants); AP2 is the payment authorization layer (how the agent pays). Both are public specs. Neither has a merchant onboarding surface for DTC operators that is generally available as of 2026.

The right operator stance on both is to watch, not build. The reason is rollout sequencing. Google ships merchant-facing surfaces through Google Shopping, Google Merchant Center, and the broader Search advertising stack. The protocol-layer announcements have landed; the merchant-facing onboarding has not. Building your own UCP intake or AP2 verification before Google ships the integration path means picking the wrong implementation surface and rewriting it when the official one lands. The cost of waiting is roughly zero because Google's agent commerce surface area today is small relative to ChatGPT's; the cost of being wrong is the rewrite plus the operational debt of running a deprecated integration.

The operator move is calendar-based, not engineering-based. Add a quarterly check to your roadmap meetings: is there a Google Shopping or Merchant Center surface for UCP feed support yet, is there an AP2 dashboard toggle in any of your payment processors yet. When either lands, the work pattern will look like the Stripe ACP setup: configuration, not engineering. Until then, the work is exactly zero, which is the right amount of work to do on a protocol with no merchant-facing surface.

MCP, A2A, TAP: the skip list (with one nuance each)

Three protocols sit in the skip column for DTC operators in 2026. Each one has a single nuance that explains why it is skip-able even though it is real and active.

MCP is Model Context Protocol, Anthropic's open-source standard for how AI models fetch context from external systems. It is genuinely important infrastructure. Claude, ChatGPT, Gemini, and most agent frameworks have implemented MCP support. But MCP is developer infrastructure, not merchant infrastructure. You ship an MCP server if you are building your own AI agent that needs to read context from external tools. You do not ship an MCP server to make your store visible to ChatGPT, because ChatGPT does not buy from your store via your MCP server. It buys via ACP. MCP is critical for the agent vendors and the agent builders; for a DTC merchant whose job is to sell shoes, it is in someone else's stack.

A2A is Agent-to-Agent, Google's open-source protocol for letting agents from different vendors discover, authenticate, and coordinate across a buying flow. The canonical use case is multi-agent commerce: a buyer's personal agent talking to a merchant's customer-service agent talking to a fulfillment agent. The reason it is skip-tier for DTC merchants today is that the multi-agent flows are concentrated in B2B procurement, insurance, real estate, and other high-touch verticals. Consumer DTC commerce is overwhelmingly single-agent: a ChatGPT agent finds the product, ChatGPT processes the transaction via ACP, the merchant fulfills. There is no second agent in the loop for sub-$200 AOV consumer goods. Skip A2A unless you are building agentic tools yourself, in which case you already know.

TAP is Tokenized Asset Protocol, the Visa-led primitive for tokenized agent-driven payments on the card-network rails. It solves how Visa's network handles transactions where the cardholder is not the one initiating the charge (the agent is, on the cardholder's behalf, with cryptographically attested authorization). For a DTC merchant, TAP is invisible. Your payment processor (Stripe, Adyen, Braintree, or your successor) handles the network-side compliance for you. The same processor that absorbs Visa's other tokenization standards absorbs TAP. The only operator question worth tracking is whether your processor publishes a roadmap update saying TAP support is live, which is a calendar check, not an engineering task.

The DTC priority matrix

Six protocols, six rows. One action column, one why column. The matrix is the screenshot the founder takes back to the team.

What to do in the next 30, 90, and 365 days

The same six-protocol map translates into a concrete operator timeline.

1. Next 30 days: log into Stripe, find the agent commerce or ACP surface, enable the feed if available. If unavailable, file the access request and move on. Validate that your product feed has precise return policies, GTINs where you can ship them, and a real-time inventory hook rather than a static snapshot. Run a sample agent transaction through the test mode and confirm the buy flow completes.
2. Next 90 days: add quarterly calendar checks for two specific milestones. (a) Has Google shipped a UCP merchant onboarding surface in Google Shopping or Merchant Center yet. (b) Has your payment processor (Stripe, Adyen, Braintree, or whoever) published an AP2 support announcement yet. Both are config-not-engineering when they land, so the check is reading a changelog rather than evaluating a build.
3. Next 365 days: revisit the matrix at the protocol level once per year. Two things tend to change on this timeline. New protocols emerge (the 2026 list is six; the 2027 list will be either six or seven or eight). Existing protocols consolidate or fragment further (ACP could become the unambiguous winner across vendors, or it could fork). The annual revisit catches both shifts without consuming attention in between.

Six protocols, one action. The discipline this post asks for is the discipline of not implementing the other five. Most engineering hours spent on agent-commerce protocols in 2026 by DTC operators will be spent on protocols that did not need their attention. The brands that recognize ACP as the only one worth touching this quarter, and treat the rest as calendar items rather than engineering work, will be the ones who actually capture agent-driven revenue without burning a quarter of build time getting there. If you want this stack tracked continuously rather than as a quarterly check, the OpenAI Ads page shows what Cresva agents do here, and you can try Cresva free.