Spryker Deep Dive: B2B Commerce, Marketplaces and the Responsibility Behind Complex Architectures

1. Executive Snapshot. Where Spryker Becomes Relevant

An industrial customer ordering a replacement part often needs considerably more than a searchable catalogue and a working checkout.

The buyer needs to establish whether the component fits a particular machine, which contractual terms apply, who is authorised to place the order and whether the expenditure falls within an approved budget. The order might need to recur at regular intervals. The product might come from a third-party merchant. In future, an AI agent might even prepare the replenishment order.

Technically, these activities can be represented as e-commerce transactions. Commercially, they belong to a much broader procurement and operational process.

This is where Spryker becomes particularly relevant.

Spryker Cloud Commerce OS is a modular commerce platform whose development has increasingly focused on demanding B2B business models. Alongside conventional commerce functionality, its capabilities cover procurement controls, recurring orders, industrial self-service processes, marketplaces and integration with existing enterprise systems.

The platform also supports B2C commerce. Its architectural characteristics become particularly significant, however, when commercial processes extend well beyond the familiar sequence of browsing, adding products to a basket and completing checkout.

The potential advantage is not necessarily the ability to develop almost any feature from scratch. More interesting is the combination of existing business capabilities and an architecture that allows organisations to adapt commerce processes to their particular requirements.

That flexibility comes with responsibilities.

Spryker demands technical expertise, a coherent integration strategy and an organisation capable of maintaining ownership of the architecture over time.

The central question is therefore not how flexible Spryker is, but which business requirements genuinely justify that flexibility.

The same distinction applies to the platform's more recent developments in agentic commerce.

Spryker now documents several AI capabilities and a Commerce MCP Server through which external AI assistants can access selected commerce operations. At the research cut-off, however, the Commerce MCP Server remains explicitly classified as an early-access preview and has not been hardened for production use. See the Commerce MCP Server technical documentation.

The technical ability to initiate a purchase does not establish that an agent has the delegated business authority to enter into a binding transaction on behalf of a customer or organisation.

That distinction runs through this assessment.

2. Market Position and Product Development. From Commerce OS to Defined B2B Processes

Spryker emerged from the idea that complex commerce requirements should be addressed through modular architecture rather than forcing different business models into a largely uniform shop structure.

The platform was designed to provide functional components from which organisations could assemble commerce applications suited to their particular commercial processes.

That principle remains visible today, although the product strategy has evolved.

Spryker increasingly positions itself around industrial and sophisticated B2B commerce. Manufacturers, distributors and organisations with complex sales and procurement structures are central to that positioning.

Recent developments within the company are consistent with this direction.

Sebastiaan Verhaar became CEO on 1 July 2026, with Stefan Ropers taking the role of Executive Chairman. In December 2025, Spryker had announced a further financing round involving TCV, One Peak and Project A.

Both developments offer useful context for understanding the company's stated direction. Neither, on its own, establishes long-term financial resilience, the quality of customer support or the commercial success of individual implementations.

The relevant company announcements are Spryker's CEO appointment and its December 2025 financing announcement.

From Technical Extensibility to Business-Ready Commerce

One of the more significant changes is the development of Spryker's B2B Business-Ready Commerce Experiences.

Earlier descriptions of the platform placed considerable emphasis on technical modularity. The 2026 releases increasingly document specific commercial processes instead.

These include recurring orders, budget and cost-centre controls, procurement functionality and workflows designed around common requirements in industrial organisations.

Product Release 202608.0 explicitly marked Recurring Orders as generally available. The same release introduced workflow infrastructure through which certain business processes can be modelled and versioned within the Back Office.

This changes the commercial assessment.

If a business has to develop a complex replenishment process entirely itself, technical flexibility may be necessary but expensive to exploit. If important elements of that process already exist as documented product functionality, the question changes.

The organisation must determine whether those functions match its actual processes and what configuration, integration or additional development is still required.

Business-ready should not, however, be confused with ready to deploy in every environment.

Even generally available features may depend on specific product versions, additional modules, configuration or contractual arrangements.

Market Presence and Customer References

Spryker has documented customer implementations across several industries, including industrial manufacturing, distribution and international commerce operations.

These references demonstrate that the platform is used in real projects. They do not necessarily establish how much of any particular implementation relies on standard functionality, how extensively it has been customised or what it costs to operate.

The same caution applies to analyst recognition.

Spryker was positioned as a Leader in the 2024 Gartner Magic Quadrant for Digital Commerce. This represents an assessment conducted at a particular point in time under the analyst's methodology. It is not independent evidence that Spryker is suitable for a particular organisation.

A defensible platform decision must therefore start with the company's own requirements, the functionality that can be demonstrated and the operational capabilities needed to sustain the resulting architecture.

3. Platform Architecture. Modularity Does Not Mean Independence

Spryker is based on PHP and incorporates Symfony components. Its architecture consists of numerous functional modules connected through defined interfaces and dependencies.

Historically, Yves as the storefront application, Zed for back-office functionality and business logic, and Glue as the API infrastructure have been among its most recognisable architectural elements.

These concepts remain important to understanding the platform.

They should not, however, be mistaken for a fixed architectural blueprint that every modern Spryker implementation must follow.

Different frontend and API development approaches are now available, and the underlying API strategy is changing.

The Different Meanings of Modularity

Several distinct characteristics need to be considered when assessing modular commerce architecture.

Code modularity allows applications to be divided into components with defined responsibilities. API decoupling enables external applications to access selected functionality through interfaces. Independent deployment concerns whether components can be released and operated separately.

