UCP vs ACP vs MCP vs AP2: what should a store actually implement

Documented analysis of UCP, ACP, MCP and AP2: risks, responsibilities, and practical steps for ecommerce that is connected, yet independent.

Published 11 September 202614 minutes

Editorial illustration about UCP, ACP, MCP and AP2 and ecommerce infrastructure control — One channel can accelerate sales without becoming the store’s central system.

Direct answer

A store can gain distribution and lose commercial context at the same time. The topic of UCP, ACP, MCP and AP2 shows exactly where those two effects need to be separated. The concrete risk is that the protocols cover different layers and should not be treated as synonyms. The practical recommendation is simple: start from the business capability and implement only the necessary adapter. That does not require withdrawing from Google. It requires Google to remain a channel connected to a commercial infrastructure that the store can operate without it.

What UCP is and what it does not solve

Universal Commerce Protocol is an open specification for exchanging commercial capabilities between agents, distribution surfaces, merchants, and payment providers. The public documentation describes capability discovery, checkout, and order management. UCP is not, however, a promise of traffic, a guarantee of eligibility, or an automatic transfer of the customer relationship. Technical implementation and access to a Google surface are separate decisions. A Romanian store can study the contract and prepare its architecture even if the commercial product is not available locally. It is precisely this separation that prevents investments made on the basis of a press headline.

Responsibility map

Layer	Control question	Minimum evidence
Catalog	Who defines the product, variant, and availability?	stable ID, version, and readback
Offer	Who calculates the total and commercial rules?	dated snapshot and expiry
Checkout	Where does the customer confirm and what do they see beforehand?	consent tied to the offer
Order	Who accepts, rejects, and reconciles?	idempotency and auditable status
Relationship	Who can serve and win back the customer?	CRM, preferences, and direct channel

In the case of UCP, ACP, MCP and AP2, the table must be completed with system names, owners, and recovery times, not marketing wording.

The catalog must remain the merchant’s source

Agents and feeds need structured data, but the source of truth should not be moved into an export. The internal catalog keeps the product identity, variants, units, restrictions, and packaging rules; the adapter transforms this data for the channel. In the UCP, ACP, MCP and AP2 topic, this discipline makes it possible to stop or replace the integration without rebuilding the business. Validation includes price, currency, availability, taxes, delivery, and expiry. If the feed and the internal system differ, the incident must be detected before a customer or agent creates an order on an impossible offer.

1. Margin lens: the decision for UCP, ACP, MCP and AP2

When we analyze UCP, ACP, MCP and AP2, the question about margin shows whether the advantage remains with the merchant after the session and campaign end. In a workshop, the process owner tests the normal path, then a timeout, a stock discrepancy, and the withdrawal of channel access. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. The exit criterion appears when the protocols cover different layers and should not be treated as synonyms. At that point we do not improvise a migration, but apply the documented decision: start from the business capability and implement only the necessary adapter.

2. Portability lens: the decision for UCP, ACP, MCP and AP2

In the case of UCP, ACP, MCP and AP2, the lack of a definition for portability shifts the discussion toward impressions and hides who bears the exception, loss, or rule change. In the architecture registry, the source, adapter, destination, and available alternative are versioned if the intermediary does not respond. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. Here the risk is concrete: the protocols cover different layers and should not be treated as synonyms. That is why the measure cannot be only the number of orders. We add consent, recovery time, and the percentage of cases resolved without manual export.

3. Identity lens: the decision for UCP, ACP, MCP and AP2

Viewed through the lens of identity, the topic of UCP, ACP, MCP and AP2 is no longer an isolated function, but a decision about how value flows between the store, the customer, and the intermediary. The pilot separately defines the effect on conversion, operational cost, and the ability to resume the direct relationship. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. The commercial consequence of the scenario is that the protocols cover different layers and should not be treated as synonyms. The verifiable answer remains: start from the business capability and implement only the necessary adapter. The acceptance threshold is written before the test, not after the results are known.

4. Consent lens: the decision for UCP, ACP, MCP and AP2

