Agentic Commerce Protocols: Cut Through the Acronym Noise (MCP, A2A, ACP, UCP & AP2)

Ask anyone in tech how to prepare your store for AI shoppers, and you will get hit with a wall of capital letters: MCP, A2A, ACP, UCP, AP2. Add a messy architectural diagram full of random arrows, and it is easy to leave the room feeling like you have a massive new integration backlog without any idea of what your actual customers will experience.

Here is the truth: these acronyms matter, but they do not solve the same problems. Hooking up an AI to your stock database is completely different from getting two agents to talk to each other. Building a seamless checkout flow is nothing like proving a shopper actually authorized a payment.

Before you commit developer hours to any protocol, you need to answer two basic questions: What should the buyer be allowed to do? And where does the merchant stay in total control?

Let us break down what these protocols actually do, how they work together, and how to build a smart strategy without getting lost in vendor fluff.

What Are the Main Protocols in Agentic Commerce?

MCP connects AI applications to tools and context. A2A supports communication between agent systems. ACP and UCP define commerce-related interactions. AP2 provides verifiable authorization evidence for agent-performed payments. These responsibilities can complement one another, but implementing one does not automatically supply the capabilities of the others.

Each protocol handles a distinct layer of the AI shopping stack:

Think of this as a functional map, not a rigid setup guide. You do not need to check every box to get started, and picking one protocol does not automatically handle the job of the others.

Whenever you are evaluating solutions, keep three separate questions in mind: What does the spec define? What has a given vendor actually built? And is that feature available in your target market today?

MCP: a connection to tools, not a complete shop

The Model Context Protocol specification gives AI apps a standardized way to read external data and trigger actions. Through MCP, servers can expose tools, prompts, and resources with built-in HTTP authentication options.

For e-commerce, an MCP tool might pull item dimensions, double-check stock for a specific size, or calculate live shipping rates. But MCP just handles the connection; it does not define business rules or decide who gets access to what.

You have to build those guardrails yourself. A basic lookup tool like "check availability" should never trigger a purchase. A public catalog tool shouldn't expose order details. And your backend needs to validate prices independently rather than assuming a formatted tool call equals permission to buy.

Bottom line: MCP gives an AI permission to call an API, not permission to make a commercial deal on your behalf.

Real-World Examples: How Alhena Uses MCP

To see how direction matters, look at how MCP works across two different integrations:

External MCP Integration: Through Alhena's external MCP integration, teams connect outside servers and assign specific tools directly to internal Alhena agents. Here, Alhena is consuming tools provided by third-party platforms.

Alhena Headless: On the flip side, Alhena Headless lets your internal team connect LLMs like Claude or ChatGPT straight into your Alhena workspace via MCP, pulling analytics and customer intelligence under strictly audited enterprise controls.

Neither approach turns your checkout into an open playground for random consumer bots. Giving internal teams access to customer insights is fundamentally different from letting a customer's personal bot read private order logs.

Always look at the tool being exposed, who is calling it, and what scope they have. Saying "we have an MCP server" is step one not the whole strategy.

A2A: Multi-Agent Collaboration

The Agent2Agent specification sets up rules for agent discovery, task handoffs, and messaging. It lets entirely separate AI systems talk to each other without needing matching codebase foundations.

Imagine a shopper trying to track down a replacement part for an old dishwasher. The buyer's bot comes in with a part number, dimensions, and a hard deadline. Your store's agent checks fitment, asks for the appliance serial number, queries inventory, and sends back a verified match.

That is a multi-step conversation. It takes back-and-forth dialogue to resolve.

However, A2A is not a pricing engine. Your business rules—like bulk discounts, regional shipping constraints, and promo code validations—must live in your core store logic. Smooth bot messaging won't make a bad price quote right.

Keep in mind that an Agent Card simply lists capabilities and access rules; it isn't an all-access pass. The A2A standard keeps discovery separate from authentication and data permissions. A bot declaring what it can do doesn't mean it gets to read your customer database.

If you are just serving product availability requests, a clean REST API or MCP setup is usually far easier than spinning up full agent-to-agent negotiations.

Note: Do not confuse the general concept of agent-to-agent commerce (bots interacting during a buying journey) with A2A (the specific open specification). They are not the same thing.

ACP: Structuring Commerce Workflows Across Platforms

The Agentic Commerce Protocol (ACP) standardizes programmatic buying flows between shoppers, AI intermediaries, and online stores. OpenAI provides detailed documentation covering both product-feed guidelines and its Agentic Checkout Spec.

ACP is much broader than a single checkout widget or launch event.

In its March 2026 product discovery update, OpenAI expanded ACP's reach around feeds and sales promotions, placing extra focus on merchant-owned checkout paths alongside early native checkout tests.

Merchant onboarding usually starts with structured catalog synchronization. The checkout spec outlines eligibility requirements for native buying flows. An open protocol standard and guaranteed distribution inside ChatGPT are two very different things.

When someone tells you a tool is "ACP compatible", dig deeper: What specific workflow are we enabling?