Organisational independence goes further. It depends on whether teams can make changes without continually coordinating modifications across other parts of the system.

These characteristics are related, but they are not interchangeable.

Spryker's module architecture provides considerable scope for adapting business functionality. At the same time, module dependencies, shared data models and project-specific customisations can create substantial coupling.

A modular codebase is therefore not automatically an independently deployable microservices architecture.

The important question is not how many modules the platform contains. It is how those modules are used, which components are modified and what dependencies those modifications introduce.

The consequences for releases, testing and operational ownership matter more than the module count itself.

API Platform. Separating the API Contract from the Technical Infrastructure

One of Spryker's most significant architectural developments in 2026 concerns its API strategy.

Three levels need to be distinguished.

The first is the application through which an API is exposed. Spryker distinguishes between the Storefront API and the Backend API.

The second concerns the API's purpose and intended users. The Storefront API supports customer-facing commerce operations, while the Backend API can expose administrative and system-oriented functionality. The Back Office API is a particular API type within the Backend API, not another name for the entire backend application.

The third level is the technical infrastructure used to implement those interfaces.

This is where the new API Platform becomes important.

For new development, it replaces elements of Spryker's proprietary Glue REST infrastructure with more standardised Symfony and API Platform mechanisms. Resources can be defined declaratively, while validation, serialisation, routing and OpenAPI documentation follow more consistent conventions.

Spryker's API Strategy, published in August 2026, explicitly identifies the API Platform integration as generally available.

New core functionality introduced from the first quarter of 2026 is delivered through this approach. Existing Glue APIs remain supported, and Spryker has announced neither a mandatory migration nor an end-of-life date for them.

For existing customers, this provides a degree of investment protection.

Adopting the new strategy does not automatically require every established integration to be rewritten.

At the same time, this is more than another interface layer placed on top of the existing architecture.

It changes how new and migrated API resources are implemented internally. Declarative resource schemas and provider and processor components take over responsibilities previously handled through established Glue controller, reader and resource-builder patterns.

Migrated and non-migrated resources can coexist within an application.

Backwards Compatibility Still Requires Verification

Spryker describes the migration of existing APIs as broadly backwards compatible.

That matters to organisations with numerous established integrations, but it should not be interpreted as a guarantee that every existing client will behave identically under all circumstances.

The API Platform migration documentation identifies technical exceptions.

For example, some older clients that do not send an explicit HTTP Accept header can encounter changed response behaviour. In certain cases, an error response may be returned instead of the previously expected result. Spryker documents a compatibility mechanism for this situation from a specified API Platform version.

Its migration status documentation also distinguishes migrated resources from newly implemented functionality whose external API contracts are not necessarily identical.

Consequently, a practical migration assessment remains necessary.

Existing integrations need to be examined against their actual module versions, API contracts and client implementations. Automated contract tests and appropriate interface monitoring should form part of the process.

Spryker provides a migration path towards its newer API infrastructure without requiring the immediate replacement of existing Glue integrations. Compatibility remains an explicit implementation concern, particularly for older clients, module-specific dependencies and API contracts that may not be identical across newly introduced resources.

Historical Integration Approaches and Product Lifecycles

Not every integration strategy introduced during a platform's development remains a long-term product direction.

Spryker's App Composition Platform provides an example.

Previously known by the abbreviation ACP, this component is being discontinued according to the current documentation. New activations and modifications are no longer supported.

It should therefore not be presented as an unrestricted strategic option for new projects.

The terminology also matters.

In Spryker's historical architecture, ACP refers to the App Composition Platform. In the emerging agentic commerce landscape, ACP can also refer to the Agentic Commerce Protocol.

The two concepts address different problems and should not be confused.

Process Logic, Events and Technical Extension

Spryker allows organisations to model their own business processes, including through state machines within its Order Management System.

Event handling, asynchronous processing and external system integration provide further means of extending those processes.

These capabilities become relevant when a transaction triggers additional activities after checkout, such as approval, ERP processing, payment checks or fulfilment.

Technical flexibility does not, however, guarantee consistent execution across all systems.

An event may be published successfully while a downstream application rejects the request. An order may have a valid status inside Spryker while the ERP system has yet to confirm that it has processed it.

Such situations require deliberate error handling, retry mechanisms and escalation procedures.

The workflow infrastructure introduced in Product Release 202608.0 expands the options for modelling and versioning business processes. It does not automatically take over integration responsibilities or the business decisions owned by external systems.

Releases and Upgradeability

Spryker distinguishes between code releases for individual modules and broader Product Releases.

Its release documentation makes clear that individual code releases cannot be tested against every conceivable combination of other module versions.

Product Releases, by contrast, bundle defined functionality that has been integrated and tested in the corresponding Demo Shops.

The further an implementation moves away from the documented standard, the more important automated tests, controlled dependency updates and traceable release processes become.

Modular architecture can make changes easier to implement.

It does not make their consequences unnecessary to test.

The real measure of architectural quality is therefore not simply how well the platform performs during its initial implementation, but how reliably it can be changed over several years.

4. B2B Commerce and Industrial Procurement. When the Basket Is Not the Real Process

In a conventional online shop, a purchase can often be described as a relatively straightforward sequence. The customer finds a product, adds it to a basket, pays and receives a delivery.

Industrial B2B commerce is frequently more complicated.

A buyer acts on behalf of an organisation. The purchase may be governed by negotiated prices, restricted assortments and approval requirements. Expenditure might need to be assigned to a cost centre, while the resulting order must be reflected accurately in the ERP system.

Framework agreements, recurring requirements, multiple delivery locations and product-specific procurement processes introduce further considerations.

