BigCommerce Deep Dive 2026: Open SaaS, B2B and the Responsibility for Distributed Commerce Processes

1. Executive Snapshot

BigCommerce combines a standardised SaaS commerce core with extensive integration and customisation capabilities. Its Open SaaS approach allows merchants to rely on a platform provider for essential digital commerce functions while connecting existing enterprise systems and developing individual customer experiences.

This creates a different allocation of responsibilities from a fully self-managed commerce application. Merchants do not need to develop and operate the entire underlying platform infrastructure or every standard commerce capability themselves. They do, however, remain responsible for coordinating the systems and processes that make up their wider trading operation.

The distinction becomes particularly important when product information originates in a PIM, pricing and customer terms are maintained in an ERP, an OMS controls order fulfilment and several storefronts serve different markets. BigCommerce can perform essential commerce functions within such an architecture. It does not automatically assume responsibility for coordinating the entire operation.

Since July 2025, BigCommerce, Feedonomics and Makeswift have operated under the corporate umbrella of the publicly listed Commerce.com. BigCommerce provides the transactional commerce core. Feedonomics supports the preparation and distribution of product information. Makeswift extends the capabilities available for creating and managing digital shopping experiences.

During autumn 2026, BigCommerce also expanded its technical capabilities for agentic applications. Its B2C and B2B Storefront MCP tools are generally available. WebMCP provides browser-based agents with structured access to supported storefront functions. Catalyst also exposes documented endpoints for the Universal Commerce Protocol.

These developments address different stages of the purchasing process. Access to product information, basket operations, checkout protocols, payment authorisation and subsequent business processes must not be treated as interchangeable capabilities.

The general availability of an interface does not, by itself, demonstrate that an external agent can conclude a legally binding purchase without additional technical, contractual or authorisation requirements.

Implications for platform selection

BigCommerce deserves consideration where an organisation wants to avoid operating its entire commerce infrastructure while retaining the ability to address individual storefront, B2B or integration requirements.

The architecture becomes more demanding when important business rules do not fit the standard platform model or when connecting numerous applications creates a substantial operating environment of its own.

The fundamental BigCommerce decision is therefore not how open the platform is. It is which responsibilities BigCommerce assumes and which remain permanently with the merchant.

2. Commerce.com and the Position of BigCommerce

From commerce platform to broader portfolio

On 31 July 2025, BigCommerce announced a change in its corporate positioning. BigCommerce Holdings, Inc. was renamed Commerce.com, Inc. In August 2025, its Nasdaq ticker changed from BIGC to CMRC.

BigCommerce, Feedonomics and Makeswift are now positioned within the same corporate group.

This development broadens the company's strategic proposition beyond the traditional commerce platform. It does not, however, remove the distinction between its individual products.

BigCommerce provides core commerce functions, including the catalogue, basket, checkout, orders and customer-related commerce processes.

Feedonomics addresses the aggregation, preparation, optimisation and distribution of product information across channels.

Makeswift supports the visual creation and management of digital storefront experiences.

Common ownership creates opportunities for closer collaboration between these products. It does not mean that they are automatically included in a single licence or share identical data models, permissions and technical services.

Merchants therefore need to establish whether a capability is included directly within BigCommerce, delivered through an additional Commerce.com product or dependent on further integration.

This distinction matters particularly for product data enrichment, cross-channel distribution and the development of individual storefront experiences.

A broader product portfolio can simplify a merchant's architecture. It can equally introduce additional licensing, integration and operational decisions.

Corporate development and vendor risk

Commerce.com remains a publicly listed company. Claims that BigCommerce was acquired by Bain Capital and taken private in 2024 are incorrect.

Reports at the time concerned possible acquisition discussions. They did not result in a completed Bain Capital transaction.

In September 2026, Commerce.com announced a restructuring programme. According to the company, the measures are intended to deliver annual savings of approximately US$60 million to US$80 million. It also set a target of at least a 20 per cent non-GAAP operating margin for 2027.

Developments of this kind are relevant when assessing a strategic software provider.

They do not, without further evidence, justify claims that platform continuity is immediately at risk or that particular products will be discontinued.

For merchants, the more useful questions concern the direction of product investment, technical roadmaps, support and the long-term maintenance of existing capabilities.

These considerations should form part of regular vendor assessment, whether the company concerned is growing or restructuring.

Market position and organisational fit

BigCommerce serves B2C and D2C merchants as well as B2B businesses, wholesalers and internationally operating organisations.

The platform can be particularly relevant where core commerce processes can largely be standardised and individual requirements addressed through configuration, documented interfaces or additional specialist systems.

For mid-market trading organisations, integration with existing systems often matters more than the number of features available within the commerce platform itself.

