Shopify in Depth

1. Executive Snapshot

Shopify has a business model that is relatively easy to explain. Understanding what that model means for a larger retail organisation requires considerably more care.

The company provides a largely standardised commerce infrastructure as Software as a Service. Merchants can operate their product catalogue, storefront, basket, checkout, payments and orders within a common platform. Additional capabilities extend this foundation into international commerce, B2B, physical retail and automation.

Standardisation is the principal advantage. Businesses do not have to develop, operate and maintain much of the underlying commerce infrastructure themselves. In return, Shopify retains control over the core platform and determines where and how merchants can extend it.

That arrangement can remove a substantial amount of technical responsibility. It can also introduce integration complexity when important business processes fall outside the platform's intended operating model.

Shopify Plus extends particular capabilities and technical limits without changing the underlying SaaS architecture.

B2B is no longer exclusive to Plus either. Company structures, customer-specific catalogues, payment terms and self-service ordering are available across several standard plans, although catalogue allocation, advanced payment functionality and customisation rights continue to differ.

In omnichannel retail, Shopify connects online commerce and physical stores through a shared platform model. POS, inventory locations and order management provide a useful foundation for cross-channel operations. They do not, by themselves, provide complete orchestration across complex store networks, multiple ERP environments or legally independent trading entities.

Agentic commerce adds another dimension.

During 2026, Shopify has been extending access to product information and commerce functions for external AI agents. Shopify Catalog, the Universal Commerce Protocol, several MCP interfaces and Agentic Storefronts provide different ways for agents to discover products, prepare baskets and participate in purchasing processes.

The Shopify Agentic Plan is particularly interesting. Under defined conditions, merchants can use Shopify as additional agentic commerce infrastructure without migrating their existing online shop to Shopify.

Shopify's Fall ’26 Edition adds another dimension to this development. With Shop.dev, Shop.md and a multi-merchant Universal Checkout, Shopify is increasingly positioning its infrastructure to support purchasing journeys that begin outside individual merchant storefronts and may involve several retailers. This changes the available integration models without transferring the underlying merchants' operational responsibilities to a single platform.

This creates three distinct strategic possibilities.

A business may use Shopify as its principal commerce platform. It may introduce selected Shopify capabilities alongside an existing architecture. Or it may retain a different commerce platform and evaluate new distribution channels independently.

The right choice cannot be established simply by counting available features.

It depends on how closely the organisation's actual commercial processes fit Shopify's standard model, which systems must remain responsible for decisions outside that model, and whether the resulting dependencies are manageable.

2. Market Position and Suitable Operating Models

Company size tells only part of the story

Shopify has long been associated with direct-to-consumer brands, conventional online shops and commerce operations that can be implemented without extensive bespoke development.

That remains an important part of its proposition, but it no longer describes the full scope of the platform.

Shopify now supports a wider range of retail models, including B2B commerce, international brand operations and transactions in physical stores. This makes it relevant to businesses that would previously have regarded the platform primarily as a solution for smaller or less complex online operations.

Yet revenue, headcount and transaction volume are unreliable substitutes for an assessment of business requirements.

A large international retailer may operate highly standardised pricing, ordering and fulfilment processes. A much smaller manufacturer or wholesaler may manage individual contracts, several purchasing organisations and complex approval procedures.

The second business could place greater demands on the commerce architecture despite having substantially lower sales.

Shopify deserves serious consideration when an organisation can align important commercial processes with an established platform standard.

In those circumstances, the ability to avoid operating and maintaining numerous individual commerce components can be valuable.

The assessment becomes more involved when the business depends on highly specialised pricing, contractual purchasing arrangements or bespoke order orchestration.

These requirements do not necessarily rule Shopify out.

They do, however, change the architecture. Some responsibilities may remain with ERP, OMS, pricing engines or specialised procurement systems, while Shopify provides the customer-facing commerce processes.

The quality of that arrangement depends on whether responsibilities are clearly defined and the integrations work reliably.

Standardisation is a commercial decision

Platform selection is often presented as a technology exercise. In practice, it also determines which processes an organisation is prepared to standardise.

Shopify makes this trade-off particularly visible.

Its platform provides established functionality and defined extension mechanisms while retaining control over the underlying commerce core.

For many organisations, that is a sensible arrangement. There is little commercial merit in recreating established functionality merely to preserve the ability to modify every detail.

Some requirements described as distinctive are simply the legacy of earlier systems or organisational decisions that no longer serve the business particularly well.

Others represent genuine competitive advantages or obligations arising from contracts, regulation and operational dependencies.

A sound platform decision must distinguish between them.

The relevant question is not how much customisation Shopify theoretically permits.

It is which aspects of the business genuinely require customisation, how those requirements can be implemented, and whether the resulting cost and responsibility remain proportionate to their commercial value.

3. Platform Architecture and Operating Model

A centrally operated commerce core

Shopify is built around a vendor-operated SaaS architecture.

The company develops and operates the central commerce platform, its principal infrastructure services and the mechanisms through which merchants access and extend its functionality.

Merchants interact with the platform through administration interfaces, storefronts, APIs and supported extension points.

This removes the need to manage substantial parts of the underlying infrastructure.

Routine platform maintenance, core developments and many operational responsibilities remain with Shopify rather than the merchant or its implementation partner.

The arrangement also introduces clear boundaries.

Businesses cannot alter the commerce core at will. Bespoke applications must work within Shopify's supported interfaces, security requirements and extension mechanisms.

That dependence is not inherently a disadvantage. It is part of the operating model and should be assessed accordingly.

The relevant issue is whether the benefits of a standardised environment outweigh the limitations imposed on business-specific processes.

Themes, Liquid and custom storefronts

Shopify's conventional storefront model uses themes built with Liquid.

This allows merchants to manage presentation, content and many common storefront interactions while retaining a close connection to the underlying commerce services.

For businesses whose customer experience fits the model, themes can avoid much of the development and operational responsibility associated with a completely separate frontend.

More demanding requirements can be addressed through APIs and headless architectures.

A custom frontend provides greater freedom over presentation, interactions and integration with other digital services. Commerce functionality remains accessible through Shopify's supported interfaces.

Shopify provides Hydrogen and Oxygen as part of this approach.

With Hydrogen 2026-10, made generally available on 14 October 2026, Shopify repositioned Hydrogen as a framework-agnostic JavaScript library, allowing developers to integrate its commerce capabilities into different JavaScript application architectures.

The documented approach supports integration with different JavaScript frameworks, including React Router and Next.js.

Hydrogen should therefore no longer be described solely as a fixed React storefront framework.