For UCP, ACP, MCP and AP2, consent must be described before integration; otherwise the team will confuse a flow that works with a business it can control. The technical contract isolates mandatory fields, intermediate states, and the evidence used when two systems disagree. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. If we observe that the protocols cover different layers and should not be treated as synonyms, the pilot returns to the direct path. The team must start from the business capability and implement only the necessary adapter, then repeat the test with the same products, markets, and rules.

5. Resilience lens: the decision for UCP, ACP, MCP and AP2

The resilience test starts from the real operation associated with UCP, ACP, MCP and AP2, not from the commercial presentation of the protocol or the platform. The team reconciles the system that produces the information, the event that confirms it, and the person who can correct an error. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. This angle does not prove that the intermediary is useless; it proves that the protocols cover different layers and should not be treated as synonyms. For balance, the recommendation is to start from the business capability and implement only the necessary adapter and to keep the channel only as long as it remains incremental.

6. Continuity lens: the decision for UCP, ACP, MCP and AP2

When we analyze UCP, ACP, MCP and AP2, the question about continuity shows whether the advantage remains with the merchant after the session and campaign end. In a workshop, the process owner measures the normal path, then a timeout, a stock discrepancy, and the withdrawal of channel access. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. The exit criterion appears when the protocols cover different layers and should not be treated as synonyms. At that point we do not improvise a migration, but apply the documented decision: start from the business capability and implement only the necessary adapter.

7. Observability lens: the decision for UCP, ACP, MCP and AP2

In the case of UCP, ACP, MCP and AP2, the lack of a definition for observability shifts the discussion toward impressions and hides who bears the exception, loss, or rule change. In the architecture registry, the source, adapter, destination, and available alternative are compared if the intermediary does not respond. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. Here the risk is concrete: the protocols cover different layers and should not be treated as synonyms. That is why the measure cannot be only the number of orders. We add consent, recovery time, and the percentage of cases resolved without manual export.

8. Attribution lens: the decision for UCP, ACP, MCP and AP2

Viewed through the lens of attribution, the topic of UCP, ACP, MCP and AP2 is no longer an isolated function, but a decision about how value flows between the store, the customer, and the intermediary. The pilot separately documents the effect on conversion, operational cost, and the ability to resume the direct relationship. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. The commercial consequence of the scenario is that the protocols cover different layers and should not be treated as synonyms. The verifiable answer remains: start from the business capability and implement only the necessary adapter. The acceptance threshold is written before the test, not after the results are known.

9. Control lens: the decision for UCP, ACP, MCP and AP2

For UCP, ACP, MCP and AP2, control must be described before integration; otherwise the team will confuse a flow that works with a business it can control. The technical contract tests the mandatory fields, intermediate states, and the evidence used when two systems disagree. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. If we observe that the protocols cover different layers and should not be treated as synonyms, the pilot returns to the direct path. The team must start from the business capability and implement only the necessary adapter, then repeat the test with the same products, markets, and rules.

10. Reconciliation lens: the decision for UCP, ACP, MCP and AP2

The reconciliation test starts from the real operation associated with UCP, ACP, MCP and AP2, not from the commercial presentation of the protocol or the platform. The team versions the system that produces the information, the event that confirms it, and the person who can correct an error. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. This angle does not prove that the intermediary is useless; it proves that the protocols cover different layers and should not be treated as synonyms. For balance, the recommendation is to start from the business capability and implement only the necessary adapter and to keep the channel only as long as it remains incremental.

11. Margin lens: the decision for UCP, ACP, MCP and AP2

When we analyze UCP, ACP, MCP and AP2, the question about margin shows whether the advantage remains with the merchant after the session and campaign end. In a workshop, the process owner separates the normal path, then a timeout, a stock discrepancy, and the withdrawal of channel access. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. The exit criterion appears when the protocols cover different layers and should not be treated as synonyms. At that point we do not improvise a migration, but apply the documented decision: start from the business capability and implement only the necessary adapter.

12. Portability lens: the decision for UCP, ACP, MCP and AP2