A merchant whose ERP retains commercial responsibility and whose PIM governs product information does not necessarily need its commerce platform to duplicate those functions.

It needs a clearly defined division of responsibilities.

Whether BigCommerce provides the appropriate foundation depends on the business model, existing architecture and organisational capabilities.

3. Open SaaS: What the Platform Takes Responsibility For

Standardised operations and their limits

Open SaaS is central to BigCommerce's technical positioning.

The platform provides essential commerce services within an environment operated by the vendor. Merchants are therefore relieved of responsibility for managing substantial parts of the underlying infrastructure.

Platform updates, important operational capabilities and standardised commerce services form part of the provider's operating model.

At the same time, the commerce core remains a controlled SaaS environment. Merchants can configure documented capabilities and extend them through interfaces, but they do not gain unrestricted access to every internal process.

The openness lies primarily in APIs, webhooks, extension mechanisms and alternative storefront architectures.

This flexibility is significant. It should not, however, be confused with complete control over the commerce engine.

An architectural assessment must distinguish requirements that can be met through standard functionality, those requiring additional components and those genuinely affected by structural platform constraints.

APIs and integration responsibility

BigCommerce provides REST APIs, a GraphQL Storefront API and webhooks.

These allow external applications to work with product information, prices, customer contexts and orders within supported integration scenarios.

The technical availability of an interface does not resolve the question of business responsibility.

If an ERP is the authoritative system for inventory, the organisation must determine when changes are transferred to BigCommerce, how reservations are accounted for and which system takes precedence when information differs.

Similar questions arise around prices and customer data.

API capacity must also be considered. The developer documentation specifies, for example, 150 REST API requests per 30 seconds for Core and Growth, and 450 for Scale. Different arrangements apply to Performance depending on contractual terms, API and resource.

Several applications may compete for the same available store quota.

These limits do not constitute general evidence of inadequate scalability. They do influence the design of integrations involving large data volumes, frequent updates or numerous connected applications.

Queues, retry mechanisms, monitoring and reliable error handling therefore belong to a robust integration architecture.

Stencil as the standardised storefront

Stencil is BigCommerce's theme-based storefront architecture.

It provides a more standardised frontend model within the platform's supported environment.

Themes can be designed, adapted and extended, provided the implementation remains within the documented architecture and its capabilities.

For organisations with largely standard requirements, this can be an economically sensible approach.

Not every commerce project benefits from introducing additional frontend infrastructure, deployment processes and responsibility for maintaining a separate framework.

Stencil should therefore not be regarded as unsuitable simply because alternative headless architectures are available.

Catalyst and custom headless architectures

Catalyst is BigCommerce's headless storefront architecture based on Next.js.

It provides greater scope for individual frontend design and development. Organisations can create their own components, integrations and user interfaces.

The additional freedom changes the allocation of operational responsibility.

Depending on the implementation, merchants or their delivery partners may need to manage hosting, deployment, framework updates, frontend security, monitoring and the maintenance of custom components.

Marketplace applications originally developed for Stencil may not work unchanged within a headless storefront.

The availability of individual development and hosting products must also be distinguished. The Catalyst CLI is generally available. BigCommerce Storefront Hosting was still documented as a closed beta at the research cut-off.

Custom headless architectures can extend technical freedom further. They also increase responsibility for integration and long-term maintenance.

A headless frontend does not automatically make the commerce core completely replaceable or internally customisable.

The storefront decision should therefore reflect how much additional freedom the organisation actually needs and how much responsibility it can sustain over time.

Checkout architecture and extension boundaries

Checkout illustrates the distinction between a customisable frontend and a vendor-operated commerce core particularly clearly.

BigCommerce provides several approaches, including Open Checkout, the Checkout SDK and Checkout APIs.

Open Checkout and the Checkout SDK allow merchants to adapt the checkout interface and incorporate documented functionality.

They do not provide unrestricted control over the payment, shipping and order-processing logic within the SaaS core.

The GraphQL Storefront API also supports checkout processes, including the processing of checkout information and converting an eligible checkout into an order. Its exact capabilities depend on the relevant API prerequisites and limitations.

This distinction matters when assessing Agentic Commerce.

The general BigCommerce checkout architecture supports capabilities beyond those exposed through the particular Storefront MCP tools.

When an MCP agent generates a checkout link, that describes a boundary of the relevant toolset. It does not establish that the entire BigCommerce platform is technically incapable of supporting further checkout processing.

The feasibility of individual checkout requirements must therefore be assessed against the actual API and architecture being used.

4. Commerce Functionality and B2B Processes

The commerce core for B2C and D2C

BigCommerce provides essential digital commerce capabilities.

These include product catalogues, variants, options, customer groups, price lists, promotions, baskets, checkout, payment integration and order management.