Oxygen remains relevant as Shopify's hosting option for suitable storefront architectures.

This development gives engineering teams additional flexibility, particularly where a business already operates a preferred frontend stack.

It does not remove the boundaries of Shopify's commerce core.

A custom storefront can change how customers interact with commerce functions. It cannot freely redefine every underlying pricing, checkout or order-processing rule.

It also creates responsibilities for frontend development, testing, monitoring and ongoing maintenance.

Headless commerce should therefore be a response to specific requirements rather than an architectural ambition in its own right.

APIs and extension mechanisms

Shopify offers several mechanisms for integrating systems and extending supported functionality.

The GraphQL Admin API enables administrative operations and data integration. The Storefront API supports custom customer-facing applications.

Shopify Functions provides defined extension points for certain commerce rules. Checkout Extensibility supports modifications to specific parts of the checkout experience. Shopify Flow enables event-driven and rule-based automation.

Metafields and Metaobjects extend the available data structures. Webhooks and other integration mechanisms allow connected systems to respond to relevant events.

These are substantial capabilities.

They should not be confused with unrestricted control over the platform's business logic.

For example, storing a contractual attribute in a Metafield does not mean that Shopify will automatically enforce all the contractual rules associated with it.

An appropriate component must interpret the information and apply the required decision.

The same distinction applies to integrations.

An ERP system may remain responsible for contractual pricing. An OMS may calculate available inventory or determine which fulfilment location should handle an order.

Shopify can participate in these processes without necessarily being the authority that makes the underlying business decision.

A robust architecture must distinguish between information stored in a system, available technical extension points and rules that are actually enforced.

The Fall ’26 Edition also introduces additional capabilities for coordinating and scheduling changes across several commerce components. Shopify describes the combined preparation of updates affecting themes, catalogues, discounts and checkout. This can simplify operational coordination, but it does not replace release governance across external systems, integrations or legally independent trading entities.

Checkout Extensibility and Shopify Plus

Checkout provides a useful illustration of Shopify's approach to customisation.

The platform supports a range of extensions through applications and defined interfaces. Availability depends on the plan and the type of extension involved.

Certain public Shopify Functions and extensions for customer accounts, thank-you pages and order-status pages are available without Shopify Plus.

More extensive UI customisation of the information, shipping and payment stages of checkout requires Plus. Certain bespoke Shopify Functions also carry additional plan restrictions.

It would therefore be inaccurate to describe Shopify checkout as generally impossible to customise.

It would be equally misleading to suggest that Shopify Plus allows unrestricted modification of every checkout process.

Merchants with unusual payment requirements, order validations, delivery calculations or regulatory obligations must examine the relevant extension points individually.

They should also establish whether those extensions behave consistently across the purchasing channels they intend to support.

This becomes particularly important when transactions are initiated or completed through agentic commerce interfaces rather than the conventional storefront.

API limits and version management

The existence of an API does not establish that every integration workload can use it without restriction.

Shopify applies cost-based rate limits to the GraphQL Admin API, with different capacities depending on the merchant's plan.

These limits can matter when synchronising substantial catalogues, updating inventory frequently or operating integrations across several business systems.

Shopify also uses a managed API versioning model.

As at the research cut-off, 2026-10 is the current stable API version. Shopify publishes stable versions regularly and generally supports them for at least twelve months.

Businesses therefore need disciplined version management.

Integrations require monitoring, appropriate error handling, controlled retries and regular testing against supported API versions.

Shopify's SaaS model reduces the responsibility for operating the core platform. It does not eliminate responsibility for the reliability of systems built around it.

The app ecosystem

Shopify's app ecosystem is a central part of its extension model.

Merchants can introduce additional functionality without building every capability themselves.

For common requirements, an established application may be substantially more economical than bespoke development.

The decision should nevertheless extend beyond whether an app exists.

Long-term suitability depends on maintainability, data access, security, support responsibilities and compatibility with future platform changes.

In larger organisations, multiple applications can become a significant architecture of their own.

Several systems may modify the same products, prices or orders. Their processes may overlap, and changes to one application may affect others.

Clear ownership of data and business rules is therefore essential.

The app ecosystem expands Shopify's capabilities considerably. It does not replace architectural governance.

4. Core Commerce and B2B

Standardised B2C commerce

Shopify brings the principal elements of online retail into a common platform model.

Products and variants, catalogues, pricing, discounts, customer accounts, baskets, checkout, payments, orders and fulfilment can be managed through connected commerce services.

For many B2C merchants, this reduces the need to assemble basic commerce operations from independently developed components.

The benefits are clearest when products, pricing and fulfilment fit reasonably well within the intended standard processes.

Other business models introduce additional demands.

A merchant may require complex product configuration, unusual promotional combinations, subscriptions or customer-specific pricing.

Another may operate several catalogue systems and rely on external services to determine commercial availability.

In these circumstances, it is necessary to establish what Shopify handles natively, which extensions are available and where another system must remain responsible.

The ability to store relevant data is not equivalent to the ability to execute the associated business process.

B2B across Basic, Grow, Advanced and Plus

Shopify's native B2B capabilities have expanded substantially.

B2B functionality is now available across Basic, Grow, Advanced and Shopify Plus.

The supported model includes Companies, Company Locations, customer-specific catalogues, quantity rules, payment terms, self-service ordering and automation capabilities.

There are important prerequisites.

B2B catalogue functionality on Basic, Grow and Advanced requires the newer Shopify Markets model.

Native B2B also relies on Shopify's current customer-account architecture. Legacy customer accounts do not support the relevant B2B model.

These conditions matter particularly for merchants evaluating an existing Shopify installation rather than introducing the platform from the beginning.

Plan differences remain significant.

Basic, Grow and Advanced permit a total of three active B2B market catalogues. Shopify Plus supports an unlimited number of these catalogues and allows direct catalogue assignment to individual companies or company locations.

Certain additional payment capabilities, including deposits, partial payments and payment requests per fulfilment, are also restricted to Plus.

Contextual storefront and checkout customisation through Markets is documented for Advanced and Plus.

The decision to adopt Shopify Plus can therefore no longer be justified simply by a general requirement for native B2B.

It should be linked to particular catalogue structures, payment arrangements, customisation requirements and operating limits.

Companies, locations and purchasing permissions

Shopify organises B2B customers through Companies and Company Locations.

This supports the management of business customers, their locations and relevant commercial settings.

Documented permissions include location-level administrative and ordering roles.

Those capabilities should not be mistaken for a complete procurement and approval system.