Spryker addresses these requirements through business accounts, roles and permissions, quotation and ordering capabilities, and modules for procurement control.

The distinction between documented functionality and an immediately available end-to-end process remains important.

An organisation needs to establish whether its actual purchasing hierarchy, approval rules, pricing structures and ERP processes can be supported through existing functionality or require additional development.

Procurement Control Goes Beyond User Administration

B2B permissions involve more than assigning a user to a company account.

What matters is which actions that user may take within a particular commercial context.

Spryker documents Purchasing Control capabilities covering budgets, cost centres and rules that determine how purchasing limits are enforced.

Three budget rules illustrate the different forms of control.

Under Block, an order is prevented when it would exceed the assigned budget.

Under Warn, the buyer receives a warning but may proceed with the transaction.

Under Require Approval, exceeding the budget triggers an approval requirement. The buyer cannot complete the order without the necessary authorisation.

These are not merely different messages displayed during checkout. They represent different business policies concerning expenditure and purchasing authority.

The organisation must decide which policies must be enforced and which systems hold the authoritative information needed to apply them.

Budget controls within the commerce application may be effective. They do not automatically replace every validation performed by the organisation's wider procurement environment.

PunchOut and External Procurement Systems

A related area is integration with external procurement systems through PunchOut.

A buyer can enter a supplier catalogue from an established procurement application, select products and return the basket to the purchasing workflow.

Spryker documents PunchOut functionality and integration options for scenarios involving standards such as cXML and OCI. The relevant product developments are described in Product Release 202606.0.

More demanding configurations may require additional partner solutions.

The central question is how responsibility is divided.

The external procurement application may own contractual conditions, approvals and the formal purchase order, while Spryker provides catalogue access and basket preparation.

These activities must be coordinated at both the functional and technical levels.

The existence of a PunchOut interface is not evidence that every organisation-specific approval process or ERP integration is already supported end to end.

Recurring Orders and the Limits of Automated Replenishment

Recurring Orders provides a particularly revealing example of Spryker's approach to industrial procurement.

Many organisations repeatedly purchase consumables, replacement parts and other standard items. The original decision to purchase these products may already have been made.

Yet each subsequent order can still be affected by changes in price, availability, quantity or purchasing budget.

Spryker made Recurring Orders generally available in Product Release 202608.0.

The documented functionality allows buyers to review and modify upcoming orders. They can replace products, alter quantities or add items. Changes may apply to a single execution or be retained for future orders.

Budget and cost-centre assignments can also be adjusted within the documented constraints.

What matters here is not simply the scheduling mechanism, but the management of exceptions.

Reliable B2B automation cannot assume that every replenishment order will be identical to the previous one. Products, prices, delivery options and permissions can all change.

Spryker documents validation and recovery processes, including states for order schedules that have been suspended, have failed or require review.

The standard functionality nevertheless operates within specific conditions.

The buyer must be signed in. The original transaction cannot originate from a Request for Quote process or be blocked by an approval requirement. An eligible invoice-based payment method is also necessary.

These limitations are set out in the Recurring Orders Feature Overview.

Why Approval-Based Budgets Are Excluded

An important limitation arises when Recurring Orders is combined with Purchasing Control.

Recurring orders are executed at a later point, without the buyer necessarily being present to approve the transaction.

The documented standard implementation therefore supports budgets using the Block and Warn rules, but not Require Approval.

A budget configured with Require Approval cannot be selected for a recurring order schedule. If such a budget assignment is detected during setup, checkout validation prevents the process from continuing.

This restriction also applies when the budget has not yet been exceeded at the time the schedule is created.

That is a meaningful business limitation.

Spryker supports automated replenishment within certain budget controls. Its documented standard feature does not provide an unrestricted combination of unattended order execution and approval-based purchasing.

Organisations requiring mandatory authorisation for individual orders must therefore consider another process design.

That might involve an adapted procurement architecture, an approval step before execution or additional integration. The appropriate solution depends on the actual governance requirements and the technical feasibility of enforcing them.

General availability of Recurring Orders should therefore not be interpreted as general availability of every form of automated B2B purchasing.

Self-Service Portal and Asset-Based Commerce

Spryker's industrial positioning becomes even clearer when examining its Self-Service Portal.

A machinery manufacturer or industrial distributor often sells more than independent catalogue items.

It may maintain an installed base of machines, equipment and technical components that continue to generate demand for replacement parts and services over many years.

Spryker documents a model connecting individual assets with broader machine models and lists of compatible products.

A model can represent a family of machines. An asset represents a particular machine, potentially identified by a serial number and associated with a business customer or organisational unit.

Product lists identify replacement parts or service products compatible with the relevant model.

Customers can consequently search for products in the context of their own equipment. Product detail pages can also support compatibility checks against registered assets.

This connects commerce with the customer's installed base.

For an industrial business, it creates opportunities to organise spare-parts purchasing and service activities around the equipment that customers actually own and operate.

The capability nevertheless depends on suitable data.

Machines, models and product lists must be created, maintained and connected accurately.

The asset-based catalogue documentation and its installation guidance also show dependencies on several Self-Service Portal capabilities, including Asset Management, Model Management and Service Management.

An asset-based catalogue is therefore more than an isolated search feature.

Equally, the documented compatibility functionality should not be interpreted as evidence that Spryker can automatically understand arbitrary engineering bills of materials or derive correct replacement parts from unstructured equipment data.

The underlying technical relationships must be represented in the data and processes used by the commerce application.

When B2B Depth Becomes Commercially Significant

For a manufacturer with a substantial spare-parts business, an asset-based catalogue can have considerable commercial relevance.

