What Rules Let AI Place Orders? Where Things Stand After the W3C Workshop

When AI selects products and proceeds to place orders on a customer’s behalf, connecting to the store and obtaining the customer’s permission to pay need to be considered separately. For managers of ecommerce and booking services in Japan, this distinction helps avoid adoption decisions based solely on claims of support for a new standard.

W3C develops shared rules for web technologies, while GS1 develops shared rules for areas such as product information. At a workshop held by the two organizations on September 8–9, 2026, presentations covered common ordering rules, functions that AI can use within websites, and payment authorization. This article uses a single order example to explain their respective responsibilities and the remaining challenges. Holding the workshop does not mean that a formal W3C standard, known as a “W3C Recommendation,” was adopted.[1][2][3][4]

The references were checked on September 14, 2026. The evidence consists of the workshop agenda and three presentations, not a list of adopted specifications or a post-workshop agreement. We have not verified real-account settings, production connections, or actual orders and payments.

1. Delegating an order involves three roles

The materials are easier to assess in terms of your own responsibilities when divided into three questions: “What is ordered, and how?”, “How are actions carried out on the website?”, and “Whose permission authorizes payment?” None of the presentations says that adopting one mechanism automatically resolves the other two.[2][3][4]

UCP (Universal Commerce Protocol) is a mechanism that lets AI and stores exchange product and checkout information under common rules. WebMCP lets a website provide functions for AI to use within the customer’s current website session. Huawei’s A4P is a proposal for validating payments against conditions authorized by the customer in advance.[2][3][4]

For illustration, consider an instruction to “order one cup of coffee from a specified store for no more than ¥600, including delivery.” The product and amount are illustrative, not results reported in the presentations. This example assumes that a way for AI to discover the store and product, and a connection through which the store receives orders, have been provided separately.

Even if AI can retrieve the store’s price and delivery fee, that alone does not establish permission to pay. And even if AI can change an order, the customer will not know what happened unless the screen they see changes too. Taken together, the presentations suggest that adoption decisions need to consider the screen and authorization, not just whether processing succeeds.[2][3][4]

2. UCP standardizes ordering while preserving differences between stores

Google’s presentation describes UCP as a common foundation for connecting the different systems used by stores and payment providers. The aim is to reduce the work of building a new, partner-specific exchange every time AI connects to another service. It is not designed to force every store to use the same sales process.[2]

This is where “capability discovery” comes in. It means that the store and AI each indicate what they support and check which functions are available. It allows processing to proceed within the supported scope without concealing differences in checkout, delivery, membership benefits and other areas.[2]

In the coffee example, the AI would check the store’s connection information and supported functions, then use the available product information and checkout processes. The store’s role would be to return the information needed for the transaction, such as prices and handover options. However, the slides reviewed here do not establish the actual fields to send or which information is mandatory, so we do not present an executable communication example.

Separate the releases described from the direction of expansion

Google’s materials show expanding functionality through releases in January, April and August. They describe a foundation of checkout, payments and orders extending into product catalogs, carts and membership account linking. The August description also covers functions related to membership benefits and local handover options.[2]

For food ordering and lodging, the materials indicate a direction of expansion into additional sectors. The diagrams show menus and meal ordering for food, and reservations for lodging. But those diagrams alone do not establish that all functions are complete or available to stores and accommodation providers in Japan.[2]

The materials do not include a complete list mapping every function to its development status and the version in which it is available. It is therefore reasonable to say that UCP “is expanding into food and lodging,” but not that “a complete set of functions for booking operations is available.” The appearance of a company’s name is also not evidence of availability across all of that company’s services.[2]

Managers of booking services need to check how far a prospective integration partner supports stay dates, guest numbers, cancellation terms and booking confirmation. These are examples of adoption requirements, not features verified in the materials reviewed here. What matters is not the UCP name itself, but how much of your booking process can be completed from start to finish.

3. WebMCP’s challenge is making AI actions visible to customers

A concrete point in Shopify’s presentation was that AI’s ability to execute a process does not necessarily make it easy for customers to use. With WebMCP, a website exposes functions to AI with defined inputs and outputs. Those functions operate according to information available while the user has the site open and whether the user is logged in. This does not mean that every action requires a login.[3]

MCP is a communication mechanism that connects AI to external functions. The presentation distinguishes connections using UCP and MCP without going through the website interface from the WebMCP route, which uses functions within a page. UCP and WebMCP are not described as simple competing options where choosing one is enough.[3]

In the coffee example, what if AI adds one cup to the cart but the screen still shows an empty cart? The customer might think the addition failed and manually add the same product. This scenario is illustrative, but Shopify did report a problem in which AI updated a cart without changing the screen, preventing the user from taking over.[3]

Shopify describes approaches such as navigating to the relevant page when needed and notifying the screen when the cart changes. These efforts bring human actions and AI actions onto the same processing path. Stores need to reduce not only the time AI spends on actions, but also the effort customers spend checking what has happened.[3]