For numerous B2C and D2C business models, these capabilities provide a viable technical foundation.

Their suitability depends, however, on the complexity of products, prices, customer relationships and operational processes.

A merchant with a relatively standard catalogue and straightforward fulfilment requirements faces different challenges from a business with configurable products, regional pricing variations or individually negotiated contractual terms.

International storefronts likewise need to be assessed individually in relation to currencies, taxes, payment methods, languages and legal requirements.

The technical ability to serve several markets does not eliminate the need for market-specific operational and legal arrangements.

The same applies to subscriptions, specialised product configurations and individual fulfilment scenarios.

Where additional applications or custom integrations are needed, they belong within the assessment of the target architecture rather than being assumed to form part of the platform's standard functionality.

B2B Edition as an additional product layer

With B2B Edition, BigCommerce offers a separate product for organisation-specific business purchasing processes.

The distinction from the underlying commerce core is important.

Customer groups and price lists may provide a foundation for B2B trading. They do not automatically deliver company accounts, organisational roles, purchasing lists, quotation processes and additional procurement capabilities.

B2B Edition adds a Buyer Portal and capabilities for Company Accounts, Buyer Roles, Quotes, Shopping Lists and invoices.

Different permissions can be assigned within a purchasing organisation.

A Junior Buyer, for example, may prepare purchasing lists without holding the same ordering authority as a Senior Buyer.

For many B2B organisations, this distinction is an essential part of the purchasing process.

Organisational hierarchies and multiple storefronts

The existence of Company Accounts does not mean that every international corporate structure can be represented completely within the standard product.

Larger purchasing organisations may comprise several legal entities, central procurement functions, local subsidiaries and different cost centres.

B2B Edition supports organisational models within its documented capabilities. Certain hierarchy functions may, however, depend on the specific B2B configuration.

Multi-Storefront introduces an additional business constraint.

An organisation may have a shared purchasing structure while quotations, invoices, shopping lists and orders remain associated with individual storefronts.

Buyer permissions may also depend on the storefront to which the buyer is assigned.

For an international wholesaler operating central agreements alongside regional sales entities, this can be decisive.

It is not enough for all users to be associated with the same company account.

The merchant must establish whether the required visibility, approval logic and commercial processing work across the relevant storefront boundaries.

Quotations, shopping lists and procurement

B2B Edition provides documented capabilities for quotations, shopping lists and other Buyer Portal processes.

These can improve collaboration between merchants and business customers.

Complete procurement processes, however, often extend beyond the Buyer Portal.

Contract terms, budgets, approvals, goods receipt, invoice matching and payment authorisation may remain within ERP, procurement or other enterprise applications.

A digital quotation process is therefore not necessarily an integrated end-to-end procurement process.

The architecture must establish which activities take place within the commerce system and which continue to be governed elsewhere.

B2B and headless storefronts

B2B Edition supports different storefront architectures, including Stencil, Catalyst and custom headless implementations.

Its capabilities nevertheless involve additional technical interfaces and their own permission models.

The B2B GraphQL API must not be treated as interchangeable with every capability of the general GraphQL Storefront API.

Headless projects therefore need to establish which Buyer Portal functions can be used directly and which require additional development.

The existence of an interface does not demonstrate that an entire B2B business process is available without further implementation.

The suitability of B2B Edition ultimately depends on the purchasing organisation, its permissions and its integration with the underlying commercial processes.

5. From Online Store to Distributed Commerce Architecture

Multi-Storefront is not Unified Commerce

BigCommerce supports different storefronts and sales channels.

These capabilities can be relevant for businesses operating multiple brands, countries or customer segments.

An additional sales channel initially expands the ways in which a business can sell.

It does not guarantee that inventory, customer information, orders, payment processes and returns are handled consistently across all channels.

The distinction becomes particularly clear with Click & Collect, Ship-from-Store and cross-channel returns.

A merchant needs to determine which stock is available, which quantities have been reserved, where an order should be fulfilled and which system has authority over subsequent changes.

BigCommerce can form part of such an architecture.

Whether a particular process is supported by documented functionality or requires additional systems must be established for the individual scenario.

Inventory, orders and system ownership

In more complex retail organisations, the availability displayed in a storefront is only one view of the overall inventory position.

Warehouse stock, store inventory, reservations, transfers and existing delivery commitments need to be reconciled.

An OMS may take responsibility for coordinating these processes. In other organisations, important functions remain within the ERP.

BigCommerce does not necessarily need to be the authoritative system for inventory and order orchestration in every architecture.

What matters is that ownership is explicitly defined.

The GraphQL Storefront API supports numerous basket and checkout functions but documents limitations for some scenarios, including certain Buy Online, Pick Up in Store operations.

This does not establish that Click & Collect is fundamentally impossible with BigCommerce.