In the case of UCP, ACP, MCP and AP2, the lack of a definition for portability shifts the discussion toward impressions and hides who bears the exception, loss, or rule change. In the architecture registry, the source, adapter, destination, and available alternative are isolated if the intermediary does not respond. The owner, verification frequency, minimum data, and what cannot be inferred from the dashboard are noted. A favorable result on one day does not replace cohort testing, and a single incident does not justify removing the channel. Here the risk is concrete: the protocols cover different layers and should not be treated as synonyms. That is why the measure cannot be only the number of orders. We add consent, recovery time, and the percentage of cases resolved without manual export.

Security and access minimization

The adapter does not receive general access just because it is called an "agent". Each operation has a purpose, identity, permissions, expiration, and log. Tokens are limited to the necessary resource and duration, and secrets do not enter feeds, prompts, or logs. For UCP, ACP, MCP and AP2, the threat model includes agent spoofing, replay, price manipulation, stock enumeration, promotion abuse, and data exfiltration. Sensitive actions require confirmation or explicit policies. Anti-bot protection is not disabled globally; legitimate traffic is authenticated and rate-limited on controlled commercial routes.

Four scenarios that should not be confused

The first scenario is discovery: the platform shows the product, and the store keeps the full transaction. The second is contextual redirect, where the cart or selection is transferred, but confirmation remains on the site. The third is embedded checkout, where part of the merchant interface appears on the intermediary’s surface. The fourth is native checkout, where the user completes the purchase without visibly returning to the store. For UCP, ACP, MCP and AP2, each scenario has a different attribution, a different set of errors, and a different level of access to the customer. The team must report them separately. If they are mixed under the label "AI sales", it is no longer possible to tell whether the result comes from recommendation, from discount, from the checkout experience, or from customers who would have bought anyway. The term "direct" is not enough either: direct for the user can mean intermediated for the merchant. The internal documentation will effectively draw the path of data and responsibility, from response to return.

What we measure

The minimum dashboard separates distribution from business health. For distribution: impressions, eligible appearances, sessions, and orders on the channel. For economics: net revenue, margin after discounts and operating cost, cancellations, returns, and support. For relationship: identified customers, valid consents, direct returns, and cohort value. For resilience: percentage of portable catalog, reconciled orders, detection time, and adapter replacement time. In the UCP, ACP, MCP and AP2 topic, a single conversion rate cannot cover all these effects.

Frequently asked questions

What do UCP, ACP, MCP and AP2 actually change?

They change where some commercial decisions are made or executed; they do not automatically move all responsibilities and do not guarantee distribution.

What is the main risk in this case?

The protocols cover different layers and should not be treated as synonyms. The risk is checked in contracts, data, and flows, not assumed from the product name.

Does an open standard eliminate dependency?

Not automatically. The specification can be open while eligibility and the interface remain controlled by a distributor.

Can we prepare the store before eligibility?

Yes: own catalog, deterministic offer, checkout, idempotency, and adapters. Preparation should not be presented as live access.

What decision does the analysis recommend?

To start from the business capability and implement only the necessary adapter, with success and stop thresholds written before the pilot.

Should Google be abandoned?

No. Google can remain a profitable channel; the goal is for it not to become the only commercial infrastructure.

Conclusion

UCP vs ACP vs MCP vs AP2: what should a store actually implement is not an invitation to isolation. It is an invitation to correctly account for control. If the protocols cover different layers and should not be treated as synonyms, the short-term advantage must be compared with portability, the direct relationship, and the exit cost. The healthy decision is to start from the business capability and implement only the necessary adapter. Note the assumptions before the pilot, define the stop thresholds, and repeat the evaluation when countries, interfaces, or contracts change. A good integration should be explainable to the technical team as well as to sales, support, and management. For an audit of visibility and dependencies you can talk to AYSA; for catalog, checkout, CRM, and adapters you can see software development or start a direct discussion.

Sources and verification date

Sources verified on 24 August 2026. Eligibility, countries, and commercial features may change; verification must be repeated before implementation. The analysis separates public documentation from editorial recommendations.