It changes how customers identify products, purchase services and manage equipment throughout its operating life.

The platform decision then extends beyond the immediate revenue generated through an online shop.

The importance of after-sales services, the number of machinery and product variants, the reliability of technical data and the integration required with ERP and service applications all become relevant.

These are the kinds of requirements that may justify the additional architectural demands of a modular commerce platform.

An organisation whose B2B operation consists mainly of straightforward catalogue orders with relatively few exceptions should assess whether it needs the same degree of flexibility.

The distinction lies in the actual business model, not in a general judgement about which category of commerce platform is superior.

5. Marketplaces. More Merchants Mean More Responsibilities

A marketplace introduces additional participants into the commerce process.

The operator no longer sells only its own products. It facilitates transactions involving other merchants, creating further responsibilities for product information, offers, prices, inventory, orders, payments and customer service.

Spryker provides documented marketplace capabilities covering Merchant Management, the Merchant Portal and the management of products and merchant offers.

An important architectural distinction is that between a product and a specific merchant offer.

Several merchants may offer the same product, with different prices, available quantities and delivery conditions.

From the customer's perspective, the underlying product may be identical. Operationally, the offers are distinct.

This matters particularly in B2B marketplaces where the same component may be sourced from several suppliers or distribution partners.

One Basket, Several Operational Processes

A marketplace may offer customers a single basket.

Behind that experience, however, there may be several merchant orders, delivery processes and financial obligations.

Some items might be dispatched by the marketplace operator, while others are fulfilled directly by merchants.

Different fulfilment responsibilities may apply within the same customer transaction.

Spryker documents marketplace functions for organising merchants and orders.

Actual execution still depends on the connected systems and the operator's business rules.

The presence of a marketplace module does not automatically make the platform responsible for an external merchant's inventory accuracy or fulfilment performance.

Splitting Payments with Stripe

Spryker provides a documented Stripe integration for marketplace payments.

It uses the Separate Charges and Transfers model.

Under this arrangement, a customer can make a combined payment for a basket containing products from several merchants.

The payment is initially charged to the marketplace operator's Stripe account. Merchant shares can then be distributed through separate transfers.

Spryker's commission functionality can be used to calculate how much is allocated to each merchant.

The documentation describes how commissions are calculated according to project configuration and how merchant transfers can be initiated through OMS commands.

Transfers can, for example, be linked to defined order-state transitions, time-related conditions or scheduled processes.

The corresponding implementation is described in Configure Merchant Transfers for Stripe.

This goes beyond the abstract ability to connect a payment service provider.

Spryker documents an actual integration pattern covering a combined customer charge, commission calculation and the technical initiation of subsequent transfers.

The terminology is important, however.

A transfer, in Stripe's terminology, moves funds from the marketplace operator's Stripe account to a connected merchant's Stripe account.

A payout moves funds from the merchant's Stripe account to its bank account.

Spryker's documentation occasionally uses these terms interchangeably in the context of marketplace commissions. For the design of financial processes, the distinction remains significant.

Regional Restrictions and Payment Governance

A documented integration does not mean every marketplace configuration is supported without additional work.

For the described payment model, Stripe requires marketplace operators and participating merchants to be located within the same supported region.

Other regional configurations may require a different payment arrangement or further consultation with the payment provider.

Spryker also makes clear that disabling a merchant inside the marketplace does not automatically disable that merchant's Stripe account.

Preventing further payouts may therefore require additional action on the payment provider's side.

Likewise, payment actions such as capture or cancellation need to follow the integration's prescribed Spryker and OMS processes.

If those operations are performed independently through the Stripe Dashboard, payment states in the two systems can become inconsistent.

The documented integration does not provide unrestricted multi-capture support for this configuration either.

These constraints are described in the Stripe for Marketplace integration documentation.

They are specific limitations of the payment integration, not merely generic warnings about marketplaces.

They illustrate why responsibility for a marketplace transaction continues well beyond a successful checkout.

Commissions, Refunds and Accounting

The operator must also determine which commission rules apply, when merchants become entitled to payment and how cancellations or refunds affect previously calculated amounts.

Spryker provides documented functionality for parts of this process.

That does not establish that it takes over every accounting, tax or regulatory requirement.

Invoicing, tax treatment, financial reconciliation and applicable compliance obligations need to be examined within the particular business model.

The division of responsibilities between operator, merchant and payment provider also depends on contractual arrangements, jurisdiction and the chosen payment architecture.

A technical integration cannot make these decisions on behalf of the business.

Marketplace Governance Is Part of the Business Model

Merchant qualification, product-data quality and service commitments form part of operating a B2B marketplace.

The operator must decide who approves products and offers, how inaccurate information is corrected and what happens when a merchant fails to meet agreed obligations.

Technically demanding industries may also require product certification, compatibility information, regulatory documentation and supplier approval.

Software can support these activities, but it cannot replace every underlying business decision.

Spryker's marketplace capabilities therefore provide a meaningful foundation for multi-merchant business models.

Whether that foundation becomes a viable and manageable operation depends equally on the operator's ability to govern merchant relationships, payments, data quality and fulfilment responsibilities.

6. Unified Commerce. Integration Does Not Create a Single Source of Truth by Itself

Unified commerce is frequently presented as the promise of a consistent customer experience across every sales channel.

For an architecture decision, a more practical question is required.

Which systems hold which information, and which system has the authority to resolve a conflict?

A customer might want to check product availability online, collect an item from a particular location, arrange a return later and complete the process through customer service.

To make that experience reliable, the commerce platform, ERP, warehouse management system, potentially the POS and several other applications must work together.