It demonstrates why support for specific omnichannel processes needs to be assessed against the APIs and integrations actually used.

Feedonomics and the product data layer

Within the Commerce.com portfolio, Feedonomics operates in the product data and syndication layer.

It supports the aggregation, preparation, optimisation and distribution of product information across different sales and marketing channels.

For large catalogues, the requirements for attributes, taxonomies, categories and data formats can vary considerably between channels.

Feedonomics can help prepare this information consistently and deliver it in an appropriate format.

This primarily improves the distribution of product data.

A correctly transmitted product feed does not mean that an order originating from the corresponding channel is fully integrated into the ERP, OMS and customer service environment.

Product syndication and Unified Commerce address different problems.

Product data enrichment and AI-driven discovery

On 29 September 2026, Commerce.com introduced Feedonomics Enrichment and BigCommerce Catalog Enrichment.

These products extend the capabilities available for preparing product information and making it useful in different digital discovery environments.

This includes improvements to attributes, descriptions and data consistency, alongside support for AI-driven product discovery.

Feedonomics Enrichment is positioned as a standalone offering. BigCommerce Catalog Enrichment brings related capabilities closer to the BigCommerce catalogue environment.

The original product announcement restricted generated product content to English. Further languages were announced.

For merchants operating German or multilingual catalogues, this restriction matters.

Responsibility for the accuracy of product information also remains with the merchant.

Automatically generated attributes and descriptions must reflect the actual products, brand requirements and, where applicable, regulatory obligations.

Feedonomics independently of the commerce core

For established commerce environments, product data optimisation does not necessarily require a migration of the transactional platform.

Feedonomics can also be considered as a standalone product data and syndication solution.

An organisation seeking to improve product information for marketplaces, advertising platforms or AI-based discovery therefore has no automatic reason to replace its commerce core.

Keeping these decisions separate can protect existing investments and limit changes to the processes genuinely affected.

Makeswift as an experience layer

Makeswift supports the visual creation and management of digital pages and shopping experiences.

Within Catalyst, Makeswift can work with custom React components.

Developers can provide technical components that content and commerce teams subsequently use within defined editorial boundaries.

This can improve collaboration between development and business teams.

The Stencil integration was still documented as beta at the research cut-off and did not offer exactly the same capabilities as the Catalyst implementation.

This is another example of why shared corporate positioning should not be confused with identical technical support across different architectures.

Unified Commerce as an organisational responsibility

BigCommerce, Feedonomics and Makeswift can perform different functions within a modern trading architecture.

They do not automatically replace ERP, OMS, CRM, store systems or payment service providers.

The essential question is which system has business ownership of each process.

Only once that responsibility is established can technical interfaces support dependable operations across channels.

The same foundation is needed for agentic applications that increasingly move beyond retrieving product information towards executing actual commerce actions.

6. Agentic Commerce: Access Is Not Autonomy

Different layers of agentic commerce

Agentic Commerce is not a single technical capability.

It ranges from structured product data provision and product discovery to basket management, checkout protocols and potentially delegated transactions.

These layers need to be assessed separately.

An agent that evaluates product characteristics performs a different function from an application that modifies a basket.

A standardised checkout protocol introduces further technical possibilities without automatically resolving questions of identity, payment and legal authorisation.

During 2026, BigCommerce documented concrete developments across several of these layers.

Product information and agentic discovery

Agentic shopping requires reliable information about products, variants, prices and availability.

Feedonomics and the new enrichment offerings can help improve that information.

Agentic Catalog Exports also belong within this layer.

They can provide structured product information to suitable external systems.

Successful data provision does not, however, demonstrate that an external agent can place an order, authorise a payment or manage subsequent changes.

Those actions depend on additional commerce and authorisation capabilities.

Storefront MCP

On 8 October 2026, BigCommerce announced general availability of its B2C and B2B Storefront MCP tools.

The Model Context Protocol enables agent applications to access documented tools in a structured manner.

B2C Storefront MCP supports functions including product discovery, retrieving product details, basket operations and generating checkout links.

Agents can therefore interact with actual commerce functionality rather than relying exclusively on interpreting a website's visible interface.

The tools can serve guest users and, in suitable configurations, authenticated buyers.

Their use nevertheless requires an enabled connection and a supported client.

General availability of the server does not mean that every conceivable agent client or storefront configuration is supported.

Storefront Session Sync

Storefront Session Sync connects an MCP session with the existing browser context of a signed-in customer.

The documented implementation applies to Stencil.

Subject to the relevant conditions, login state, basket information and customer-specific data can be transferred.

BigCommerce uses short-lived synchronisation tokens for this purpose. The agent does not receive the customer's browser cookies directly.

For B2B applications, the existing company and permission context may also be relevant.