A larger B2B organisation may require several approval levels, purchasing budgets, project-based procurement or complex contractual controls.

Location-level permissions do not automatically reproduce those processes.

Additional automation, applications, bespoke integrations or external procurement systems may be necessary.

The question of authority is particularly important.

If an ERP system controls contractual terms, credit limits and commercial approval, Shopify should not inadvertently become a second, conflicting source of decisions.

An integration architecture must define which rules Shopify enforces and which decisions are supplied authoritatively by other systems.

Combined B2B and B2C operations

Shopify supports both dedicated B2B stores and combined B2B/B2C arrangements.

A shared shop may simplify product and content management. The customer groups can nevertheless have very different pricing, catalogue and payment requirements.

The suitability of a combined model depends on the extent of those differences.

Where B2B and B2C share much of their product and fulfilment structure, a common shop can be appropriate.

Where legal, commercial and operational requirements diverge significantly, separate structures or additional systems may be more practical.

Documented functional exclusions also matter.

Shopify B2B currently does not support Agentic Storefronts, accelerated checkout methods including Shop Pay, or certain subscription capabilities.

Specific local delivery and pickup arrangements have additional limitations.

A new Shopify capability available to consumer commerce should therefore not be assumed to be available to B2B customers under the same conditions.

Assessing Shopify for B2B

Shopify is relevant to a broader range of B2B models than older product classifications would suggest.

Its native company structures, catalogues and payment terms can provide a useful basis for business customer portals and comparatively standardised ordering processes.

For more complicated purchasing organisations, suitability depends increasingly on the wider systems architecture.

A business may use Shopify as the customer interface while contractual rules, pricing and order approvals remain within ERP or procurement applications.

This can be a sensible arrangement when responsibilities are clear and the connections operate reliably.

A different assessment is required if Shopify is expected to replace an established, highly specialised procurement platform in its entirety.

The issue is not whether Shopify supports B2B.

It is which elements of a particular B2B operation the platform should own, and whether the resulting architecture can support the complete business process.

5. Internationalisation and Multi-Store Operations

International markets within one commerce model

International retail often requires different languages, currencies, assortments, prices and payment methods.

Shopify Markets provides mechanisms for managing such differences within supported shop structures.

For businesses operating a largely consistent commercial model, this can simplify international expansion.

Not every additional country needs a separate commerce installation.

The distinction becomes important when a market is also an independent trading organisation.

A local subsidiary may have its own invoicing entity, tax obligations, payment relationships or operational responsibilities.

These requirements can extend well beyond localisation.

Businesses must establish whether their international differences concern presentation and commercial terms or require genuinely separate operational structures.

The available Markets functionality should then be assessed against the relevant plan, target market and business model.

Expansion Stores and Shopify Plus

Shopify Plus provides an organisational structure for managing multiple shops.

The standard contractual arrangement includes one primary shop and up to nine Expansion Stores. Additional eligibility and contractual conditions apply to particular configurations.

Expansion Stores can support separate market operations or storefronts within an organisation.

They do not automatically share a single underlying data set.

Products, collections, inventory, configurations and many settings remain specific to each shop. Synchronisation must be arranged where necessary.

Applications can also generate additional charges for individual shops.

This matters for international retail groups.

Central organisational administration may reduce certain management tasks, but it is not equivalent to central product information management, a single inventory authority or a group-wide customer identity.

Where those capabilities are required, the architecture may need additional systems and integration processes.

Global and local responsibility for data

Larger retail organisations frequently distribute responsibility for product information, pricing and inventory across different business systems.

A PIM may manage global product data. Regional teams may determine assortments. ERP or OMS applications may control commercial availability.

A Shopify implementation must reflect these responsibilities.

Multiple shops introduce further questions.

Which product attributes are centrally controlled? Which markets may change their local assortments? How are regional prices maintained? Which system resolves inconsistent inventory information?

The number of available shops does not answer these questions.

They arise from the actual operating model of the business.

International organisations should therefore define their legal, commercial and operational responsibilities before choosing between Markets, additional shops and external systems.

6. Unified Commerce

Bringing online and physical retail together

Shopify connects online commerce and physical stores through Shopify POS and shared commerce functionality.

In supported configurations, products, inventory, locations, customers and orders can be managed within the same platform.

For retailers with a common operational structure, this can simplify the relationship between digital and physical sales channels.

It may reduce the need to integrate independent commerce and point-of-sale systems for every transaction.

There are still important differences between Shopify POS and POS Pro.

The available functionality, payment methods, hardware and certain operating capabilities depend on the relevant plan and region.

Introducing Shopify POS does not by itself demonstrate complete integration of all cross-channel processes.

Inventory and order routing

Shopify supports location-based inventory and mechanisms for directing orders to fulfilment locations.

This may provide an adequate foundation for businesses with relatively straightforward store and warehouse arrangements.

Larger networks introduce more demanding requirements.

An item physically present in a store may not be available to every sales channel. It may already be reserved, allocated to another order or excluded from online fulfilment for operational reasons.

Where several warehouse management systems, ERP environments or store organisations are involved, responsibility for calculating sellable inventory must be established explicitly.

Order routing can also require more than assigning an order to a location.

Orders may need to be split between warehouses. Stores may have different fulfilment capacities. Certain products may require special handling or delivery arrangements.

An external OMS may therefore be appropriate.

Shopify can remain responsible for the customer-facing transaction while the OMS manages the more complex operational decisions.

Click and Collect and Ship-from-Store

Local pickup and shipping from stores are among the most commercially relevant connections between online and physical retail.

Offering a pickup option in checkout is only the beginning of the process.

Availability must be accurate, inventory must be reserved appropriately and store staff need a reliable way to prepare and hand over the order.

Ship-from-Store introduces additional decisions concerning location selection, store capacity and carrier integration.

Shopify provides native functionality and extension options for these processes.

Whether they are sufficient depends on the retailer's operating model and the systems already in use.

For larger organisations, the assessment should follow the entire journey from availability calculation through reservation, fulfilment and customer handover.

Returns across channels

Returns are a useful test of how closely retail channels actually operate together.

A customer may purchase online and return an item to a store.

The retailer must connect the original order, payment, product condition and inventory movement.

Shopify supports returns and exchanges through POS.

However, return rules are not enforced identically in every configuration.

Shopify documents that centrally defined return rules apply at POS Pro locations. Authorised staff may override certain restrictions, while some elements, including return-shipping and restocking fees, are handled differently from online self-service returns.

This illustrates the distinction between shared commerce data and identical process enforcement across channels.