Spryker can act as an important commerce component within such an architecture. Its APIs, modules, event mechanisms and OMS processes support different integration models.

The existence of these technical capabilities does not, however, establish that a fully integrated unified commerce operation is available out of the box.

Ownership of Business Data

Prices, inventory, customer identities and order status are particularly sensitive.

An ERP system may manage the authoritative contractual terms while Spryker presents the resulting prices to customers.

When a contract price changes, the organisation must decide when that change becomes effective in the commerce application.

It also needs a policy for situations in which the price at checkout differs from the price originally displayed during product selection.

Inventory creates similar challenges.

Showing that a product is available is not the same as reserving it.

Actual delivery capability depends on warehouse processes, update intervals and the chosen system architecture.

With multiple warehouses, physical stores or third-party merchants, coordination becomes more demanding.

Spryker documents inventory and reservation-related functionality. Product Release 202608.0 also describes improvements to reservation aggregation across multiple plugins and warehouse configurations.

This represents a specific technical building block.

It does not eliminate the need to establish which system has final authority over availability and allocation.

The question of unified data is therefore less about the number of available interfaces and more about clearly assigned ownership of business information.

The Role of the Order Management System

Spryker's Order Management System uses state machines to model order states and transitions.

Orders can move between states depending on defined conditions. Events and commands can initiate further activities, such as payment checks, approval processes or handovers to external applications.

This enables detailed process control.

It does not mean that Spryker automatically controls every participating system.

When an order is passed to an ERP or warehouse management system, the architecture needs confirmation of what actually happened.

Failures must be detected and, where appropriate, operations retried.

Repeated messages must not produce unintended duplicate orders or accounting entries.

The business consequences of cancellation also need to be defined.

Once a warehouse has started processing an order, a customer's cancellation request may not be fulfilled simply by changing the order status in Spryker.

The state machine therefore models and controls an important part of the process.

Reliable end-to-end orchestration also requires appropriate integrations and clearly defined responsibilities.

Unified Commerce Is an Organisational Decision

This is especially relevant to businesses that have developed multiple sales channels and operating divisions over time.

They frequently maintain different sources of customer, product, pricing and stock information.

Introducing a new commerce platform does not automatically resolve those differences.

If Spryker is implemented without clear business ownership, it may simply add another integration landscape in which existing problems appear in new places.

Equally, Spryker can serve as a central commerce component when the roles of surrounding applications have been deliberately defined.

It does not have to become the authoritative system for every type of data or process.

A viable architecture can contain several systems of record, provided their responsibilities, interfaces and conflict-resolution rules are consistent.

A unified customer experience does not necessarily require one physical data store. It does require clear responsibility for the information and decisions on which that experience depends.

7. Agentic Commerce. An Interface Is Not a Mandate to Act

The emergence of agent-driven commerce places new demands on existing commerce architectures.

Many transactions are still initiated directly by a human user. A customer finds a product, reviews the conditions and confirms an order.

AI agents can take over some of that work.

They may research product information, compare alternatives, prepare a basket or perform certain actions through technical interfaces.

This changes how commerce capabilities need to be exposed.

An architecture must provide not only information intended for human users, but also structured operations that software agents can execute reliably.

Spryker is developing several AI components for different purposes.

They should not be treated as one unified agentic commerce product, nor should they be assumed to share the same level of availability.

AI Foundation and Internal Commerce Assistance

AI Foundation provides an abstraction layer through which different AI providers and models can be connected to Spryker applications.

The documentation describes support for several providers and the configuration required to use them.

A range of AI commerce capabilities builds upon this foundation.

Smart PIM assists with editing, translating and enriching product information. Smart CMS supports selected content creation and editing activities. Search by Image enables image-based product searches.

Further capabilities cover visual order preparation and assistance with administrative operations in the Back Office.

These functions form part of Spryker's documented AI Commerce portfolio.

AI Foundation is therefore a technical foundation for different applications.

It is not itself an autonomous purchasing agent.

Nor do all the applications built around it automatically have identical availability or maturity.

Using a particular capability may require the relevant modules, installation steps, provider configuration and access to appropriate AI models.

Listing a function within the AI Commerce portfolio does not establish that it is immediately available in every Spryker implementation.

AI Functionality Still Requires Business Control

AI-assisted product-data management can reduce manual effort and support the maintenance of large catalogues.

It does not replace an authoritative source of product information.

A model might improve a product description without verifying every technical specification.

An image-based search may identify plausible products without establishing that a particular replacement part is compatible with a machine.

In industrial commerce, the provenance and authority of information therefore remain critical.

AI-generated content should not become the unquestioned source for technical compatibility, binding contractual terms or regulatory product characteristics.

Likewise, the provider abstraction offered by AI Foundation does not remove all questions about data protection and processing.

Organisations still need to establish what information is sent to which models, under what contractual conditions it is processed and how access permissions, costs and logging are controlled.

AI Dev SDK and AI Dev MCP Server

Another distinct part of Spryker's AI strategy concerns platform development and maintenance.

AI Dev SDK supports agent-assisted development workflows, including customisation, upgrades and bug fixing.

Product Release 202608.0 documents, among other improvements, a guided upgrade workflow and enhanced processes for managing individual changes and resolving defects.

AI Dev MCP Server makes development-related information and tools available to supporting applications.

These components are not designed to conduct customer purchases.

They help developers and project teams work on Spryker applications.

The distinction matters because a development tool and a commerce interface may both use MCP while serving entirely different purposes and requiring different access controls.

Nor does the existence of AI-assisted development workflows automatically establish measurable reductions in implementation or maintenance costs.