This represents an important technical development because agentic actions no longer need to rely exclusively on anonymous product information.

At the same time, changes between the agent session and browser state must remain consistent.

An authenticated session permits only those actions for which the underlying buyer is actually authorised.

B2B Storefront MCP

The B2B toolset extends the general storefront capabilities with selected Buyer Portal operations.

The documentation includes tools for shopping lists and quotations.

These become available according to B2B Edition, the authenticated buyer's identity and their permissions.

An agent can consequently prepare or modify certain procurement activities.

For example, it may update a shopping list or retrieve quotation information where the buyer has the appropriate rights.

Generating a checkout link from an eligible quotation context is also documented.

This brings existing role-based permissions into parts of the agentic interaction.

It does not remove the need to determine who is entitled to approve an order or authorise payment.

WebMCP and Cloudflare

On 21 October 2026, BigCommerce introduced WebMCP for supported storefronts.

WebMCP allows browser-based agents to access structured tools made available by a website within the browser environment.

The developer documentation describes default enablement for Stencil and for Catalyst storefronts hosted on Cloudflare. Custom headless storefronts on Cloudflare may be connected subject to additional requirements.

Where server-side Storefront MCP tools are enabled, they can automatically be exposed through WebMCP.

Settings can be managed through the BigCommerce Control Panel, and merchants can disable WebMCP.

The functions that can actually be used still depend on browser support, storefront architecture and the available tools.

WebMCP therefore provides an additional route into existing commerce functionality.

It is not a blanket assurance that every browser-based agent can complete every sales process.

UCP: An additional technical layer

Alongside MCP and WebMCP, BigCommerce documents concrete support for the Universal Commerce Protocol.

Catalyst 1.12.0, released on 16 September 2026, exposes UCP endpoints on the public storefront domain.