The important question is whether the retailer's intended returns policy can be implemented consistently throughout the organisation.

Customer identity, loyalty and CRM

A coherent view of the customer is another important element of unified commerce.

Shopify can connect customer information and transactions within its supported commerce structures.

For retailers with a relatively consistent customer model, that may provide an adequate operational foundation.

Larger businesses often work with additional CRM systems, loyalty platforms, historical customer databases and separate store records.

A consistent enterprise-wide customer view then requires more than synchronising customer records.

The organisation needs to determine which identity is authoritative, how duplicate identities are resolved and which permissions govern the use of customer information.

Dedicated customer-data, identity or CRM systems may be appropriate.

This should not automatically be interpreted as a shortcoming in Shopify.

It is a question of enterprise architecture and data governance.

The Fall ’26 Edition extends the connection between digital and physical retail. The announced and newly introduced capabilities include customer-authorised recognition of existing customer profiles in stores and the ability to continue supported online baskets within POS.

These functions can improve continuity between channels. Their practical value nevertheless depends on customer consent, the available POS configuration and the connected inventory, CRM and order-management systems. Shared customer recognition or the transfer of a basket does not, by itself, demonstrate fully integrated enterprise-wide unified commerce.

Assessing actual omnichannel maturity

Shopify provides a genuinely connected foundation for several important retail processes.

Where sales, inventory and fulfilment follow a consistent operating model, its shared commerce infrastructure can reduce integration complexity.

The picture becomes more demanding as additional legal entities, inventory systems, store organisations and customer structures are introduced.

The most useful assessment therefore follows actual end-to-end processes.

Using Shopify Online Store and Shopify POS is an important starting point. It does not establish that every relevant price, inventory position, return or customer interaction is consistently managed across the business.

7. Agentic Commerce

7.1 From product discovery to purchase

Traditional online commerce usually begins with a customer visiting a merchant's storefront.

The customer searches, compares products, selects variants and completes a transaction through the merchant's interface.

AI agents can now participate in parts of that process.

They may search for products, compare specifications, select variants, prepare baskets and, under defined conditions, interact with checkout.

Those activities are not equivalent.

A recommendation does not constitute an order. A prepared basket is not a completed transaction. A technically executable checkout does not automatically give an agent authority to make purchasing decisions.

Shopify has developed several components to support these different activities.

They are not a single, interchangeable agentic commerce interface.

The architecture combines catalogue access, shopping tools, checkout capabilities and browser-based interaction.

For merchants, the relevant decision begins with the customer process they intend to support.

The technical integration should follow from that requirement, rather than from the availability of a particular protocol.

7.2 Shopify Catalog

Shopify Catalog provides structured access to product information for external applications and AI agents.

The developer documentation distinguishes between Global Catalog and Storefront Catalog.

Global Catalog supports product discovery across multiple Shopify merchants.

Storefront Catalog is intended for discovery within a particular merchant's catalogue.

Both implement the UCP Catalog capability, but differ in scope, available functions and data context.

Global Catalog may be appropriate when an agent is comparing products from several merchants.

Storefront Catalog is the more relevant approach when an agent is assisting a customer within a specific shop.

These interfaces allow merchants' product information to participate in new forms of customer interaction.

They do not guarantee visibility in any particular AI application.

A merchant may be eligible for a distribution channel without its products being selected for a specific customer query.

Product-data quality therefore remains important.

Descriptions, variants, availability and other structured attributes need to be reliable and sufficiently detailed for the intended purchasing process.

Good product data is a prerequisite for useful agent interaction. It is not evidence that a channel will produce additional traffic or sales.

Those outcomes require measurement.

7.3 UCP, MCP and WebMCP

Shopify's agentic commerce architecture uses several technical standards.

The Universal Commerce Protocol, or UCP, defines commerce capabilities and the structures needed to coordinate supported activities.

The Model Context Protocol, or MCP, provides a mechanism through which AI agents can access structured tools.

The two approaches can work together.

UCP may describe a commerce capability, while an MCP interface makes that capability available to an agent as a tool.

WebMCP operates differently.

It exposes supported tools within a website or browser session, allowing an agent to interact with the customer's current storefront or checkout context.

Shopify supports several implementations of these approaches.

Global Catalog MCP and Storefront Catalog MCP support product discovery. Cart MCP manages baskets. Checkout MCP supports server-side checkout sessions. WebMCP exposes particular functions within the browser environment.

The former Storefront MCP has been superseded by the newer UCP-based interfaces and should not be treated as an additional, unchanged integration option.

The choice of interface depends on the process.

A merchant-specific shopping assistant has different requirements from an agent searching across multiple retailers.

A server-side agent initiating checkout also has different responsibilities from a browser agent assisting a customer already using a storefront.

These differences matter more than a general claim that a platform supports MCP.

7.4 Baskets and checkout

Shopify distinguishes exploratory basket activity from the actual checkout process.

Cart MCP implements the UCP Cart capability.

An agent can assemble products, change quantities and obtain provisional totals without necessarily requiring an authenticated buyer.

A checkout is needed when the customer intends to proceed with a purchase.

Checkout MCP creates and manages checkout sessions. It requires appropriate authentication or signed requests and applies stricter processing and usage limits than Cart MCP.

The interface supports creating, updating, retrieving, completing and cancelling checkout sessions.

Under documented conditions, complete_checkout can technically complete a purchase through the API, including creation of the order.

This capability should not be confused with its availability in every access model.

Where further buyer input or review is required, the agent hands the customer over to the merchant checkout through the continue_url. Eligible API-based integrations may complete the transaction directly once the necessary authorisation and checkout conditions have been satisfied.

Checkout states are important.

incomplete indicates that necessary information is missing.

requires_escalation identifies a need for additional action or intervention.

ready_for_complete means that the checkout is technically prepared for completion.

Only completed confirms a successfully created order.

Shopify also provides mechanisms for safely retrying certain completion requests, reducing the risk of duplicate transactions caused by technical retries.

For merchants, the distinction is straightforward.

Shopify documents ways of completing a checkout programmatically. The authority of an agent to use those capabilities in a particular purchase still depends on the buyer's consent, payment authorisation and the relevant integration permissions.

7.5 WebMCP within the customer's browser session

WebMCP is intended for agents operating within the active storefront or checkout session of a customer.

Shopify introduced corresponding tools for Liquid storefronts in August 2026, alongside an initial developer-preview approach for Hydrogen.

Additional checkout tools followed in September.

A browser agent can use supported tools to retrieve product information, interact with the basket and perform certain checkout actions.

With Checkout WebMCP, the agent works with the checkout already open in the customer's browser.