A reported rollout does not mean everything is settled

Shopify’s materials state that WebMCP has been deployed to Shopify stores. At the same time, they describe its status in Chrome and Edge as an Origin Trial: a trial offering that lets participating sites test a feature. This must not be interpreted as meaning that it works the same way in every environment.[3]

The presentation also identifies challenges caused by page navigation, including the need to register AI-facing functions again and reload the AI’s in-page state. Mechanisms to make that state easier to preserve are under consideration. Shopify also reports a measurement gap: counting actions and recording their timing does not reveal whether users were satisfied.[3]

The presentation further outlines a vision in which a store-side AI and a customer-side AI cooperate. The UCP “ask” function used in that vision is treated as an early-stage exploration of conversational inquiries. A future vision should not be included in adoption requirements as though it were a function ready to connect today.[3]

4. Verify customer payment authorization separately from order processing

Huawei’s proposed TASP is a framework that divides responsibilities across five areas: users, services, payments, identity and credential verification, and operational oversight. It organizes who checks what and who keeps records when AI advances an order across devices. A4P is the component within that framework that handles payment authorization.[4]

Huawei also proposes five levels, P0–P4, for the degree of payment autonomy delegated to AI. The distinction most directly relevant to adoption decisions is between P1, where the customer confirms each payment, and P2, where AI pays within conditions the customer has set in advance. This classification is also Huawei’s proposal, not a shared classification adopted by the workshop as a whole.[4]

Under P1, the customer reviews the order for one cup of coffee, the payee and the total amount, then confirms that payment. Under P2, the customer first authorizes boundaries such as the store, product, amount, time and frequency, and those conditions are checked when the payment is executed. “Choose a recommendation” and “pay without asking the customer again” require different checks from the store and payment provider.[4]

For illustration, suppose the conditions are “specified store, one cup of coffee, no more than ¥600 including delivery, 10 a.m. on weekdays, once per day.” A total of ¥580 meets the amount condition, but the store, time and number of executions that day must also be checked. A total of ¥650 or a second execution on the same day would fall outside the scope of that advance authorization and could not proceed under it.

This is an example created for the article to explain authorization boundaries, not an official TASP data format. The materials reviewed here do not establish the screen or processing details for an out-of-bounds payment, such as whether the customer would be asked to confirm again or the process would stop. Nor does this example suggest that meeting the amount limit alone is enough to proceed.

In the A4P concept, the user reviews the authorization on their device and adds a digital signature, which can be checked for tampering and other issues. The payment-processing system validates the payment against the authorization and the current execution context. Another aim is to retain evidence that allows the sequence of events to be traced later.[4]

The materials distinguish implementation descriptions relating to P1, including Huawei Pay, from P2 advance-authorization scenarios. The latter cannot be read as evidence of production use. A4P is also not the same as Google’s AP2; the materials list them as separate mechanisms.[4]

5. A shared standard name does not establish interoperability

One unresolved issue in these materials is whether systems from multiple companies can process transactions using the same meanings and conditions when connected. This is called interoperability. Similar order formats do not necessarily mean that customer authorization or screen state will also match.[3][4]

Shopify explains that its AI-facing functions broadly follow UCP but differ in some respects because complex actions confused AI models. Huawei proposes a framework for sharing the meanings of terms, mappings between systems and verifiable evidence across different ordering and payment mechanisms. Neither presentation reports that all connection gaps have already been resolved.[3][4]

In the coffee example, the first requirement is for each system to interpret “order one cup” consistently. In addition, the total including delivery must match the authorization, the order result must be visible to the customer, and the process must stop if it falls outside the authorization. An adoption requirement is to separate the responsibilities of each mechanism, then connect and verify this entire sequence.

6. What should your business wait for, and what can it assess now?

You do not have to choose between waiting for every standard to be complete and rolling everything out immediately. These materials allow you to separate a narrowly scoped assessment from decisions that still involve unresolved issues. However, the four documents do not establish eligibility for use in Japan or the terms under which these mechanisms would be provided in your own environment.[1][2][3][4]

If your goal is to help customers select products or manage a cart, the main question is whether customers can check the results of AI actions and take over manually. If you want AI to proceed through ordering and payment without asking the customer each time, additional issues include the scope of advance authorization, tracking execution counts, stopping actions outside that scope and keeping a record of events. For areas such as lodging, separately check whether the functions required for that sector are available in the version being considered.

To revisit the evidence, use the workshop agenda to check speakers and presentation titles. Consult Google’s presentation slides for UCP expansion, Shopify’s presentation slides for challenges in keeping the screen in sync, and Huawei’s presentation slides for the customer-authorization proposal. None of these is an application form.[1][2][3][4]

Your adoption decision can rest on three points rather than the single word “supported”: which orders can be handled, when the customer confirms, and what results the customer can see. The value of these workshop materials is that they help distinguish where implementations exist across those three points and where trials or proposals remain.