Generated changes must still be reviewed, tested and approved within the actual project architecture.

Commerce MCP Server. Exposing Commerce Operations to Agents

For agentic commerce itself, the most directly relevant component is Spryker's Commerce MCP Server.

The Model Context Protocol enables AI applications to interact with external systems through defined tools.

Spryker's Commerce MCP Server exposes selected operations from its Storefront API.

The documented capabilities include product search, product information, authentication, basket operations, checkout and access to order information.

This enables an AI application to initiate certain commerce activities programmatically.

An assistant could, for example, search for a replacement part, evaluate the information returned and prepare a basket without requiring a human user to navigate each step in a conventional storefront.

That is a relevant extension of how commerce functionality can be accessed.

It does not mean that the interface assumes responsibility for the entire transaction.

Production Readiness and Documented Limitations

The technical documentation updated on 22 June 2026 explicitly describes Commerce MCP Server as an early-access preview.

It is intended for demonstration, evaluation and prototyping.

Spryker states that its security mechanisms and error handling are simplified and have not been hardened for production use.

For production implementations, the vendor directs customers towards its Professional Services organisation.

The functional scope is also limited.

Complex product types and configuration scenarios are not fully covered. Checkout in the preview uses a demonstration payment method.

A complete MCP-based process for returns, refunds, marketplaces and merchant operations is not documented as part of the available preview.

The limitations are described in the Commerce MCP Server feature documentation.

The preview demonstrates that important commerce operations can be exposed through MCP.

It does not establish the availability of a production-ready solution for autonomous, legally binding purchasing processes.

Three Levels of Authorisation

The key challenge is not simply whether an agent can submit an order.

The organisation must establish the authority under which it acts.

Three levels need to be distinguished.

Technical authentication establishes which account and API resources an actor can access.

Delegated business authority determines which decisions that actor may make on behalf of a customer or organisation within an explicitly defined mandate.

Payment authorisation governs the circumstances in which a binding payment can be initiated.

These levels may be connected technically, but they are not the same.

An agent might have access to a company purchasing account without having delegated business authority to place orders above a specified value.

Likewise, a user might be permitted to select products but not to approve a new supplier or change a registered payment method.

These differences are particularly important in industrial procurement.

Agent-Assisted Spare-Parts Procurement

Consider a business operating several machines supplied by the same manufacturer.

An AI agent is asked to review recurring spare-parts requirements and prepare suitable replenishment orders.

It first needs reliable information about the equipment concerned and the components compatible with it.

Spryker's Self-Service Portal can provide relevant product information where machine models, assets and product lists have been maintained correctly.

The agent must then consider the applicable procurement conditions.

These might include contractual terms, available budgets, permitted delivery locations and approved suppliers.

Spryker's B2B and Purchasing Control functionality can represent parts of those rules within the commerce application.

But this does not determine the extent of the agent's delegated business authority.

May it select an alternative product when the preferred component is unavailable? Must it seek approval when the price changes? May it modify an existing replenishment schedule? And what happens when an order is assigned to a budget that requires formal approval?

The documented limitations of Recurring Orders illustrate that approval-dependent purchasing cannot simply be combined with unattended order execution.

The same underlying issue applies to an autonomous agent, even if its technical execution model is different.

An API capable of creating a basket does not determine whether that basket may become a binding order without human approval.

Audit Trails, Revocation and Error Handling

A production-grade agentic procurement process also requires decisions to be traceable.

It must be possible to establish who instructed the agent, the limits of its mandate and the information on which a particular action was based.

When delegated authority is revoked, the agent must not continue acting indefinitely under a previously valid mandate.

Individual technical permissions may also need to be revoked independently, depending on the identity and access model.

Errors and exceptions require explicit rules.

A failed checkout must not be retried indiscriminately if repeated execution might create several binding orders.

A price change may require fresh confirmation. An unavailable product might not be replaceable without additional approval.

A meaningful audit trail therefore needs to record more than a technical API call.

It must connect the principal, the mandate, the relevant permissions, the action executed and its result.

The currently documented Commerce MCP Server does not provide evidence of a generally available, complete production solution for this form of end-to-end governance.

What About Other Agentic Commerce Protocols?

Several approaches are being discussed alongside MCP in the wider agentic commerce landscape.

They include Universal Commerce Protocol, Agentic Commerce Protocol, Agent Payments Protocol, WebMCP and agent-to-agent communication.

These address different technical concerns, from structured product access and tool invocation to communication between agents and payment authorisation.

For a Spryker assessment, the important question is which of these approaches the platform actually implements, under which conditions and at what level of availability.

At the research cut-off, MCP is specifically documented through the Commerce MCP preview.

The reviewed Spryker product sources do not provide equivalent evidence of generally available, native end-to-end implementations of the other protocols.

Individual integrations through APIs may still be possible.

Technical extensibility, documented protocol support and production-ready business processes are distinct capabilities.

Agentic Commerce Requires Better Decision Architecture

As AI agents begin to act more frequently on behalf of customers and businesses, existing rules governing identity, pricing, inventory, budgets and approvals do not become less important.

They are increasingly applied through software interfaces, often without direct human involvement at every stage.

This presents an interesting opportunity for Spryker because the platform already has extensive commerce and B2B process capabilities.

Whether these can support production-grade agentic procurement also depends on identity and policy systems, payment providers, ERP integrations and the agent application itself.

An agent can execute a business process responsibly only when the organisation has established which decisions it has delegated authority to make.

Agentic commerce is therefore not simply another interface category. It exposes the quality of the underlying process and decision architecture.

8. Implementation and Economics. What the Architecture Demands Over Time