This differs from Checkout MCP, where a server-side integration manages its own checkout session.

Checkout WebMCP can retrieve checkout information, update supported fields and complete an eligible prepared transaction.

The scope is not unrestricted.

Shopify documents exclusions affecting B2B checkouts, embedded checkout arrangements, draft orders, certain traditional multi-page checkout configurations and other special cases.

Not every interaction introduced by a checkout app is accessible through the WebMCP tools.

Where further action is required, such as payment confirmation or interaction with an unsupported extension, control must return to the customer.

Browser and agent support also remains limited.

Shopify now provides WebMCP tools for supported Liquid and Hydrogen storefronts and selected checkout processes. The availability of these Shopify capabilities must nevertheless be distinguished from support in individual browsers and AI agents. Documented restrictions affecting particular checkout types also remain relevant. Universal agent support should not be inferred.

It would therefore be premature to describe these capabilities as universally available to browser agents.

7.6 Shop MCP

On 13 October 2026, Shopify introduced Shop MCP as an additional shopping interface for external agents.

Shop MCP combines product search, product information, basket functionality and Shop Pay-related purchasing processes through a single MCP connection.

Searching Shopify Catalog through this interface does not require a separate API key.

Personalised functionality and purchase completion remain subject to the appropriate user and payment processes.

Cart creation and checkout can operate without Shop sign-in. Access to saved customer details and Shop Pay requires the shopper to sign in, while completing a purchase remains subject to confirmation of the total and payment method.

Shop MCP is not simply another name for Catalog MCP.

The catalogue interfaces focus primarily on product discovery.

Shop MCP brings several stages of shopping together within a broader integration.

There is also an operational limitation that matters to developers.

At launch, Shopify did not provide checkout-completion webhooks for Shop MCP.

Integrations must therefore use appropriate status queries and state checks to establish the outcome of a transaction.

This affects monitoring, reconciliation and failure handling.

It also illustrates why the availability of a new shopping interface should not be mistaken for a complete operational commerce architecture.

7.7 Shop.dev, Shop.md and Universal Checkout

Shopify's Fall ’26 Edition extends access to its shopping infrastructure for external applications and AI agents.

Shop.dev provides a developer-oriented entry point to selected capabilities for product discovery, identity, baskets, checkout and Shop Pay. Shop.md complements this with a machine-readable description that enables suitable AI agents to discover and use the supported shopping functions.

These components should not be treated as separate, independent commerce platforms. They make the underlying Shopify services more accessible to external applications.

A further development is Shopify's Universal Checkout, designed to bring products from different merchants into a shared purchasing experience. The participating merchants retain their respective orders and applicable commercial rules.

A shared checkout experience does not mean that all downstream operations become unified. Fulfilment, returns, customer service, payment reconciliation and the legal responsibilities of individual merchants still need to be considered separately.

This introduces another architectural decision for businesses. Alongside their own commerce core and external sales channels, cross-merchant infrastructure for product discovery, customer identification and checkout is becoming increasingly relevant.

Actual availability remains dependent on the documented integration requirements, supported payment arrangements, geographical eligibility and release status of the individual capabilities.

7.8 Agentic Storefronts and regional availability

Shopify uses Agentic Storefronts to describe the distribution of products through supported AI channels.

These include ChatGPT, Google AI Mode and Gemini, Microsoft Copilot and selected Meta services.

Their capabilities and geographical eligibility differ.

For ChatGPT, Shopify currently documents a product-discovery and referral model.

Customers can discover products through ChatGPT before being directed to the merchant's normal checkout, either within the in-app browser or through a separate browser tab when using the web interface.

A separate direct ChatGPT checkout is not currently provided through this Shopify channel.

Among the documented conditions is a requirement for the merchant to serve customers in the United States. The merchant itself does not necessarily need to be based there.

Google AI Mode and Gemini, Microsoft Copilot and supported Meta interfaces follow different arrangements.

Direct checkout through Shopify can be available under particular conditions within the relevant AI channel.

Eligibility depends on the channel, supported countries, merchant qualification and the checkout requirements involved.

This distinction is especially important for European retailers.

The global availability of an open technical protocol does not establish that a merchant can offer direct purchases to German or other European customers within every supported AI interface.

Similarly, activation of a channel does not guarantee that all products will appear in results or that its checkout will reproduce every capability of the merchant's own storefront.

The Fall ’26 Edition also extends the ability to integrate Shop Pay into selected external AI agents. This does not establish universal availability across agents, merchants or customer regions. Authentication, transaction confirmation and payment authorisation remain dependent on the specific integration model.

Technical interoperability, regional eligibility and actual purchasing availability must therefore be assessed separately.

7.9 Shopify Agentic Plan

The Agentic Plan extends Shopify's role beyond merchants using its own commerce platform.

It is explicitly intended to support businesses whose existing online shop runs on another system.

Eligible merchants can provide product information to Shopify Catalog and access supported Agentic Storefronts without fully migrating their commerce core.

Product information must satisfy the applicable requirements.

For Agentic Plan merchants, this includes an external product URL linking to the existing online offer.

Other requirements concern business verification, merchant information and configuration of the relevant distribution channels.

The implementation depends on the intended purchasing model.

In a discovery or referral arrangement, the customer is directed to the existing merchant checkout.

In supported direct-checkout arrangements, Shopify components participate in the transaction within the AI channel.

Direct checkout is disabled by default under the Agentic Plan.

The merchant must enable it for the relevant supported channel and configure the necessary payment, tax and delivery settings.

ChatGPT continues to use the merchant's existing checkout through its referral model.

The standard Agentic Plan has no monthly subscription charge.

That does not mean every associated commerce process is free of charge.

Payment fees and other transaction-related costs may arise depending on the integration model.

Shopify also documents a separate enterprise form of the Agentic Plan with additional capabilities. Its technical and commercial terms require individual assessment.

There is another important distinction.

A Shopify online shop can be prepared under the Agentic Plan, but publishing a conventional Shopify storefront and using its checkout for ordinary online-store orders requires an appropriate paid commerce plan.

The Agentic Plan is therefore not a general replacement for the existing commerce platform.

It provides an additional integration option.

Product information, prices and inventory must remain accurate. Where direct checkout is used, orders, payments, fulfilment and customer service must be coordinated across the participating systems.

This can be particularly demanding when the existing commerce platform operates bespoke pricing, inventory reservations or fulfilment rules.

The strategic significance remains considerable.

Shopify offers a way to access certain agentic commerce capabilities without requiring the merchant to replace its existing platform.