These include /.well-known/ucp for protocol discovery and /api/ucp/* for relevant protocol requests.

Catalyst forwards these requests to BigCommerce. The protocol processing itself takes place on the BigCommerce platform rather than within the Catalyst application.

This goes beyond a statement of strategic intent. It demonstrates a documented UCP integration, with Catalyst exposing the endpoints and BigCommerce handling protocol processing.

The existence of these endpoints alone does not, however, establish which transactional capabilities are operationally available for every merchant, region or external agent.

In particular, supported UCP functions, payment integrations, authorisation models and further prerequisites need to be assessed individually.

Technical provision of a UCP interface should therefore be equated neither with a simple product feed nor with an unrestricted autonomous purchasing process.

Checkout and transactional boundaries

The distinction between agentic interfaces and the general checkout architecture is fundamental.

The documented Storefront MCP process allows an agent to find products, modify baskets and generate a checkout link.

The buyer then completes the purchase through the regular checkout.

BigCommerce nevertheless has additional Checkout APIs and documented UCP endpoints beyond this particular toolset.

The limitations of Storefront MCP must not therefore be presented as universal limitations of every technically possible checkout process on the platform.

An assessment of agentic transactions must answer several questions.

Which actions can the agent actually perform? Which prerequisites must the merchant satisfy? Who confirms the binding purchase? What technical and legal authorisation exists? How is payment processed? Which systems handle subsequent changes, returns and customer service?

The currently documented capabilities do not provide a single answer applicable to every merchant.

Store Management MCP

Alongside its customer-facing interfaces, BigCommerce is developing Store Management MCP for administrative activities.

At the research cut-off, this was available only through an invitation-only closed beta.

Its documented functions include activities involving the product catalogue, prices, inventory, promotions and selected order and refund processes.

Access uses OAuth 2.1 with PKCE and permissions associated with individual users.

Different safeguards are applied to different actions.

Newly created products remain hidden initially. Newly created promotions are disabled and require separate activation before use.

Other tools can make immediately effective changes. These include price or inventory updates and the ability to issue actual refunds.

The level of protection therefore depends not merely on whether an agent is technically authenticated, but also on which action it can perform and what controls exist before that action takes effect.

The closed beta must not be confused with the general availability of Storefront MCP.

Open protocols and their different purposes

MCP, WebMCP and UCP address different parts of agentic commerce architectures.

MCP provides structured access to tools. WebMCP makes suitable functionality available in the browser context. UCP addresses standardised commerce processes and their technical interaction.

Other protocols pursue complementary objectives.

ACP describes commerce interactions between AI applications and merchants. AP2 addresses authorisation and payment evidence. A2A concerns communication between agents.

The existence of these standards does not establish their complete implementation within BigCommerce.

The documented UCP connection should be recognised. Support for other protocols or individual transactional stages needs to be established separately.

The relevant question is not how many protocols a vendor mentions, but which business processes they actually support.

Agentic Commerce as an end-to-end process

The new interfaces expose significant elements of digital shopping to agents.

These include product discovery, selected basket operations and certain checkout interactions.

Fully delegated purchasing requires additional capabilities, including explicit mandates, permissions, price and budget limits, payment authorisation and traceable post-purchase processes.

Complete production support for this entire sequence cannot be established solely from the documented MCP, WebMCP and UCP endpoints.

That does not mean more extensive solutions are fundamentally impossible.

It means their actual implementation must be assessed within the relevant technical and contractual context.

BigCommerce has significantly expanded technical access to real commerce functions. Whether this becomes a fully delegated purchasing process depends on the additional requirements for transactions, authorisation and integration.

7. Identity, Permissions and Governance

Technical access and commercial authority

Agentic commerce processes do not change the fundamental responsibility for commercial decisions.

They do, however, change how those decisions can be prepared and executed technically.

When an agent acts on behalf of a buyer, technical authentication, business permissions and legal authority must be distinguished.

A successful login initially establishes an identity.

It does not prove that every action initiated by an agent has been authorised by the buyer.

Within B2B organisations, company affiliation, purchasing roles, budget limits and potentially multi-stage approval processes add further requirements.

Those controls must remain effective when an application supports the purchasing process through MCP or other protocols.

Buyers, organisations and agents

A sound governance model distinguishes the human buyer, the purchasing organisation, the agent being used, the agent provider and the commerce and payment service providers involved.

Each participant has different responsibilities and access to different information.

The merchant must be able to establish which action was performed, under which authority and with what commercial consequences.

Limits concerning order values, delivery addresses, substitute products, recurring commitments and revocation of permissions are particularly important.

Where these rules are not provided through standard platform capabilities, additional controls are necessary.

Permissions in Store Management MCP

Administrative MCP access illustrates the distinction between technical and business controls particularly clearly.

The closed beta uses permissions for functional areas including products, inventory, promotions and orders.

These permissions are not fully granular at field level.

A user authorised to modify products cannot necessarily be restricted to editing descriptions while being technically prevented from changing prices.

Permissions are also assigned to users rather than separately to every connected agent.

Several agents operating under the same user identity may therefore receive the same access rights.

The documentation further explains that actions in the audit trail are attributed to the authorising user. Independent attribution to the individual executing agent is not yet provided.

This limits traceability where several agents operate through the same user account.

Different risks associated with administrative actions

Not every agent action has the same commercial significance.

Creating a product that initially remains hidden, or a promotion that remains disabled, provides an additional opportunity for review before the change affects customers.

A price modification, by contrast, may immediately affect published commercial terms.

An actual refund creates a financial movement and cannot be reversed through the same tool call.

BigCommerce provides technical checks within the refund process, including calculating a proposed refund and checking the amount again before execution.

These controls do not replace a separate business approval where the organisation requires one.

For financially consequential actions, human confirmation, permission boundaries and auditability must form part of the implemented process.

There is also a relevant operational consideration. Changes to or revocation of permissions may not take effect immediately in every existing beta session.

This matters when evaluating the operational and security requirements of administrative agents.

Governance across system boundaries

Responsibility does not end at the BigCommerce interface.

When an agent uses product information from Feedonomics, retrieves customer-specific terms through BigCommerce and subsequently prepares a payment using an external service, several technical and organisational boundaries are crossed.

Prices, availability, customer identity, authority to act and payment status must remain consistent.

Customer service and complaints handling also need traceable information about agent actions and decisions explicitly confirmed by customers.

Agentic Commerce governance is therefore not an isolated AI problem. It extends existing commerce governance and makes unclear permissions or system responsibilities more visible.

8. Implementation, Operations and Economics

Platform licensing is only part of the cost

BigCommerce changed its public plan structure in June 2026 to Core, Growth, Scale and Performance.

The current public US list prices start at US$29 per month for Core, US$79 for Growth and US$299 for Scale when billed annually. Performance is offered under individually negotiated terms and starts at US$1,499 per month with annual billing according to the public pricing information.

These figures do not constitute a reliable project budget for a merchant in Germany.

They describe the public starting point for platform licensing. Actual costs depend on the plan, transaction volume, payment processing, additional products and contractual arrangements.

GMV thresholds and payment fees

Since June 2026, BigCommerce has applied a revised revenue and fee structure to its self-service plans.

Two mechanisms must be distinguished.

Plan allocation is based on BigCommerce's defined Gross Merchandise Value. Under the published rules, the relevant Inclusive GMV is calculated by reducing the gross order value by ten per cent.

The public pricing information specifies a twelve-month threshold of US$30,000 for Core and US$100,000 for Growth. Scale uses a monthly GMV threshold of US$33,333, with an additional volume-based arrangement above that threshold.

Separately, BigCommerce charges an Open Payment Provider Fee on certain plans.

The fee applies to the relevant order volume actually processed through an Open Payment Provider.

Transactions processed through a qualifying Embedded Payment Provider are not subject to that additional fee.

Where a merchant uses multiple payment providers, only certain portions of its order volume may therefore attract the charge.

Simply displaying an Embedded Payment Provider during checkout is not sufficient. What matters is which provider actually processes the transaction.

Orders originating from other sales channels or custom integrations may also be subject to the arrangement, depending on their payment processing and the published contractual conditions.

Normal payment service provider charges remain separate.

A meaningful financial assessment must therefore examine at least the platform plan, relevant GMV, payment provider mix and individual contract terms.

The historical claim that BigCommerce does not charge additional transaction-related fees is no longer generally valid.

Additional products and contractual boundaries

B2B Edition, Feedonomics, Makeswift and other supplementary products need to be assessed individually for licensing and scope.

Their presence within the Commerce.com group does not mean they are automatically included in a BigCommerce licence.

Multi-Storefront configurations, additional applications and specialised integrations may also create recurring costs.

The economic assessment must therefore concern the target architecture that the merchant actually requires.

Comparing public entry-level subscription prices would not provide a sufficient basis for that decision.

Development and long-term operations

Storefront architecture influences cost as much as platform licensing.

A more standardised Stencil implementation can limit certain frontend development and operational responsibilities.

Catalyst and custom headless architectures offer greater flexibility but demand additional technical capabilities.

Depending on the implementation, these include hosting, deployment, framework updates, monitoring, security and the maintenance of custom components.

Compatibility with existing applications and the integration of additional services also require consideration.

A headless storefront is therefore not merely a one-off development project. It becomes part of an operating environment that must be maintained over time.

Integrations and data quality

ERP, PIM, OMS and CRM integrations can account for a substantial proportion of overall expenditure.

Their complexity depends less on the existence of technical interfaces than on data quality, business processes and the allocation of responsibilities.

A merchant with clearly defined data ownership and stable interfaces starts from a different position from an organisation with numerous custom applications, inconsistent master data and unclear process ownership.

Monitoring, error handling and recovery from failed data transfers are also recurring operational responsibilities.

An integration failure may result in incorrect prices, unreliable availability or delayed orders.

These risks belong within the economic assessment.

Total Cost of Ownership and Total Cost of Change

Total Cost of Ownership includes implementation, licensing, payment processing, integrations, development and ongoing operations over a defined period.

For BigCommerce, this includes the platform itself, additional products, applications, storefront operations and integration with existing enterprise systems.

Total Cost of Change deserves separate consideration.

It describes the economic consequences of future modifications.

An organisation may enter new markets, change its B2B procurement processes, connect additional marketplaces or introduce agentic applications into the purchasing journey.

An architecture that appears inexpensive initially may become costly if such changes repeatedly require substantial custom development.

Conversely, a more demanding integration architecture may be economically justified if it makes recurring changes easier to implement.

No general BigCommerce cost advantage or disadvantage can be inferred from these considerations.

Economic performance depends on the relationship between platform capabilities, the existing systems landscape and organisational competence.

The economics of agentic capabilities

The new MCP, WebMCP and UCP interfaces create additional technical opportunities.

Their economic value cannot, however, be inferred from availability alone.

Merchants need to determine whether these capabilities are used in practice, which commercial processes they improve and what additional expenditure arises from product data quality, integration, permissions, monitoring and customer service.

Supervising agent actions and dealing with incorrect decisions may also create recurring costs.

Without suitable evidence from production environments, broad claims about higher conversion rates, lower service costs or autonomous revenue growth are not justified.

9. Structural Limits and Criteria for Platform Change

Missing standard functionality is not necessarily a platform constraint

In established commerce environments, a platform replacement often enters the discussion when new requirements can only be implemented with additional effort.

That alone does not justify migration.

The first question should be whether the requirement genuinely falls outside BigCommerce's technical capabilities.

A feature may be available in another edition, through a supplementary application or via a manageable integration.

In other cases, the difficulty arises from poor data quality, unclear business processes or organisational weaknesses.

Replacing the commerce platform would not automatically resolve those problems.

Where structural limits may arise

Structural constraints become significant when business-critical requirements demand changes to the commerce core that the SaaS model does not permit.

Extensive custom integrations can also produce an architecture whose long-term operation becomes disproportionately demanding.

This may arise with complex B2B contractual structures, unusual pricing mechanisms, highly customised checkout processes or sophisticated omnichannel requirements.

The decisive question is not merely whether a requirement could technically be implemented through further development.

It is whether the resulting solution remains stable, maintainable and economically sustainable.

Extension before migration

Before pursuing migration, merchants should examine the available options for extending their existing environment.

These include BigCommerce capabilities, alternative licensing arrangements, B2B Edition, specialist applications, additional Commerce.com products and custom integrations.

Feedonomics provides a useful example of how product data processes can be improved without necessarily replacing the commerce core.

The same principle applies to new agentic interfaces.

Support for emerging protocols may matter to the future architecture. Introducing a new standard is not, on its own, a sufficient reason to replace an established platform.

When migration becomes justified

Platform replacement becomes a defensible option when important business requirements demonstrably cannot be met, or can be met only at disproportionate cost or operational risk.

Both the structural limitations of the existing solution and the economic and organisational consequences of change need to be examined.

Existing integrations, data models, custom functionality and internal expertise all have value.

Migration creates new technical possibilities, but it also changes responsibilities and introduces project risks of its own.

For mid-market trading organisations in particular, the ability to manage such a change can be as important as the technical characteristics of an alternative platform.

The decision should follow from concrete business requirements, not product announcements or an abstract preference for a supposedly more modern architecture.

10. Management Conclusion

BigCommerce combines a standardised SaaS commerce core with extensive interfaces and different storefront architectures.

For B2C, D2C and certain B2B organisations, this can provide a viable technical foundation.

The approach is particularly relevant for businesses that do not want to develop and operate all core commerce functions themselves, but still need to accommodate existing enterprise systems and individual business requirements.

B2B Edition extends the commerce core with organisation-specific purchasing capabilities. Feedonomics supports product data preparation and syndication. Makeswift adds capabilities for designing and managing digital shopping experiences.

Developments in Agentic Commerce demonstrate that BigCommerce is increasingly exposing actual commerce functions through structured interfaces.

Storefront MCP supports documented shopping actions. WebMCP extends access for suitable browser-based agents. UCP connectivity provides another technical foundation for standardised commerce interactions.

These developments matter, but their actual capabilities must be distinguished.

Access to a production-ready tool does not automatically amount to a legally binding transaction. An authenticated customer session is not unrestricted authority to act. And a documented checkout interface does not establish a fully autonomous payment and post-purchase process.

The underlying strength of the BigCommerce approach is therefore not unlimited technical openness.

It is the ability to combine standardised commerce capabilities with supplementary systems without having to operate every foundational aspect of the storefront platform independently.

Whether this produces an economically convincing architecture depends on the business model, integration requirements, organisational capabilities and the need for processes that operate consistently across systems and channels.

Organisations with clearly defined data ownership, largely standardisable core processes and a manageable integration landscape may benefit from this model.

Businesses with unusually complex commercial rules, extensive requirements for changes to the commerce core or poorly governed systems landscapes need to examine more carefully where additional responsibility arises and whether it remains sustainable over time.

BigCommerce takes responsibility for a substantial part of the technical commerce operation. It does not take responsibility for the merchant's entire trading business.

That distinction should guide the platform decision.

---

Sources and Research Context

This analysis reflects publicly documented information available up to 28 October 2026. Vendor documentation is used to establish published product capabilities and availability, not as independent evidence of economic benefits or implementation success.

The sources are grouped by subject to make the principal findings traceable.

Corporate structure and product strategy

1. Commerce.com: Introduction of the New Corporate Structure, 31 July 2025
2. SEC: Commerce.com, Inc., Corporate and Capital Market Filings
3. Commerce.com: Corporate Announcements and 2026 Restructuring
4. Commerce.com: Data Enrichment, 29 September 2026

Platform architecture, B2B and economics

5. BigCommerce: Current Plans, GMV and Payment Fees
6. BigCommerce: 2026 Pricing Changes
7. BigCommerce: REST API Rate Limits
8. BigCommerce: Custom Checkout and Checkout SDK
9. BigCommerce: GraphQL Storefront Cart and Checkout
10. BigCommerce: Makeswift
11. BigCommerce: B2B Storefront and Buyer Portal Tools

Agentic Commerce, MCP and UCP

12. BigCommerce: Catalyst 1.12.0, UCP and Storefront Session Sync, 16 September 2026
13. BigCommerce Developer Changelog, 8 October 2026
14. BigCommerce: MCP Server Overview
15. BigCommerce: B2C Storefront MCP
16. BigCommerce: B2B Storefront MCP
17. BigCommerce: WebMCP, 21 October 2026
18. BigCommerce: WebMCP Documentation
19. BigCommerce: Store Management MCP, Closed Beta

Note on currency of information: Agentic Commerce, MCP, WebMCP and UCP are evolving rapidly. Documented technical endpoints, product availability and actual support for complete business processes must be assessed separately. Individual licensing terms, regional restrictions and production integration capabilities should be verified again during any specific platform selection or implementation project.