An economic assessment of Spryker cannot begin and end with the licence fee.

Licensing, cloud operations and support are relevant cost components. In a highly customised commerce environment, however, substantial additional expenditure can arise from design, integration, data migration, development and long-term maintenance.

In complex B2B and marketplace projects, these activities may carry considerable economic weight.

The essential distinction is between requirements addressed by existing product capabilities and those that demand project-specific solutions.

Understanding the Actual Project Scope

A Spryker project may involve a relatively well-defined commerce application.

Alternatively, it may require the redesign of significant parts of an organisation's sales and procurement architecture.

In the latter case, Spryker is only one component of the wider initiative.

A machinery manufacturer introducing an asset-based spare-parts shop needs more than the appropriate storefront functionality.

It also requires a dependable structure for technical product information, machine models and customer assets.

Existing ERP and service processes must be integrated, while responsibility for maintaining the data needs to be established.

Similar considerations apply to B2B marketplaces.

Merchant onboarding, payment processing, commission accounting, fulfilment and external product information are not solely responsibilities of the commerce platform.

The economic scope of a project therefore reflects the changes required across the wider process and systems landscape.

Cloud Operations and Application Responsibility

Spryker provides a cloud operating model in which parts of the infrastructure are operated and monitored by the vendor.

This does not transfer every operational responsibility away from the customer or implementation partner.

The Spryker monitoring documentation distinguishes between monitoring the production cloud environment and monitoring the application itself, which remains the responsibility of the customer or partner.

A commerce application can be available while important business processes are failing.

An order might not reach the ERP system even though the storefront remains accessible.

An incorrect pricing rule might cause financial damage without producing a technical outage.

A viable operating model therefore needs to monitor both technical availability and the correct execution of business processes.

Implementation Partners and Architectural Knowledge

Spryker projects are frequently delivered with specialist implementation partners.

Their expertise can be valuable for demanding B2B and integration initiatives.

Partner selection should not, however, rely solely on certification or an established relationship with the vendor.

The relevant question is whether the partner has the capabilities required for the intended architecture.

These may include Spryker module expertise, PHP and Symfony, API integration, process modelling, data architecture, automated testing and the selected operational tooling.

Industrial self-service projects also benefit from an understanding of equipment, spare-parts and service data.

Marketplace projects introduce further requirements around merchant operations, payment processing and fulfilment.

The long-term availability of architectural knowledge matters just as much.

An organisation does not necessarily need to maintain every technical skill internally. It should nevertheless remain capable of understanding its principal architecture decisions and assessing their commercial consequences independently of any single service provider.

Total Cost of Ownership and Total Cost of Change

Total Cost of Ownership covers the long-term costs of running the system.

These include licensing, cloud operations, maintenance, support, monitoring and the technical expertise needed to sustain the platform.

For a modular and adaptable architecture, that perspective is necessary but incomplete.

Total Cost of Change is equally important. It describes the effort involved when the organisation needs to implement new business requirements.

A company might expand into additional countries, introduce a different procurement model or onboard new marketplace merchants.

The cost of those changes depends on more than whether suitable features exist.

The degree of customisation, dependencies between modules and quality of the integration architecture all influence the work required.

A well-structured modular solution can make future development more manageable.

A heavily customised implementation with numerous interdependencies can make even relatively modest changes expensive.

Spryker's newer API strategy and increasingly packaged B2B capabilities may improve this position.

Whether they actually reduce cost needs to be assessed against the specific installation.

Platform Economics Cannot Be Generalised

There is no sufficiently robust set of publicly available Spryker project budgets that can reliably represent different business models and organisational sizes.

A largely standard B2B shop and an international marketplace integrated with several ERP systems may use the same commerce platform while having entirely different cost structures.

Broad comparisons with other commerce platforms would be equally unhelpful without consistent requirements and comparable project assumptions.

A defensible economic assessment must therefore begin with a defined scope.

It should consider existing systems, required integrations, data quality, the degree of customisation, operational responsibilities and anticipated changes to the business model.

Such an assessment may demonstrate that Spryker is economically appropriate despite substantial technical requirements, because its capabilities support important commercial processes.

It may equally show that an organisation has little need for the available architectural freedom.

Both are legitimate outcomes of an independent platform assessment.

9. Structural Limits. When Development Makes More Sense Than Replacement

When assessing an existing commerce platform, the absence of a particular feature is often treated as evidence of a structural limitation.

That conclusion does not always follow.

A requirement might be met by an existing module. It might require a new integration or a controlled custom extension.

Sometimes the underlying problem is outdated data, unclear responsibilities or an implementation that has not been maintained adequately.

For a modular platform such as Spryker, distinguishing between these situations is particularly important.

A Missing Feature or a Missing Implementation?

An organisation might discover that its current Spryker shop does not adequately support recurring B2B orders.

This does not establish that Spryker is fundamentally unable to address the requirement.

Recurring Orders is now a documented product capability that may simply not be present in an older implementation.

The cost and feasibility of introducing it will depend on the existing module versions, technical prerequisites and process changes required.

Similar questions arise with API Platform and the Self-Service Portal.

The first step is to establish whether the gap can be addressed through an upgrade, an additional component or a controlled extension.

Only when those options prove technically, operationally or economically unsustainable does the platform limitation itself become the decisive issue.

When Customisation Becomes a Structural Risk

The reverse problem is equally possible.

Technical extensibility can encourage organisations to respond to every new requirement with more custom development.

Over several years, this may produce a highly individualised system landscape.

The underlying platform remains in place, but its continued development becomes increasingly dependent on project-specific components, adapted data models and the knowledge of particular teams.