That makes access to new AI distribution channels a distinct architectural decision rather than an automatic reason to replatform.

7.10 Implications for the existing commerce architecture

Agentic commerce introduces additional points of interaction between merchants and customers.

Products can be discovered without the customer first visiting the merchant's website.

Baskets can be prepared outside the normal storefront.

Purchasing processes can be initiated or supported by external applications.

These changes place additional demands on product information and commercial data.

Prices and availability must remain reliable at the point of purchase.

A price displayed during product discovery may not be the final transaction price. Inventory can change before checkout. Delivery conditions and payment requirements may depend on the buyer's actual circumstances.

The architecture must account for these differences.

Identity, authorisation and transaction traceability also become more important.

Shopify provides several technical foundations for these processes.

The wider organisational and legal responsibilities do not disappear simply because the interfaces are available.

For merchants, agentic commerce should therefore be considered an extension of commerce architecture rather than an isolated storefront initiative.

It connects product data, customer interactions, checkout, payments, orders and operational governance.

8. Identity, Authorisation and Governance

An authenticated agent is not necessarily an authorised buyer

Agentic commerce requires several identities and permissions to be distinguished.

An agent may be technically authenticated without being permitted to place an order for a particular customer.

A customer may be signed in without having approved a specific purchase.

A checkout may also be technically ready without a valid payment authorisation.

Agent identity, buyer identity, permission to place an order and payment authorisation are separate matters.

Shopify's checkout architecture reflects parts of this distinction through authentication requirements, transaction states and mechanisms for returning control to the buyer.

These mechanisms do not automatically establish the full scope of an agent's authority.

Buyer consent and payment authorisation

A customer may instruct an agent to research products and prepare a basket.

That instruction does not grant unlimited permission to purchase.

Approval of a proposed basket may also cease to be valid if its price, contents, delivery costs or payment conditions subsequently change.

Checkout WebMCP therefore requires confirmation of the current order and total by the buyer before completion.

Appropriately authorised Checkout MCP integrations must likewise satisfy the relevant confirmation and payment requirements.

Shopify's UCP Buyer Consent extension, documented in October 2026, also supports the structured communication of particular consents, such as marketing preferences or data-processing decisions.

These should not be mistaken for general authority to make purchases.

More autonomous purchasing arrangements would require additional controls.

Examples include maximum spending limits, permitted product categories, acceptable substitutes, delivery preferences, recurring commitments and revocable mandates.

Such rules would need to be technically enforceable and auditable.

At the research cut-off, a general Shopify standard capability for unrestricted autonomous purchasing under comprehensive delegated authority has not been established.

That is a statement about the available evidence, not a claim that such systems could never be developed.

Multi-merchant checkout processes introduce additional requirements for linking customer identity, transaction consent, payment and orders. Even where products from several merchants appear within a shared purchasing interface, the responsibilities of the individual merchants and the authorisation of each relevant transaction must remain traceable.

Commerce, agent and payment protocols

UCP, MCP, WebMCP and other agent or payment protocols address different problems.

UCP describes commerce capabilities and processes.

MCP enables structured tool access.

WebMCP exposes suitable functions within a browser context.

Approaches such as the Agent Payments Protocol, or AP2, focus more specifically on authorisation and accountability in agent-mediated payments.

Other protocols may be relevant where several agents or services communicate with one another.

Support for multiple protocols is not evidence of a fully interoperable and properly authorised purchasing process.

The important question is which functions have actually been implemented and which system is responsible for each decision.

A secure agent connection does not prove that the buyer approved a transaction.

A technically successful checkout also does not demonstrate that every preceding action complied with an authorised mandate.

Auditability and operational accountability

Agent-mediated purchases introduce additional requirements for logging, error handling and traceability.

A merchant must be able to establish which products were ordered, what prices and delivery terms applied, and which systems participated in the transaction.

Responsibility must also be clear when something changes.

An order may be cancelled, amended or returned. Payments may fail or need to be refunded. Products can become unavailable after an order has been placed.

Appropriate permissions and escalation procedures are required for these situations.

Privacy is another consideration when personal information moves between merchants, agent providers, payment services and other participating systems.

European organisations must assess the applicable lawful bases and responsibilities, including those arising under the General Data Protection Regulation.

Shopify's technical support for a process does not remove the need to assess the actual implementation.

Agentic commerce therefore introduces more than another sales channel.

It adds a new dimension to governance and accountability throughout the commerce operation.

9. Implementation and Economics

Standardisation can reduce costs

Shopify's SaaS model can reduce both development and operational responsibilities.

Businesses do not necessarily need to establish their own infrastructure for every central commerce function.

Many processes are available within the standard platform.

The financial benefit is strongest when business requirements fit that model reasonably well.

The cost of a Shopify architecture cannot, however, be determined from the monthly subscription price alone.

Applications, custom storefronts, integrations, payment providers, physical retail operations and multiple shops can all materially affect expenditure.

Internal process changes, migration and staff training also belong in the implementation assessment.

Plan selection and additional commerce capabilities

Basic, Grow, Advanced and Shopify Plus differ in functionality, capacity and commercial terms.

The choice should follow from specific requirements.

A company does not require Plus merely because it has substantial revenue or sells to business customers.

Plus may become necessary for particular B2B catalogue models, checkout customisations or additional technical capacity.

Expansion Stores and the applications required to support them also need to be included in the financial assessment.

Published subscription prices provide an initial reference point.

A meaningful cost model must reflect the applicable regional contract, payment fees and any relevant variable charges.

General implementation budgets would be misleading given the differences between operating models.

Payments and payment providers

Payments are both a technical component and a commercial cost driver.

Shopify Payments provides an integrated payment infrastructure in supported markets.

Available payment methods and fees depend on country, plan, payment method and contractual conditions.

External payment providers may introduce further charges and integration requirements.

International merchants must also consider separate legal entities, merchant accounts and financial reconciliation processes.

B2B payment terms and agentic checkout models add further considerations.

The evaluation should therefore extend beyond which payment logos can appear in checkout.

Authorisation, refunds, reconciliation and the allocation of transactions to the correct legal entity matter just as much.

Additional local payment methods and wider Shop Pay integrations extend the available payment models. Their economic relevance depends on country-specific availability, participating payment providers, transaction fees and reconciliation requirements. Supporting another payment method does not automatically reduce total operating costs.

Applications and integrations

Existing applications can reduce the need for bespoke development.

They remain economically attractive only when they can be operated reliably and maintained at a proportionate cost.

In more complex Shopify implementations, applications and integrations can develop significant dependencies.