Are you syncing inventory feeds? Enabling AI product discovery? Preparing cart payloads? Managing checkout sessions? Or handing users back to your hosted store? Always verify exact platform availability before building.

Pay attention to commercial terms, too. Clarify transaction fees with your platform partner rather than assuming fee percentages are baked into the protocol standard itself.

Make sure you know who owns the order record, payment processing, fulfilment, and customer support. Technical compatibility will never replace clear operational contracts.

UCP: A Universal Framework for Commerce Capabilities

The Universal Commerce Protocol (UCP) gives merchants a uniform way to advertise capabilities, align API versions, and handle transactions. Its core framework includes identity and payment modules rather than treating every transaction like a basic web request.

A quick note on "capability negotiation": this means two technical systems agreeing on supported API features. It does not mean buyer and seller bots are haggling over price tags.

Google’s March 2026 UCP update added optional capabilities for Cart, Catalog, and Identity Linking. That word optional is crucial: simply adopting UCP does not automatically enable every feature in the spec.

A complete implementation strategy should explicitly cover protocol versions, capabilities, transport protocols, auth mechanisms, and payment fallbacks when a partner lacks a feature.

UCP Readiness ≠ Automatic Google Checkout Access

Google’s official Merchant Center documentation outlines access rules for its UCP-driven checkout. Native checkout availability remains restricted to approved merchants and eligible products in select regions.

The takeaway: Supporting an open protocol standard is not an automatic ticket into every commercial surface using that standard.

Take a look at Shopify’s commerce agent tools for a practical reference. Shopify pairs UCP features with MCP tools across discovery, cart creation, and order tracking, keeping merchant web handoffs and direct checkout completions on distinct permission tiers.

If you work with Alhena, its UCP onboarding process evaluates UCP compatibility separately from ACP requirements. Treat these as distinct integration paths, not identical capabilities.

AP2: Cryptographic Proof for AI Payments

The Agent Payments Protocol (AP2) specification (v0.2) introduces explicit Checkout Mandates and Payment Mandates to create verifiable audit trails for agent-assisted purchases across direct and autonomous modes.

A checkout mandate verifies what is being bought, while a payment mandate locks down payment processing details. AP2 delivers signed proof of authorization; it doesn't replace your cart or inventory system.

The business question is simple: What cryptographically proves that a customer authorized this specific payment?

Say a customer tells their bot to order a replacement filter capped at $80, as long as it arrives by Friday. Staying under $80 doesn't justify sending an incompatible filter, nor does a late Monday delivery meet their requirements. AP2 mandate structures allow these conditions to be verified explicitly before funds move.

A cryptographic signature cannot fix a broken product description or out-of-stock inventory. Always validate offer details before processing authorization signatures.

AP2 distinguishes between real-time user authorization (direct flow) and pre-approved autonomous agent execution (autonomous flow). Verification logic should live in strict, deterministic code, never left to an LLM's interpretation.

Verify support across your payment gateway, processor, and AI agent platforms before roll-out. Signed mandates give clear audit trails, but they don't erase basic merchant dispute responsibilities.

Tokenization, Credentials and Payment Authorization

A secure payment flow has several responsibilities: protect sensitive account information, check purchasing authority and carry out processing through the appropriate systems.

Tokenization replaces sensitive card details with a substitute value. In a tokenized flow, a payment token can be used in place of the raw account number, helping reduce exposure of valuable financial data. Its restrictions depend on the implementation. EMVCo’s explanation describes how this supports payment security.

A legitimate credential still needs to be used within its permitted scope. Your implementation must connect the action, amount and relevant conditions to the customer’s authorization before processing payment for that transaction.

For a practical example, Stripe’s published implementation describes Shared Payment Tokens and support for network-led capabilities from Visa and Mastercard. This is provider-specific infrastructure; confirm the supported configuration for your store and channel.

Ask your payment provider how it handles credential scope, consent, expiration and fraud checks. A payment processor may process payments using the supplied payment method, while another component supplies or checks the authorization evidence.

Treat these as separate implementation questions. A protocol name alone is insufficient evidence that every part of the flow works together.

How the Protocol Layers Fit Together

Here is how a complete agentic commerce architecture looks in practice:

A shopper asks their AI assistant to find a carry-on bag within a specific budget, color preference, and delivery window. The assistant pulls catalog info, resolves variant specifics, and requests a live quote. Your store backend verifies inventory, pricing, delivery estimates, and return terms.

Next, a supported commerce interface prepares the checkout payload. The buyer approves the summary (or an authorization engine checks an existing mandate), the payment gateway processes the charge, and your system returns a confirmed order payload with tracking data.

In this architecture:

MCP exposes data lookup tools.

A2A manages multi-agent subtasks.

ACP or UCP structures cart and checkout payloads.

AP2 supplies signed payment authorization proof.

You do not need all five protocols to run an effective agentic shopping experience. Google’s UCP technical overview outlines options for integrating via standard REST APIs, MCP tools, or A2A messaging. Choose the leanest stack that gets the job done.

Focus on clear operational ownership over collecting every protocol acronym.