Upgrades may become more demanding, testing cycles longer and changes riskier.

This does not necessarily mean the original platform choice was wrong.

It may indicate inadequate architectural governance.

The important distinction is between complexity that genuinely follows from the business model and complexity introduced by previous technical decisions.

Spryker's development towards more packaged B2B capabilities makes this question especially relevant.

Existing customers should investigate whether newer product functionality could replace parts of their custom implementation over time.

Any such migration must preserve the necessary business capabilities and offer a credible economic benefit.

Agentic Commerce Is Not, by Itself, a Reason to Change Platforms

The growing adoption of AI-assisted purchasing may encourage businesses to reconsider their existing commerce platforms.

That should not lead to a replacement decision simply because another vendor has announced an agent interface or published an impressive demonstration.

What matters is which business processes actually need to be supported.

For some scenarios, existing commerce APIs, supplementary agent services and suitable identity and authorisation infrastructure may already provide a viable integration approach.

Spryker's Commerce MCP Server also demonstrates that the platform itself is developing new ways of exposing commerce operations to agents.

Its present preview status is a limitation.

It is neither evidence that Spryker is structurally incapable of supporting agentic commerce nor proof that production readiness has already been achieved.

Platform decisions should rest on demonstrated requirements and capabilities, rather than the mere availability of a new protocol.

When a Platform Change Deserves Serious Consideration

Replacement becomes a credible strategic option when essential business requirements can no longer be addressed sustainably within the existing architecture.

The reasons might include genuine technical constraints, disproportionate integration costs or operational risks that cannot be controlled at an acceptable cost.

The organisation's own capabilities also matter.

If it cannot realistically govern the complexity of the required architecture over time, a different systems approach may be more appropriate, even when the current platform could technically provide the functionality.

Such a decision must nevertheless account for existing investments, integration risks and migration consequences.

Changing the commerce platform does not automatically correct product data, ERP processes or unclear organisational ownership.

It may even make established problems more difficult if they remain unresolved during migration.

The useful question is not whether another platform appears more modern. It is whether that platform can address the organisation's actual problems more effectively under realistic conditions.

10. Management Conclusion. The Right Architecture, with Sustainable Ownership

Spryker addresses commerce organisations whose business processes demand more than a standard product catalogue and checkout.

Its modular architecture allows extensive adaptation and integration.

At the same time, the product offering is evolving towards more concrete business capabilities for industrial procurement, self-service and marketplace models.

Recurring orders, purchasing controls and asset-based spare-parts catalogues demonstrate how Spryker's technical architecture can be connected to specific commercial requirements.

That combination may be valuable to organisations whose business models require a more differentiated commerce architecture.

The potential advantage, however, does not arise from functionality alone.

It depends on whether the organisation can maintain reliable data, manage integrations and develop the architecture sustainably.

API Platform illustrates how Spryker is modernising its technical foundations without forcing existing customers to replace their Glue integrations immediately.

The AI strategy adds another dimension.

AI Foundation and AI Dev SDK support different activities across the commerce and development landscape. Commerce MCP Server creates a technical route towards agent-accessible commerce processes, but remains a preview that has explicitly not been hardened for production at the research cut-off.

The emergence of agentic procurement highlights a fundamental limit of technical flexibility.

A system may be capable of accepting an order without determining who has delegated business authority to place it.

For B2B organisations, budget rules, contractual conditions, approvals and traceable responsibility are not peripheral details.

They are essential to controlled procurement.

When selecting a new platform, the first task is therefore to establish which business requirements genuinely justify a modular architecture.

For an existing Spryker implementation, the more immediate question is which needs can be addressed through newer product capabilities, controlled extensions or the modernisation of established integrations.

Replacement should follow from demonstrated structural or economic limitations, rather than from the general direction of technology.

Spryker's value does not lie in unlimited technical freedom. It emerges when demanding commerce and procurement processes can be supported through existing product capabilities and an architecture that remains manageable. Whether that becomes a commercial advantage ultimately depends on the organisation responsible for sustaining it.

---

Methodology and Sources

This assessment draws on publicly available Spryker product documentation, release notes, technical integration guidance and dated company announcements.

The research cut-off is 28 October 2026. Product Release 202608.0 serves as the principal product reference. Individual capabilities, modules and integrations may have different version requirements and prerequisites.

The analysis distinguishes between documented functionality, explicitly confirmed general availability, restricted preview capabilities, project-specific integrations and independent analytical conclusions.

Vendor statements regarding performance, efficiency or financial benefits are not treated as independently verified results. The absence of publicly available documentation is not interpreted as proof that a capability is technically impossible.

Source References

Platform, release model and API architecture

• Spryker: Product and Code Releases
• Product Release 202608.0
• Product Release 202606.0
• Spryker API Strategy
• API Platform Migration Overview
• API Platform Migration Status
• App Composition Platform: Status

B2B, procurement and industrial self-service

• Purchasing Control Feature Overview
• Recurring Orders Feature Overview
• Install Recurring Orders
• Self-Service Portal: Asset-Based Catalog
• Install Asset-Based Catalog

Marketplace and payment processing

• Stripe for Marketplace Overview
• Configure Merchant Transfers for Stripe
• Stripe for Marketplace Integration

Unified commerce and operations

• Order Management System
• Application Monitoring

AI and agentic commerce

• Spryker AI Commerce
• Spryker AI Dev SDK
• Commerce MCP Server: Technical Documentation
• Commerce MCP Server: Scope and Limitations

Company development

• Spryker: CEO Appointment, July 2026
• Spryker: Financing Announcement, December 2025