Changes to one component may require testing and adjustment elsewhere.

This increases the importance of interface documentation, monitoring, technical ownership and disciplined release management.

Shopify's app ecosystem is particularly valuable when established solutions meet the business requirements without creating disproportionate complexity.

Where dependencies continue to multiply, the organisation should examine whether the original benefits of standardisation are being preserved.

Headless, international shops and omnichannel operations

A custom headless storefront, several international shops or complex POS and OMS integrations may expand the technical architecture considerably.

This does not necessarily make Shopify unsuitable.

It means that the economic assessment must reflect the actual solution rather than the platform's entry price.

A bespoke frontend requires development and maintenance.

Multiple shops can introduce additional application and integration costs.

Complex omnichannel operations may require external systems for inventory, order routing or customer identity.

The resulting cost structure differs substantially from that of a relatively standard online shop.

Total Cost of Ownership and Total Cost of Change

Two financial perspectives are particularly useful.

Total Cost of Ownership covers the cost of implementation, operation, maintenance and integration over the relevant period.

Total Cost of Change considers what happens when the business needs to evolve.

Entering another market may introduce additional tax and payment requirements.

A new brand may need its own shop structure.

A new B2B model may demand more sophisticated pricing or approval processes.

Agentic commerce can also change the integration and data architecture.

Where these developments fit Shopify's established capabilities, standardisation may continue to provide a long-term advantage.

Where every major change requires more bespoke systems, additional integrations and new operational dependencies, the economics become less straightforward.

The platform must therefore be evaluated not only against present requirements but also against plausible changes in the business.

10. Structural Limitations and Replatforming

A missing feature is not necessarily a platform limitation

Different kinds of constraints are often grouped together during platform selection.

A feature may be absent from the chosen plan but available on another.

It may require an app, a supported extension point or an external integration.

The underlying difficulty may also be an organisational responsibility that has never been clearly defined.

These are different problems and should not lead automatically to the same conclusion.

An external integration is not inherently undesirable.

Neither is an app.

A genuine architectural concern emerges when a business-critical process cannot be operated reliably, maintained effectively or delivered at a proportionate cost within the available model.

Pricing and order logic

Individual pricing and ordering arrangements are among the most important potential limits of a standardised commerce platform.

A business may calculate prices across several systems, manage complex contracts or require additional approval before an order becomes binding.

Shopify may support some of these requirements directly and integrate others through external components.

The assessment must establish whether the result is a coherent commercial process.

If ERP determines authoritative prices, the architecture must define when Shopify receives them and what happens when values change.

If an order requires external approval, the requirement must be enforced reliably rather than merely displayed in the user interface.

A structural limitation exists when essential requirements cannot be implemented adequately within the available architecture.

Complex B2B and omnichannel organisations

B2B businesses may depend on purchasing hierarchies, contractual structures and approval procedures that extend beyond native commerce functionality.

Omnichannel retailers face similar questions with inventory ownership, reservations and order routing.

Not every decision needs to be made within Shopify.

An external ERP or OMS may be the appropriate authority, particularly where it already controls the relevant processes.

The architecture must then make Shopify's responsibilities explicit.

A clear division can allow the platform to remain useful within a larger enterprise environment, even when certain processes are managed elsewhere.

Vendor dependency and data control

Shopify's SaaS architecture creates a deliberate dependency on its provider.

Organisations should understand which data can be exported, which extensions rely on proprietary interfaces and which processes would need to be recreated during a future migration.

External applications can introduce additional dependencies.

This is not, in itself, an argument against Shopify.

Every substantial commerce architecture involves dependencies.

What matters is whether they are understood, documented and manageable from both an operational and economic perspective.

New AI channels are not an automatic reason to migrate

Agentic commerce introduces new demands for product data, checkout interfaces and transaction processing.

Those demands do not automatically require replacement of the existing commerce platform.

Shopify's Agentic Plan demonstrates that certain capabilities can be introduced alongside another commerce system.

The integration still needs a proper technical and economic assessment.

If it supports the intended customer journey adequately, a full platform migration may add little value.

If essential requirements cannot be supported and workarounds create unacceptable complexity, a broader architectural reconsideration may be justified.

The existence of new protocols is not sufficient reason on its own.

The Fall ’26 Edition reinforces this conclusion. Shop.dev, Shop.md and Universal Checkout extend the possibilities for using Shopify services outside a complete Shopify storefront. The appropriate integration must still be assessed against the actual business processes, data flows, checkout responsibilities and downstream operational requirements.

When replatforming becomes a serious option

Replatforming should be driven by demonstrated commercial requirements.

It may be appropriate when the existing architecture can no longer support critical processes or when necessary business changes repeatedly create disproportionate cost and operational risk.

The assessment must also recognise the consequences of migration.

Existing investments, data structures, integrations, operating processes and organisational capabilities all have value.

Not every historical requirement needs to be reproduced unchanged in a new environment.

Sometimes simplifying a business process is more economical than replacing the platform that supports it.

The available decisions are therefore broader than keeping or replacing Shopify.

A business may extend its existing implementation, change the responsibility of connected systems, standardise certain processes or select a different core platform.

The appropriate choice should emerge from the evidence rather than from a predetermined preference for migration.

11. Management Conclusion

Shopify now offers considerably more than a standardised B2C online shop.

Its centrally operated commerce core is connected to a substantial extension model, native B2B functionality, international commerce capabilities and physical retail operations.

Agentic commerce is extending that infrastructure beyond the conventional storefront.

These developments create additional opportunities for merchants and introduce new questions about data quality, process ownership, identity and authorisation.

The fundamental strength of Shopify remains standardisation.

It can relieve organisations of many technical responsibilities and simplify the operation of common commerce processes.

That advantage is particularly meaningful when the business can operate effectively within the platform's intended model.

As pricing, contracts, ordering and operational processes become more specialised, the architecture surrounding Shopify becomes increasingly important.

Shopify Plus provides additional capabilities. Applications and APIs extend what can be achieved.

The full operation of a complex trading organisation nevertheless remains an architectural responsibility rather than a feature that can simply be purchased.

The Agentic Plan adds another consideration.

Under defined circumstances, Shopify can provide agentic commerce infrastructure to merchants using a different platform as their principal commerce system.

That makes the platform decision more nuanced.

A business does not necessarily have to migrate to Shopify to use certain newer Shopify capabilities.

Equally, adopting Shopify does not automatically provide universal access to every AI sales channel, purchasing model or authorisation mechanism.