Map Protocols to Your Customer Journey

Build your tech stack around actual user touchpoints, starting with minimum required access permissions:

1. Product Discovery: Structured & Reliable Data

Focus on clean variant data, stable SKU identifiers, accurate stock statuses, and compatible feed specifications. Review OpenAI’s product-feed best practices to ensure your feed passes platform checks.

Test thoroughly: Can an AI agent clearly identify variant differences and key purchasing constraints?

2. Cart Handoff: Lossless Handoffs

Ensure your cart links carry over exact size, color, quantity, market settings, and applied promos. Make sure shoppers don't have to manually re-select options when handed off to your store.

Track referral traffic performance separately from cart completion metrics to catch drop-off points.

3. Direct Purchase: Validation & Idempotency

Implement strict identity verification, transaction checks, and idempotent API logic so network retries never lead to duplicate credit card charges.

OpenAI’s Agentic Checkout Spec mandates strict authentication, input validation, and safe retry handling. Enforce these safety measures at the code level.

4. Post-Purchase: Scoped Support Access

Define clear boundaries for post-purchase APIs. Checking tracking info requires a very different permission level than approving order cancellations or issuing refunds.

Always keep an immediate human escalation route available when authorization or user intent is unclear.

Read Alhena’s agentic commerce guide for strategic advice on structuring your overall AI commerce operations.

Essential Questions to Ask Vendors

Ask vendors to demonstrate the complete workflow using your own product data. A useful evaluation should cover:

• Implemented capabilities: Which versions, extensions and operations are supported in production?
• Channel access: Is the feature generally available, in a limited rollout or dependent on partner approval?
• Commercial decisions: Which system calculates tax, discounts, delivery eligibility and the final amount?
• Access controls: Where are permissions checked, and what happens when a caller lacks authority?
• Payment arrangements: Which component checks delegated approval, and which provider handles processing?
• Failure recovery: How are duplicate requests, price changes, declined charges and unsupported features handled?
• Operational ownership: Who handles disputes, refunds, customer support and liability under the applicable agreements?

Run live edge-case testing: Use real store catalog data to test edge cases like sold-out options, sudden price updates, or unsupported shipping addresses. Returning an HTTP 200 status code doesn't prove an AI shopping task succeeded.

Test key boundary protections: Which system handles tax and final price calculations? Where are permission rules checked? How are duplicate network requests blocked? Where are payment audit logs stored? What fallback UI appears when a bot fails?

Establish legal and operational ownership for merchant-of-record status, payment disputes, and customer support responsibilities upfront.

Maintain a centralized log tracking supported protocol versions, API capabilities, validation logs, and maintenance owners so team handoffs and protocol updates run smoothly.

Evaluate new spec updates against actual customer friction points before adding them to your development roadmap.

What Ecommerce Teams Actually Need

Start with a customer task you can define and measure. Choose the minimum set of capabilities required to complete it accurately, with clear authority and a reliable recovery path.

Build on the infrastructure you already use for product information, orders, customer service and secure payments. Add an interoperable interface where it removes a specific limitation.

The goal is a shopping experience people can trust: the right product, the correct terms, a deliberate approval and a clear answer when something goes wrong.

Keep the Customer Experience in View

The technical choices matter because they shape what customers experience. Alhena’s Masters of CX series explores the operational decisions behind customer support, shopping assistance and AI adoption. Bring that same focus to this work: define the experience first, then select the capabilities needed to deliver it.

Frequently Asked Questions

Is MCP an e-commerce checkout protocol?

No. MCP connects AI applications to data sources and tools. A tool can execute a shopping action, but your backend server still needs to enforce business logic, security permissions, and transaction rules.

Are MCP and A2A competing standards?

No, they handle different integration jobs. MCP connects apps to local or remote tools and context, while A2A coordinates messaging between distinct AI agents. Systems can use both together, or rely on just one depending on complexity.

Are ACP and UCP interchangeable?

No. They have different specs, capability models, and integration requirements. Supporting ACP does not give you UCP compatibility. Evaluate your target channel to see which standard it requires.

Does supporting UCP automatically feature my store in Google Checkout?

No. Adopting the UCP specification is separate from participating in Google’s hosted checkout experience. Review Merchant Center guidelines for current regional and product eligibility requirements.

Does UCP require both MCP and A2A to function?

No. UCP supports multiple transport pathways, including direct REST APIs. Use whichever transport mechanisms fit your infrastructure best.

Is ACP only used for checkout flows?

No. OpenAI updated ACP to cover product feeds, discovery features, and promotions alongside its checkout specs. Check official documentation for current integration guidelines.

Does Alhena Headless grant external agents access to private customer data?

No. Alhena Headless provides secure, authenticated access to your Alhena workspace for internal team LLM clients under strict enterprise permissions. It does not open up public data access for external consumer bots.

Which protocol should an e-commerce brand implement first?

Start with your immediate business needs, primary sales channels, and native e-commerce platform capabilities. Adopt the minimum protocol setup required to deliver a safe, seamless customer experience.