The Fall ’26 Edition takes this development beyond individual AI sales channels. Shopify is positioning additional cross-merchant services for product discovery, identity, checkout and payments. This introduces another layer of architectural decision-making without automatically creating a reason to replace an existing commerce platform.

For executive teams, the starting point should be the actual requirements of the organisation.

Which processes create commercial advantage? Which can reasonably be standardised? Where must other systems retain authority? And which technical and organisational dependencies will remain acceptable as the business evolves?

Shopify may provide a suitable answer.

Whether it does so for a particular business cannot be established from the size of its app ecosystem, the breadth of its marketing claims or the number of newly introduced agentic commerce interfaces.

It depends on whether the complete commerce architecture fits the organisation and remains economically and operationally sustainable as its requirements change.

---

Sources and References

Technical and product research cut-off: 28 October 2026.

The Shopify references below document official product capabilities, prerequisites and restrictions. Architectural assessments and management conclusions are independent interpretations of those sources. Public documentation does not, by itself, establish successful implementation in every enterprise environment.

Platform architecture and extensibility

[S01] Shopify Developer Documentation. API Versioning. Stable versions, release cycles and support periods.
https://shopify.dev/docs/api/usage/versioning

[S02] Shopify Developer Documentation. API Limits. Technical usage limits, including GraphQL Admin API rate limits.
https://shopify.dev/docs/api/usage/limits

[S03] Shopify Developer Changelog. Hydrogen 2026-10. General availability and framework-independent development, 14 October 2026.
https://shopify.dev/changelog/blog/hydrogen-2026-10-is-now-available

[S04] Shopify Help Center. Checkout Customisation. Available checkout extensions and plan-dependent restrictions.
https://help.shopify.com/en/manual/checkout-settings/checkout-customization

[S05] Shopify Help Center. Expansion Stores. Organisation model, separate shop data and operational dependencies.
https://help.shopify.com/en/manual/organization-settings/expansion-stores

B2B and unified commerce

[S06] Shopify Help Center. Shopify B2B Features by Plan. B2B capabilities, catalogue limits, payment functionality and plan prerequisites.
https://help.shopify.com/en/manual/b2b/getting-started/plan-features

[S07] Shopify Help Center. B2B Considerations. Requirements and documented functional restrictions.
https://help.shopify.com/en/manual/b2b/getting-started/considerations

[S08] Shopify Help Center. Shopify POS. Physical retail functionality and operating models.
https://help.shopify.com/en/manual/sell-in-person/shopify-pos

[S09] Shopify Help Center. POS Return Rules. Return policies, POS Pro prerequisites and operational exceptions.
https://help.shopify.com/en/manual/sell-in-person/shopify-pos/order-management/return-rules

Agentic commerce and technical interfaces

[S10] Shopify Developer Documentation. About Catalogs. Global Catalog, Storefront Catalog and UCP-based catalogue access.
https://shopify.dev/docs/agents/catalog

[S11] Shopify Developer Documentation. Global Catalog MCP. Cross-merchant product discovery.
https://shopify.dev/docs/agents/catalog/global-catalog

[S12] Shopify Developer Documentation. Storefront Catalog MCP. Merchant-specific product discovery.
https://shopify.dev/docs/agents/catalog/storefront-catalog

[S13] Shopify Developer Documentation. Carts and Checkout for Agents. The respective roles of Cart MCP, Checkout MCP and Checkout WebMCP.
https://shopify.dev/docs/agents/carts-and-checkout

[S14] Shopify Developer Documentation. Cart MCP. Basket management and the UCP Cart capability.
https://shopify.dev/docs/agents/carts-and-checkout/cart-mcp

[S15] Shopify Developer Documentation. Checkout MCP. Authentication, checkout states, escalation and API-based completion.
https://shopify.dev/docs/agents/carts-and-checkout/checkout-mcp

[S16] Shopify Developer Documentation. Checkout WebMCP. Browser-based checkout tools, buyer confirmation and functional restrictions.
https://shopify.dev/docs/agents/carts-and-checkout/checkout-webmcp

[S17] Shopify Developer Changelog. WebMCP Support for Liquid and Hydrogen Storefronts. Published 5 August 2026.
https://shopify.dev/changelog/posts/webmcp-liquid-hydrogen

[S18] Shopify Developer Changelog. WebMCP Support for Checkout. Published 28 September 2026.
https://shopify.dev/changelog/posts/webmcp-support-for-checkout

[S19] Shopify Developer Changelog. Shop MCP. Introduction of the combined shopping interface, 13 October 2026.
https://shopify.dev/changelog/posts/add-shopping-and-shop-pay-checkout-to-any-agent-with-shop-mcp

Agentic Storefronts and Agentic Plan

[S20] Shopify Help Center. Shopify Agentic Storefronts. Channels, distribution models and eligibility requirements.
https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts

[S21] Shopify Help Center. Selling on ChatGPT. Product discovery, checkout referral and market requirements.
https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/chatgpt

[S22] Shopify Help Center. Selling on Google AI Mode and Gemini. Direct-checkout eligibility and restrictions.
https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/google

[S23] Shopify Help Center. Shopify Agentic Plan. Use alongside an existing commerce platform and relevant functional and commercial limitations.
https://help.shopify.com/en/manual/intro-to-shopify/pricing-plans/plans-features/shopify-agentic-plan

[S24] Shopify Help Center. Agentic Plan Setup. Product information, verification, checkout models and channel configuration.
https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/agentic-plan-setup

Protocols and governance

[S25] Universal Commerce Protocol. Official protocol specifications and commerce capabilities.
https://ucp.dev/

[S26] Agent Payments Protocol. Protocol framework for authorisation in agent-mediated payments.
https://ap2-protocol.org/

Fall ’26 Edition

[S27] Shopify. Fall ’26 Edition. Official overview of the new capabilities and product announcements.
https://www.shopify.com/editions/fall2026

[S28] Shopify. Fall ’26 Edition: Developer Announcements. Shop.dev, Shop.md, Universal Checkout, WebMCP and developer-oriented capabilities.
https://www.shopify.com/news/fall-26-edition-developer

[S29] Shopify. Fall ’26 Edition: Merchant Announcements. POS, customer identification, shopping journeys, payments and commerce operations.
https://www.shopify.com/news/fall-26-edition-merchant

[S30] Shopify. Shop.dev. Developer access to product discovery, identity, baskets, checkout and Shop Pay for external applications and AI agents.
https://shop.dev

The references represent the documented product position at the research cut-off. Recently introduced agentic commerce capabilities, in particular, require renewed confirmation of development status, regional eligibility and implementation prerequisites before deployment.