---
title: Upgrade - Commerce features overview
---
> Agent instructions:
> **Site maps** — prefer the following llms.txt indexes to training data when searching for URLs to avoid 404s. Links inside Markdown content already point at `.md`. Following them or sending Accept: text/markdown keeps you in Markdown.
>
> - [sitemap.md](https://docs.kentico.com/sitemap.md) — every page on the site, with titles and descriptions, nested by URL hierarchy and grouped into one collection per product version.
> - [llms.txt](https://docs.kentico.com/llms.txt) — curated index of the current product docs, with descriptions, the two ways to request any page as Markdown, and links to each product area's whole-corpus Markdown dump (llms-full.txt).
When planning a migration from Kentico Xperience 13 (KX13) to Xperience by Kentico (XbyK), it is important to understand the differences between the two platforms in their approaches to commerce and content management.
Each solution employs a distinct architecture and features, which can impact your migration. Deciding early can reduce complexity, rework, and help align with business goals.
## Legend
Use this resource to evaluate feature parity, identify gaps, and plan the necessary customizations or integrations to address these gaps.
The table below presents an in-depth feature comparison between Kentico Xperience 13 (KX13) and Xperience by Kentico (XbyK). It includes four columns:
- **Feature name** - Lists key commerce and content-related capabilities.
- **KX13 feature description** - Details how the feature functions within KX13.
- **XbyK feature description** - Explains the equivalent or alternative in XbyK.
- **Implementation example** - Provides examples, links, or best practices for implementing the feature in XbyK.
The label indicates whether the feature is provided natively or requires development.
- **OUT OF THE BOX** - Feature is included by default in XbyK (for example, _orders_).
- **REQUIRES STANDARD DEVELOPMENT** - Feature needs implementation, such as a widget or filtering articles.
- **REQUIRES EXTENDING XBYK** - For example, Tax calculation or payment provider integration require extending built-in features.
- **REQUIRES CUSTOMIZING XBYK** - For example, _credit history_ or _membership subscriptions_ need custom logic and XbyK UI extension.
| **Products catalog** | | | |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feature name | KX13 feature description | XbyK feature description | Implementation example |
| Product (SKU) | KX13 uses SKU-based commerce. Products are SKUs, optionally linked to CMS pages, which support content features such as workflow and multilingual options. See details in the [documentation](https://docs.kentico.com/13/e-commerce-features.md) | **OUT OF THE BOX**
XbyK products are content items in the Content hub or as website pages with [structured data](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/structured-and-unstructured-content.md). No dedicated SKU objects exist out-of-the box.
This content-centric approach enables powerful features like versioning, localization, and workflows, giving you the flexibility to shape your product data model as needed. See detailed description of XbyK's [commerce capabilities](https://community.kentico.com/blog/xperience-by-kentico-refresh-april-17-2025#digital-commerce). | Follow the recommendations how to [model product catalog](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/model-product-catalog.md). |
| Product filters | Product filtering is in the live site app. Customers filter by product attributes, such as manufacturer or resolution.
Filtering can utilize page properties, SKU properties, or linked data, such as manufacturer or status.
Developers create customized filtering experiences based on the product data structure. | **REQUIRES STANDARD DEVELOPMENT**
XbyK product specifications and attributes are custom fields defined in the content type.
Developers use taxonomies or custom properties in queries, as well as [reusable field schemas](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md).
For example:
Define taxonomies for categories like Laptop Features (e.g., external GPU, disc drive, screen size).
Editors tag products with these values.
Developers configure listing components (e.g., widgets) to filter products by selected tags.
This approach allows editors to manage filters without developer involvement once they are implemented. | Product content types should use standard content categorization. See available options in [model taxonomies](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/model-taxonomies.md).
When building nested filters, developers must carefully design and optimize queries. |
| Display product details | KX13 commerce sites included catalog and product detail pages.
Customers filter products by brand, price, or size. Developers delivered logic to display data, with optional images and other product details. | **REQUIRES STANDARD DEVELOPMENT**
XbyK uses a content-centric model. Teams tailor product displays for marketing and commerce. Products are managed as content items or pages, presented in the same manner as any other content.
Developers build templates or widgets for product listings, detail views, comparators, or related products.
Editors can also leverage built-in **image transformations** to create responsive, optimized product images for different devices. | Use recommendations in the [Product fields](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/model-product-catalog.md#product-fields) section. |
| **Products** | | | |
| ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feature name | KX13 feature description | XbyK feature description | Implementation example |
| Standard products | KX13 standard products are managed as SKU records in a dedicated commerce system.
Products contain information about pricing, inventory, and transactions, and are stored in a dedicated table. Linking to content pages adds multilingual, SEO, or similar web data, but core product data remains in the commerce system and doesn't support language variants or translations.
This setup made it easy to manage products for selling online, with strong support for pricing, inventory, and other commerce features. | **OUT OF THE BOX**
XbyK products are treated as content items, not specialized commerce objects.
A content-first approach lets editors create products as flexible content types.
There's no dedicated SKU table. Product data is stored in defined content fields (name, price, images, etc.). Products built with content leverage features like versioning, localization, and workflows.
This model is flexible but needs extra development for commerce-specific features. | **How to improve editor XbyK?**
Use reusable content types or structured page data for product info. When importing from ERP, store all or key product data in XbyK. Developers must map databases properly.
Use [Content management API](https://docs.kentico.com/documentation/developers-and-admins/api/content-item-api.md) to synchronize the XbyK product catalog with external ERP/PIM. |
| E-products | KX13 supports e-products, such as digital downloads, through a built-in functionality.
E-products are managed in a separate table. Editors added downloadable files with features such as expiration dates, download limits, and secure access tokens. This allows selling digital goods, such as PDFs, software, or media, with built-in controls. | **REQUIRES EXTENDING XBYK**
XbyK doesn't natively support e-products or digital downloads.
XbyK utilizes a content-first architecture, enabling you to model digital products as custom content types. XbyK restricts access to resources for registered users to ensure secure downloads. Editors can set expiration dates for content types. | **How to add e-products to XbyK?**
To replicate e-product functionality, you should define a **custom content type** in the Content hub or as a website page. Here's a recommended structure:
**Content Type: Digital Product**
Reusable: (depends on the selected [content modeling approach](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/design-website-content.md#create-and-organize-website-channel-content))
Fields:
_ProductName_ (Text, required)
_ProductCode_ (Text, unique, required)
_Price_ (Decimal, required)
_Description_ (Rich text)
_ProductImages_ (Reference to [asset](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-files.md) content types)
_DownloadFile_ (Asset or secure file reference)
_DownloadLimit_ (Integer – Max number of downloads)
_ExpirationDate_ (DateTime – Access expiration)
_Access Rule/Token_ (Text – For secure access, generated after processing and, for example, tied to a _membership_)
_AvailabilityStatus_ (Multiple choice – e.g., Available, Expired)
Implementation notes:
**Secure access**: Implement token-based download links that expire or validate against customer order history.
**Download tracking**: Store download counts per customer/order in a custom module.
**Ordering digital products**: Link digital products to orders and trigger access provisioning post-purchase.
**Handing expiration**: Use scheduled tasks or event handlers to disable access after expiration (e.g., archive product). |
| Membership | Kentico 13 supports membership products through dedicated system tables. When a user purchases a membership:
The system automatically assignes a role, granting access to the appropriate resources.
Memberships support validity periods, allowing time-based access control.
The system can send expiration notifications to users as their membership neared its end.
Businesses can offer access-based products, such as subscriptions or gated content, with minimal custom development. | **REQUIRES CUSTOMIZING XBYK**
XbyK does not currently offer native support for **membership products** or expiration notifications. To replicate the membership functionality available in Kentico 13, developers must implement custom solutions. | **How to add Memberships to XbyK?**
Providing subscription-like products in XbyK requires custom development. To enable membership-like features, the following components must be developed:
Create a custom **Membership/Subscription** (product) content type and use custom logic to assign an appropriate _membership_ tier after purchasing this product. When a customer purchases this product, assign the respective role.
[Membership roles](https://docs.kentico.com/documentation/developers-and-admins/development/registration-and-authentication.md): Assign roles to live site members to enable [targeted promotion eligibility](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/customer-eligibility-customization.md) and similar benefits.
Validity Tracking: Add fields to store and manage membership start and end dates.
Expiration Notifications: Set up custom scheduled tasks and custom email flows to notify members when their membership is about to expire.
Renewal: Depending on the requirements, the membership purchase flow should follow the standard [checkout process](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/checkout-process.md), including automated order creation, e.g., via scheduled task, notifications, and other project-specific requirements.
Access Management: Use [restricted (secured) access](https://docs.kentico.com/documentation/business-users/website-content/secure-pages.md) to protect resources based on membership status. Implementation depends on how you approach building your membership product and handling content relationships. |
| Bundles | KX13 product bundles group multiple products into a single purchasable unit. Bundles are treated as a distinct product type, identified in the SKU record.
Bundles are defined in a dedicated table, and each bundle can include multiple products with specific quantities.
KX13 automatically handles inventory updates for each item in the bundle when a customer purchases the bundle. | **REQUIRES CUSTOMIZING XBYK**
XbyK does not offer native support for product bundles. There is no built-in structure or API for defining bundles, managing their inventory, or handling bundle-specific pricing. Replicating the feature requires re-implementing both the backend logic and the frontend presentation. | **How to add bundles to XbyK?**
To support bundles in XbyK, developers must build the entire system from scratch using custom content modeling and logic. This involves:
Modeling bundle relationships depends on project-specific requirements. For example, you can start using linked content items to create bundles (e.g., a “Bundle” content type that links to multiple “Product” items). The “bundles” implementation will also be influenced by different aspects, such as bundle-specific pricing requirements, catalog/bundle complexity (e.g., complex bundles might need some custom-optimized data queries for updates and removals), or whether (and then how) the store deals with stock inventory.
Custom cart logic to represent bundled items correctly during checkout.
Inventory deduction for each item in the bundle when a bundle is purchased.
Pricing aggregation to calculate the total price of the bundle, possibly with bundle-specific discounts, or bundle-specific prices to avoid complex discounts.
Order processing logic to ensure bundled items are correctly represented in orders and inventory is updated accordingly.
Cross-sell/up-sell behavior to promote bundles or their components in the storefront.
Additionally, you will need to decide on how to handle several key aspects. Namely, you might want to extend the administration with a custom interface that store managers will create and manage bundles. Then, you’ll need to implement storefront logic, including custom components to display bundles, processes to handle bundles when the customer selects them, and manage system-level events, such as storing the types of products the customer purchased in custom activities. |
| Product images, documents | KX13 product images are managed using the standard [media library](https://docs.kentico.com/13/managing-website-content/working-with-files/media-library-files.md). Each product (SKU) can have one or more images linked to it, typically stored as _media files_.
Store managers (or custom synchronization) upload images to KX13 and associate them with products (manually or via API from a 3rd-party system).
Developers ensure that images are sized and positioned correctly for different devices. Commonly, developers implement custom logic to optimize image sizes and make them responsive to different screen sizes. | **OUT OF THE BOX**
XbyK product images are part of the product content item. Images are asset content types stored in the Content hub.
Images are stored as **asset content types** linked to the Product content type.
The system uses [AIRA AI features](https://docs.kentico.com/documentation/business-users/aira.md#image-processing) to automatically optimize the image and create image variants for different screen sizes.
You can manage multiple images, and they support **versioning** and **localization**.
This makes it easy to maintain consistent product visuals across languages and devices. | **Product images**
Use the Out of the box feature. If you have images in an external solution, use [API to import files](https://docs.kentico.com/api/content-management/content-items.md) (with an option to optimize images after import).
**Product documentation**
You can build dedicated content types for image/document files, as recommended in the [Content modeling guide](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-files.md#content-types-for-non-image-files)
In the most basic implementation, you can build an _Asset_ content type with:
Content asset uploader component
Tag selector component that targets a dedicated [taxonomy group](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/model-taxonomies.md#taxonomies-in-xperience-by-kentico). |
| Product options | KX13 features built-in support for product options, such as size, color, or custom text. These options are grouped into categories and linked to products. KX13 provides three types of options:
Selectable attributes (e.g., size, color)
Linked products (e.g., add-on items)
Text input (e.g., engraving)
Store managers can use these options to create variants, like a _red T-shirt in size M_, each with its own price and inventory. | **REQUIRES STANDARD DEVELOPMENT**
XbyK adopts a **content-first architecture**, meaning products are modeled as content items within the _Content hub_. It does not include native support for **product options**. Properties like size, color, or custom selections are stored in standard data fields, and Content hub doesn't provide a feature that dynamically combines data fields to generate product options. To achieve similar functionality to KX13 requires a custom implementation for similar product options functionality. This includes both backend data structures and frontend components. | **How to handle Product Options in XbyK?**
The complexity of implementation depends on project size and business requirements. To support product options in XbyK, developers can:
Model options as taxonomy tags, dedicated content type fields, or separate linked content items in the _Product_ content type. (For example, size and color can be stored as taxonomy fields or multi-select fields.)
Create a variant system if combinations of options (e.g., red and medium) require separate pricing or inventory management. You can approach it via _separate content items_ for each variant (and separate content types for the Product Options). Alternatively, your developers can create custom UI form components to store complex, structured data in dedicated fields (e.g., as JSON data).
Build custom UI components that customers will use to select the options on the storefront.
Implement logic for _price calculation_ based on selected options, including extending the _Discount engine_.
Inventory tracking per option or variant, e.g., using [a custom module](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/model-product-catalog/model-product-stock.md). |
| Product variants | In KX13, product variants, such as different sizes or colors of a product, are managed using a built-in variant system.
The store manager defines option categories (e.g., Size, Color) and links them to products. Each variant (e.g., “T-shirt – Medium – Red”) is stored as a separate product (SKU) that referenced a parent product.
The system automatically generates all possible combinations of options using the VariantHelper API. Each variant could have its own price, stock level, and image. | **REQUIRES STANDARD DEVELOPMENT**
XbyK does not have a built-in variant system since each product variant is a separate content item, typically linked to a parent product that stores shared data. Instead, your solution architects need to model product variants using content types.
XbyK allows a more flexible approach, but it’s important to carefully design your product catalog. In some cases, it may be helpful to minimize the number of variants to reduce complexity and introduce dedicated Product content types. | **How to handle Variants via content modeling?**
When handling product variants through content modeling, there are two primary approaches to consider.
**Create a reusable Product Variant content types**
Typically, you'll create one content type per **Product Option** content type. This helps developers as they will work with strongly typed objects.
The _Product Variant_ content type should include fields such as:
Variant Name (text)
Parent Product (linked item referencing a single product)
Variant Options (multiple choice for attributes like size or color)
Price (decimal for variant-specific pricing)
SKU (unique text identifier),
Inventory Level (decimal).
Approaching variants as dedicated content types gives you flexibility for scenarios, e.g., where your store admins need to manage variants as independent entities, e.g., for inventory reasons.
**Embed variant data directly within the Product content type**
If your product catalog requirements are relatively simple, you can reduce number content items, and store data for variants directly in the product content type, for example, by using a [reusable field schema](https://docs.kentico.com/documentation/developers-and-admins/development/content-types/reusable-field-schemas.md). This approach might require more custom development for UI and data handling.
To enhance the editing experience, consider adding a custom field for _Variant Options_ and implementing a custom UI control to store variant configurations (e.g., in JSON format). This will enable editors to manage complex variant structures without creating separate content items.
We recommend customizing the UI, as it is typically a one-time development effort with good reusability, which provides editors with an easy curation flow. It also simplifies content operations, as editors don’t need to create each variant item, which cuts down on the time needed for project delivery.
Choosing between these options depends on your project requirements.
If your project needs individual workflows, permissions, or detailed analytics for variants, use a separate _Product Variant_ content type.
For simpler scenarios where variants are tightly coupled with the product and do not require independent lifecycle management, consider embedding variant data within the product content type to streamline the model and reduce complexity.
You’ll need to build custom logic if you want to generate combinations or manage variant-specific pricing, stock, or images, in case you’re not syncing the data from a 3rd-party ERP system. |
| Brands | KX13 provides dedicated support for managing the brand through specialized _Brand_ commerce objects. _Products_ (SKUs) are directly linked to a brand, allowing for filtering by brand in product listings and running brand-specific promotions or offering brand-related discounts. | **REQUIRES STANDARD DEVELOPMENT**
XbyK uses a content-first approach, meaning there’s no native _Brand_ object, and you can model brand representation to match your project requirements. For example, you can leverage [taxonomies](https://docs.kentico.com/guides/digital-marketing/work-with-taxonomies/taxonomies.md) or use custom content types. | **How to handle brands and manufacturers in XbyK?**
The implementation of Brand depends on project requirements. Let’s use the “brand” as an example to simplify the explanation
**Brand as a Taxonomy tag**
In case you don’t need additional details about these, you can use Taxonomy tags. In less complex scenarios, you can create one tag for each brand.
**Brand as a reusable field schema**
If your content primarily features products from individual brands, you can also store the Brand data as reusable field schema fields.
**Brand as a reusable content type**
Start by defining reusable content types for entities like Brand. This content type should include fields such as brand name, logo, ideally stored using a custom Image/Asset content type [as recommended](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-files.md#image-content-type), and a description. Then, link assets to your _Product_ content type.
Use the _Combined content item_ selector in the _Product_ content type to add linked item fields to associate each product with its corresponding brand and/or manufacturer.
Alternatively, editors can use dedicated _taxonomy tags_ instead of the _Combined content selector_ to connect products with brands and manufacturers.
Both approaches enable filtering and dynamic display of related details, such as showing brand or manufacturer information on product detail pages or allowing users to filter product listings by brand or manufacturer.
Consider also including optional enhancements to improve usability and SEO. For example, you can create dedicated brand detail pages to boost search visibility. If your project needs hierarchical categorization, add corresponding taxonomy fields to support structured navigation. |
| Collections | KX13 supports product collections through a dedicated commerce table.
Collections enable the grouping of products for marketing, navigation, or discount purposes. Store managers can link products (SKUs) to one or more collections and organize products into themed groups (e.g., _Summer Sale_ or _New Arrivals_”\*). Collections can receive specialized collection-based discounts.
Developers can leverage collections when defining filtering and display logic in the storefront. | **REQUIRES STANDARD DEVELOPMENT**
XbyK does not include native support for collections as a commerce feature.
You can implement collections using XbyK’s content-first architecture, using linked content items or taxonomies. This provides flexibility and integrates seamlessly with XbyK’s content management features. | **How to handle collections in XbyK?**
To replicate collection functionality, you can use one of the following approaches. They are ordered from the most convenient to the least.
**Base collections on Taxonomies**
Define a dedicated taxonomy group called _Collections_, and assign collection tags to products (e.g., _Holiday Gifts_, _Clearance_). This setup works well for hierarchical or multi-tag setups. The taxonomy tree where editors select tags to assign provides an easy-to-use interface. However, with current XbyK capabilities, users cannot be restricted from modifying existing tags.
**Leverage linked content items**
Create a _Product Collection_ content type with a Combined content selector field that editors will use to refer to multiple Product content items. They can use it to group products into themes like _Summer Sale_, _New Arrivals_, or _Skiing Bundle_.
Using a dedicated content type provides an additional layer of security. When you base the collection definition on a reference to a content item, you can leverage [workspaces](https://docs.kentico.com/documentation/developers-and-admins/configuration/users/role-management/workspaces.md) and restrict editors to only assign, but not modify the collection items. Dedicated content type also supports [translations](https://docs.kentico.com/guides/digital-marketing/work-with-multilingual/multilingual-variant-of-product.md) , [versioning](https://docs.kentico.com/documentation/business-users/content-versioning.md), and [workflows](https://docs.kentico.com/guides/digital-marketing/work-with-workflows/workflows.md).
**Employ Smart folders**
Use [smart folders](https://docs.kentico.com/documentation/business-users/content-hub/content-hub-folders.md#smart-folders) in the _Content hub_ to organize products by metadata (e.g., price range, availability). Editors can use them in the _Content hub_ to improve their editorial workflows. If your collections don't need any ordering capability, developers can display them on the website storefront using dynamic delivery.
**Additional suggestions**
As _collections_ are represented by _content-first_ entities, you can use them to drive campaign landing pages or filtered product listings. If needed, add custom fields to collections for banners, descriptions, or SEO metadata. |
| Suppliers, Manufacturers | KX13 natively supports managing **Suppliers** and **Manufacturers** through dedicated commerce tables.
Store managers can directly link products (SKUs) to a supplier/manufacturer.
Businesses can track which supplier provides each product, filter or organize products by supplier or manufacturer, or support backend operations like inventory sourcing or reporting. | **REQUIRES STANDARD DEVELOPMENT**
XbyK uses the content-first approach and does not include native **Supplier** or **Manufacturer** objects or applications.
Building on this, depending on your project requirements (such as the amount of information you want to store about these entities), you can create custom content types or taxonomies. This approach provides greater flexibility and aligns with modern, composable architecture principles. | **How to add suppliers or manufacturers in XbyK?**
Let’s use the _Supplier_ entity as an example. (The _Manufacturer_ entity follows similar pattern.)
Because XbyK is content-first, the most future-proof approach is to model suppliers as tags, reusable content items linked to products, or a combination of both. In most complex scenarios, you might want to develop a custom module to handle supplier data.
The options below align with how XbyK allows you to model suppliers (content types, taxonomies, or custom modules when necessary) in your [product catalog](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/model-product-catalog.md).
**Supplier as a Taxonomy tag**
Similarly to _Brands_, you can use [Taxonomy](https://docs.kentico.com/documentation/developers-and-admins/configuration/taxonomies.md) tags to add a supplier, especially in cases when you don’t need to store any additional details about this supplier. Editors can create one tag for each supplier, which is recommended for lightweight scenarios that require filtering but limited supplier data.
**“Supplier” as a reusable content type (most common)**
To store additional supplier data, create a **Supplier** content type in the Content Hub and link it to your Product items. Depending on project requirements, suppliers can be stored as reusable items in the Content hub (most common), or as structured pages in a website channel (for simpler implementations, using a page for categorization similar to KX13 patterns). Define supplier fields following the [content modeling guide](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide.md):
Display name
Code
Home website
Email/Phone
Address content type (or fields for address, including country/region)
Notes
Asset (logo). (Fields follow XbyK’s content-type modeling practices, i.e., you might want to store logo in a dedicated [Image asset](https://docs.kentico.com/guides/architecture/content-modeling/content-modeling-guide/store-files.md#image-content-type) content type.)
Editors define relationships by linking Product to _Supplier_ (single or multi-supplier, depending on your business rules) using the _Combined content selector_.
Alternatively, in complex scenarios, you can create a _Supplier_ taxonomy, and add a taxonomy field to both _Product_ and _Supplier_ content types. Editors will assign supplier tags to both content items. Adding tags adds a new layer that allows for additional filtering of suppliers in the Content hub or creating smart folders.
Both approaches enable filtering and displaying details, such as displaying supplier or manufacturer information on product detail pages or enabling users to filter product listings by brand or manufacturer.
**Custom “Suppliers” (or “Manufacturers”) module**
If you need operational features, such as supplier SLAs, lead times, per-supplier cost data, purchasing endpoints, implement a custom module—the same approach XbyK recommends for other operational domains like [product stock](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/model-product-catalog/model-product-stock.md).
Store supplier master data in the module (tables + Info objects).
Build admin UIs (lists, detail edit) and permissions as needed.
Keep a content link from the Supplier record to a _Supplier_ content item (for marketing-friendly profiles) or link directly to _Product_ items.
**Integrate your PIM/ERP as a supplier source of truth**
If suppliers are managed in an ERP or PIM, utilize XbyK’s extensibility and APIs to synchronize supplier references with products (IDs, names, snapshots for display), while maintaining operational data in the external system. The product page(s) can still show a supplier profile from the Content Hub.
**Where to surface Supplier data**
Storefront: Show supplier name/logo/links on product detail pages via the linked Supplier content item (or taxonomy).
Filtering & navigation: Use taxonomies (or a _Supplier_ linked item) to enable supplier filters in category and search pages.
Headless delivery: Expose supplier fields via XbyK’s content APIs for SPA/JS front ends. (XbyK provides content delivery and querying patterns for content types.)
**Order & inventory considerations (patterns)**
XbyK ships the essential order and customer apps, but leaves stock and deeper business rules to your implementation—so decide how supplier info should flow into [orders](https://docs.kentico.com/documentation/business-users/manage-commerce-stores.md#manage-orders) and [ availability](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/model-product-catalog/model-product-stock.md).
When a product is added to the cart or purchased, store the current supplier name/ID in the order item representation. This ensures historical orders remain accurate if supplier assignments change later. This is a recommended project-level pattern.
Inventory by supplier: If availability depends on supplier, extend your custom stock module with per-supplier quantities or lead times; XbyK recommends implementing stock as a [custom module](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface.md). |
| Product workflow and product versions | Kentico 13 uses a SKU-based commerce architecture, where products (SKUs) are primarily represented as records in a dedicated commerce table and hold all essential commerce-related data.
KX13 products can be linked to CMS page types, which enables them to participate in content management workflows. When this link is established, products gain access to:
Workflow processes (e.g., draft → review → publish)
Versioning (with history and rollback)
Multilingual support (culture-specific variants)
Capabilities for product-related content come from the content management part of the KX13, meaning that any product linked to a page type can follow the same approval and publishing processes as other pages. | **OUT OF THE BOX**
XbyK adopts a content-first architecture, meaning products are modeled as content items within the Content Hub, rather than as dedicated commerce objects, such as SKUs in KX13.
Because products are content items, they automatically inherit all [workflow](https://docs.kentico.com/guides/digital-marketing/work-with-workflows/workflows.md) features, including:
Versioning
Every product has a version history with restore capabilities.
Approval workflow
Products can follow structured publishing workflows (e.g., draft → review → approved → published).
Translation
Culture-specific variants are natively supported.
Content Sync
Products can be synced across environments (e.g., staging → production).
Smart folders & usage tracking
Products can be organized based on taxonomy and other criteria. Editors see where products are referenced across website channels.
These features are available out of the box for any content item, including products, without needing additional configuration. | Use out of the box [workflow](https://docs.kentico.com/documentation/developers-and-admins/configuration/workflows.md) feature. You can extend existing behavior to provide [custom workflow notifications](https://docs.kentico.com/documentation/developers-and-admins/customization/handle-global-events/set-up-custom-workflow-notifications.md). |
| Product metadata | In KX13, product (SKU) metadata is stored in a dedicated table, which contains all commerce-related fields, product type indicators (e.g., standard, variant, bundle, e-product), inventory and pricing data, tax and discount associations.
Store managers can provide additional metadata via custom fields in the SKU table, which requires modifying the default commerce module’s capabilities. Store managers can reuse some content, such as descriptions or images, with linked pages.
KX13 also provides multilingual support for products, which dictates the approach the developers take to implement the store. | **OUT OF THE BOX**
XbyK products are content items with metadata stored as fields in custom content types. You define exactly what metadata you need, such as name, SKU, price, description, images, category, brand, and specifications. This metadata is fully customizable. Store managers can use versioning and workflow to handle their product content lifecycle. Product information can be localized using [AIRA translations](https://docs.kentico.com/documentation/business-users/aira.md#aira-translations). And product data is reusable across different marketing channels.
Because it's part of the content model, product metadata benefits from all CMS features without needing separate commerce structures. | Use the out-of-the-box content type features. |
| **Orders** | | | |
| -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feature name | KX13 feature description | XbyK feature description | Implementation example |
| Order management by admin, including displaying a list of orders, managing order items | In KX13, store admins manage customer orders using a built-in **Orders** application.
The **Orders** application lets administrators:
**View and update orders**
Store administrators can view all order details, including items purchased, customer information, payment status, and shipping details.
**Change order statuses**
Orders can progress through various stages, including Pending, Processing, and Shipped. These statuses can be customized and even automated.
**Handle returns**
KX13 does not have a dedicated Returns module; admins can manage returns by updating order statuses and adjusting inventory manually.
Every order maintains a complete record of what was purchased, by whom, and how it was paid for and shipped. | **REQUIRES EXTENDING XBYK**
In XbyK, store admins manage orders using the **Orders** application. Administrators can:
**View orders**
Admins can see order details like products, customer info, shipping, and payment status.
**Set order statuses**
Managers can define custom order statuses (like _New_, _Processing_, _Paid_, or _Completed_) and update them as the order progresses.
XbyK does not have automated workflows for updating order status. Administrators must manually update statuses, or developers can build custom logic if needed.
**Handle returns**
XbyK has no dedicated _Returns_ module, admins can manage returns by updating order statuses and adjusting inventory manually.
Every order maintains a complete record of what was purchased, by whom, and how it was paid for and shipped. | **How to enable admins to change order in XbyK?**
To update a completed order, the project can use two different approaches. They both consist of the basic flow:
Cancel the original order to prevent fulfillment or reporting issues.
Create a new order manually with the correct items and quantities.
They differ in how the new order is created.
We recommend that editors mimic the customer on the live site and manually create the order, going through each step as if they were the customer. This approach reflects a commonly used and reliable method adopted by Kentico partners in their implementations. It avoids complications with modifying finalized transactions and maintains a clear audit trail.
If your project needs more complex order management, developers can implement a custom module to create an order using XbyK admin UI components and Order API. For example, a custom module’s UI page can contain fields where the store manager inputs the same data as that customer need to provide through the live site’s multistep process in a custom _Create order_ form. Store managers will populate the respective fields, including product selection, pricing adjustments, and selecting valid shipping options, and then create the order from within the admin UI. |
| Order recalculation after change | When a customer updates their order, e.g., adds or removes items, changes quantities, or applies a discount, KX13 automatically recalculates the order using a _calculation pipeline_. This pipeline ensures the final price was always accurate. | **REQUIRES STANDARD DEVELOPMENT**
When a customer updates their cart, for example, by changing quantities or adding or removing products, XbyK recalculates the order server-side using its shopping cart services.
When the cart changes, the system recalculates totals, including product prices, shipping costs, and taxes (if applicable).
The recalculation logic is simpler than in KX13 and doesn’t use a detailed multi-stage pipeline. Developers can extend the calculation logic. | Follow the recommended approach for [price calculation](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/price-calculation.md). |
| Order notifications | KX13 uses macro-based email templates to send notifications to customers about their orders. These emails include:
Order confirmations
Shipping updates
Status changes
Payment received messages
Admins create email templates using HTML and Kentico macros to insert dynamic order data using a simple email editor.
KX13 sends emails automatically based on configured rules, ensuring customers stayed informed throughout the order process. | **REQUIRES STANDARD DEVELOPMENT**
XbyK order notifications are handled using the Email Builder, a visual tool that lets admins design and send emails when order statuses change.
**Email Builder**
Admins create email templates using drag-and-drop components that developers prepared. These templates can include dynamic order details, such as product names, totals, and customer information.
**Triggered by order status changes**
When an order status is updated (e.g., from _Processing_ to _Shipped_), XbyK can automatically send the corresponding email to the customer.
**Custom notification content**
Email templates support placeholders for order data, so each email is personalized. To supply values dynamically, XbyK uses a modern and customizable placeholder system built into Email Builder instead of KX13 macros. | Follow recommended approach for order [status notifications](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/configure-order-statuses.md#configure-notifications-for-order-statuses). |
| Payment method | Kentico 13 supports custom payment gateway integrations, but it doesn’t include built-in payment processing.
Admins configure payment options in a dedicated table, including _allowed currencies_, _payment fees_, or _gateway type_ (e.g., manual, credit card).
To capture payments (e.g., via Stripe or PayPal), developers need to build custom integrations. Kentico provides examples, like a Stripe integration guide.
After payment is captured through the gateway, the system updates the order’s payment status manually or via custom code.
KX13 doesn’t handle payment authorization or capture itself. KX13 relies on external systems and developer-built logic to complete the transaction. | **REQUIRES EXTENDING XBYK**
XbyK supports payment method configuration, but does not include built-in payment gateway integrations.
Admins define payment methods as configuration objects, which include details such as _payment method name_, _description_, and _supported currencies_.
Deleting the payment method doesn’t change existing orders that used this payment method.
To actually capture payments (e.g., via Stripe or PayPal), developers need to build custom integrations using XbyK’s checkout API. There’s no out-of-the-box payment processing, but there’s a [Stripe implementation](https://www.goldfinch.me/blog/from-spec-to-stripe-building-a-payment-provider-for-xperience-by-kentico) by Kentico Community.
After payment is captured, the order status and payment info can be updated in XbyK manually or via custom logic.
XbyK doesn’t handle payment authorization or capture, and it relies on external systems and developer-built code. | Use recommended approach for [payment methods](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/shipping-and-payment-methods.md#configure-payment-methods). |
| Order addresses | In KX13, each order stores shipping and billing addresses using dedicated database tables, which store details, such as customer name, street, city, ZIP/postal code, country and state, phone, and email (if needed).
Order addresses are separate from the customer profile and are associated with the specific order. Each order keeps a snapshot of the address used at the time of purchase.
KX13 can store both billing and shipping addresses for each order, allowing flexibility for different delivery and payment scenarios.
Store admins can view and update order addresses through the Orders application if corrections are needed. | **REQUIRES STANDARD DEVELOPMENT**
XbyK orders include address information for billing and shipping directly in the order information, including customer name, street address, city, postal code, country, and region.
Developers can extend the _order_ model to include additional address fields if needed (e.g., company name, phone number).
XbyK stores address data as part of the order object or linked to the customer record.
These addresses can be used in custom logic for calculating shipping costs or taxes, though XbyK doesn’t include built-in engines for either. | Follow the guidance on how to implement [Order addresses](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/checkout-process/order-creation.md#address-handling) in the documentation. |
| **Customers** | | | |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feature name | KX13 feature description | XbyK feature description | Implementation example |
| Users and customers | KX13's _COM\_Customer_ table links to _CMS\_User_ for registered customers with bidirectional synchronization of name, email, and phone.
KX13 utilizes a _CMS\_User_ object for every entity that represents a human being, including system editors, customers, etc. | **OUT OF THE BOX**
In XbyK, _Customers_ are a separate entity from a _User_. **Users**, or more accurately, **editors**, are restricted to editors and other users who have access to the XbyK back-office. | |
| Customer data, Customer profiles | In KX13, _customer data a_nd _customer profile_ serve as a central component of the commerce system. They allowed storing and managing customer-related information from the admin interface. This enabled businesses to maintain accurate records and deliver personalized experiences across the platform.
Customer profile includes:
Personal details, such as name, email, phone number, and other contact information.
Order history that contains a complete record of all purchases made by the customer.
Addresses include billing and shipping addresses associated with the customer.
Custom fields that developers can create custom fields to capture additional business-specific data.
The Customer profile is tightly integrated with core commerce features such as:
Discounts and Promotions that allow for targeted offers based on customer data.
Shopping cart feature supports personalized follow-ups to boost conversions in abandoned cart scenarios.
Contact segmentation allows store managers to grouping customers for marketing campaigns and behavioral analysis.
**Managing Customer Profiles**
KX13 contains several applications that enable users to manage customer data across different systems.
**Customers** application where store managers create, edit, or delete customer records.
**Users** application handles account-level actions for registered customers, such as password changes and updates to login or contact details. Customers could change their password and other details through the **My profile** application (if granted admin access permissions).
**Orders** application where store managers can review or manage customer details within existing orders (e.g., billing/shipping address). The app also helped preserve historical order integrity while reflecting necessary changes.
Additionally, KX13 includes a dedicated application for tracking customer credit history, supporting businesses in managing financial relationships. | **REQUIRES EXTENDING XBYK**
In XbyK, the **Customer** profile is currently handled differently compared to KX13. Currently, it exists as an isolated entity within the Commerce module, and, aside from the **Membership** entity, it is not yet integrated with other parts of the platform.
**Future Direction: Unified Customer Identity**
XbyK is evolving toward a **Customer Data Platform** approach. Upcoming features will introduce [unified identity resolution](https://roadmap.kentico.com/c/336-unified-contact-profile-identity-resolution) linking the Customer entity with other representations such as:
Contacts
Subscribers/Recipients
(other entities)
This integration will enable cross-feature usage of customer data across both marketing and commerce, creating a single, consistent view of each customer. Until these features are delivered, projects requiring a unified view of customer data can implement custom solutions.
**Managing Customer Profiles in XbyK**
XbyK contains two main applications where store managers manage customer data.
**Customers** application where store managers can create, edit, or delete customer records.
Registered customers are linked to _member_ accounts.
Anonymous customers: Can complete purchases without creating an account, the _Customers_ application stores their commerce-related data.
**Members** application holds registered customer data. The members are managed via APS.NET Core Identity, enabling login, password management, and profile updates. The application stores their account info and other non-commerce data.
Developers can extend the Customers or Members applications (or build entirely custom applications) to include additional entities, such as credit history.
**Upcoming features**
XbyK does not yet fully integrate customer profiles with marketing contacts or email recipients. Follow the public roadmap for features related to building customer profiles and leveraging customer data. We plan to deliver several opportunities that will create membership roles, [link customer profiles to other entities](https://roadmap.kentico.com/c/336-unified-contact-profile-identity-resolution) like contacts, members, and subscribers for cross-feature use, or the [abandoned cart](https://roadmap.kentico.com/c/336-provide-a-flexible-way-of-segmenting-customers-by-conditions-and-context) and other segmentation scenarios feature. | **How to implement the member-contact-customer relationship?**
To enable seamless data integration between contacts and commerce-related entities, it's essential to establish a custom relationship between the _Contact_ and _Customer_ objects. This relationship enables you to surface relevant commerce data (e.g., purchase history, order count, product preferences) directly within the contact profile, allowing for more precise segmentation and automation in your marketing workflows.
You can implement this relationship by following a similar approach to the [Contact–Member relationship](https://docs.kentico.com/guides/development/members/map-member-to-contact.md).
This involves:
Creating a custom field on the Contact object that references the Customer object by adding a [custom field](https://docs.kentico.com/guides/development/customizations-and-integrations/add-custom-contact-field.md).
Ensuring proper synchronization and data mapping between the two entities.
Optionally, extend the Member object in a similar fashion if your solution requires linking all three entities (_Contact_, _Customer_, _Member_).
This will allow store managers and marketers to leverage commerce data in real-time personalization, segmentation, and marketing automation scenarios. |
| Customer registration/profile | KX13 supports purchases for both registered and anonymous customers:
Registered customers can create an account during checkout or prior to checkout. Their data is stored in the _Customer_ object, which is linked to a _User_ account in the system. Registering allows for:
Abandoned shopping cart and other workflows.
Order history tracking, customer credit.
Personalized experiences leveraging contact data enriched with commerce data.
Easier repeat purchases, upsell, and cross-sell based on customer history.
Anonymous customers can complete purchases without needing to create an account. Their data is stored in the Customer object, but without a linked User account. This allows for:
Quick checkout experiences
Basic order tracking (via email confirmation)
Limited personalization based on _Contac_t data.
KX13 store managers can choose between requiring registration or allowing guest checkout, and depending on business needs, request developers to customize commerce implementations. | **REQUIRES STANDARD DEVELOPMENT**
XbyK also supports purchases for both registered and anonymous customers.
Customers can complete a purchase without creating an account (anonymous) or register during purchase (registered customers). _Registerd customers_ are based on an extensible _ApplicationUser_, which allows for extending the “customer” object with custom fields to collect additional customer data.
Records of registered customers are linked to orders, and store managers work with them in the _Customers_ application. Anonymous customers have their data stored and linked to orders, but their data isn't connected to identity-based accounts.
At this moment, XbyK doesn’t contain out-of-the-box commerce-driven condition rules for segmentation in Contacts groups or for triggering automation processes. Support for Abandoned shopping cart and other segmentation scenarios will be enabled in [this opportunity](https://roadmap.kentico.com/c/336-provide-a-flexible-way-of-segmenting-customers-by-conditions-and-context).
Follow namely [Custom Data Platform](https://roadmap.kentico.com/c/336-provide-a-flexible-way-of-segmenting-customers-by-conditions-and-context) initiative on the [roadmap](https://roadmap.kentico.com/tabs/6-next-refreshes). | **How to store and leverage commerce-related data?**
If you need to to enable advanced segmentation and automation capabilities within your marketing platform before we deliver the [identity resolution](https://roadmap.kentico.com/c/336-provide-a-flexible-way-of-segmenting-customers-by-conditions-and-context), we recommend to extend the Customer object by creating custom fields, following the same [best practices](https://docs.kentico.com/documentation/developers-and-admins/digital-marketing-setup/contact-configuration/map-custom-member-fields-to-contacts.md) applied to the [Member](https://docs.kentico.com/documentation/business-users/members.md) object. Before you explore implementation options, consider the project timeline/feature requirements.
To effectively leverage commerce-related data, such as purchase behavior or return history, for contact segmentation or to trigger automated marketing processes, you can implement a custom relationship between the Contact and Customer entities. This relationship allows you to store and access relevant commerce data directly within the contact profile.
Key data points to consider storing in custom contact fields include:
Product interactions (e.g., products viewed or purchased)
Number of orders placed
Number of returns
Average order value
Last purchase date
In addition to enriching contact profiles with static data, we also recommend [logging custom activities](https://docs.kentico.com/documentation/developers-and-admins/digital-marketing-setup/set-up-activities/custom-activities.md) that capture customers' behavioral events. Marketers can use activities to drive real-time marketing automation (and deeper analytics via [Customer journey](https://docs.kentico.com/guides/customer-journeys.md)). Examples include:
Product purchased (with product ID, category, timestamp)
Number of purchases over time
Purchases made with a discount or promotion
Cart abandonment
Product review submitted
You can combine enriched profile data with logged behavioral activities and build highly personalized, data-driven marketing journeys that respond to both historical and real-time customer behavior. |
| Managing customer credit | The _Customer credit_ feature in KX13 allows you to offer store credit as a payment method for registered customers in a loyalty service.
Customers earn credit through purchases or promotions and can redeem it for products once they accumulate enough. Credit payments must cover the full order amount and cannot be combined with other payment methods.
The system supports both global and site-specific credit balances, which can be configured via the _Store_ or _Multistore configuration_ applications. Developers need to implement the credit payment method using the Xperience API (credit transactions are managed through a dedicated _CreditEventInfo_ API). | **REQUIRES CUSTOMIZING XBYK**
XbyK does not include built-in support for managing or tracking customer credit history. If your solution requires credit-related data (e.g., credit limits, balances, or payment history), this functionality needs to be implemented through custom development or integrated from an external system via APIs or custom modules. | **How to store and leverage commerce-related data?**
You can introduce a credit system that allows customers to accumulate, view, and redeem credits (e.g., loyalty points, refund credits, promotional bonuses) within the Xperience platform.
Extend the _Customer_ object with custom fields to store:
Current credit balance
Total earned credits
Total redeemed credits
Last credit transaction date
Optionally, create a custom object (e.g., _CreditTransaction_) to log credit-related events (earn, redeem, expire) with metadata like:
Amount
Type (manual, purchase-based, refund, promo)
Timestamp
Related order or campaign
Implement a custom credit service layer to encapsulate all credit operations, including adding credits (e.g., after purchase or campaign), deducting credits (e.g., during checkout), validating credit usage (e.g., maximum per order, expiration), and retrieving credit history.
Hook into order processing events (order completed, refunded) to automatically award credits based on order value or rules, or deduct credits if used during checkout.
You can also extend the checkout process to allow customers to apply credits as a payment method or to receive discount.
We recommend providing admin UI for editors to manage credit (manual adjustments, view credit logs, manage credit rules), as well as customer-facing UI to view current balance, see credit history, or redeem credit option.
Optionally, store credit-related data in contact profile fields for segmentation (e.g., high-credit customers). Create a custom scheduled task to evaluate these fields. If the value is true, add a dedicated custom activity to contact that triggers automation, such as sending reminders before credit expiration, rewarding top credit earners, or re-engaging users with unused credits.
Consider building the system to support:
Multiple credit types (e.g., loyalty points, gift cards),
Credit expiration,
(potentially) Integration with external systems (e.g., CRM) |
| Abandoned shopping cart | KX13 marks _shopping carts as abandoned_ using a scheduled task that checks for carts meeting certain conditions (e.g., not updated for a set time and containing products). When identified, the system creates a custom _Shopping cart abandoned_ activity, which can trigger marketing automation workflows like reminder emails.
You can customize the logic by overriding the default task or creating your own, allowing rules such as excluding registered users or filtering by currency. | **REQUIRES CUSTOMIZING XBYK**
XbyK doesn’t provide abandoned shopping cart out of the box and needs to be custom-implemented at the moment. Support will be added through the **Customer Data Platform initiative** and will be added to the [product roadmap](https://roadmap.kentico.com/tabs/4-planned). | **How to add the abandoned cart flow in XbyK?**
To recover abandoned shopping carts in XbyK, developers can create [custom activities](https://docs.kentico.com/guides/development/activities-and-marketing/log-custom-activities.md) to track when users leave items in their cart without completing a purchase. This is achieved by logging a custom activity against the _contact profile_ when a cart remains inactive for a specified period (e.g., 24 hours).
Developers can prepare a custom [scheduled task](https://docs.kentico.com/documentation/developers-and-admins/customization/scheduled-tasks.md) to check for these _abandoned carts_ and log the activity.
Logging the activity triggers [automation sequence](https://docs.kentico.com/documentation/business-users/digital-marketing/automation.md) with reminder emails that include a link to restore their cart. Currently, the link generation logic needs to be custom-implemented.
The system should also track whether users return and complete their purchase with a custom activity, helping editors measure success in, e.g., customer journey, and to drive further messaging/personalization.
This setup works for users who provided an email address (or registered users), integrates with XbyK’s contact management, and supports marketing automation and reporting via [Customer journey](https://docs.kentico.com/guides/customer-journeys.md). |
| **Discounts** | | | |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feature name | KX13 feature description | XbyK feature description | Implementation example |
| Displaying discount | To show discounted prices on a KX13 commerce site, discounts were designed to integrate to the app through dependency injection. Developers poll and display discounts accordingly on the live site. | **REQUIRES STANDARD DEVELOPMENT**
XbyK provides a _promotions_ feature that allows store managers to apply [Catalog](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/catalog-discounts.md) and [Order](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/order-discounts.md) discounts. | See implementation details in the [documentation](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions.md). |
| Catalog discounts | KX13 utilizes the built-in _ICatalogPriceCalculator_ service to retrieve product prices and returns both the standard and discounted prices. Developers can implement logic to calculate the discount value by subtracting the discounted price from the standard price. This allows them to display both the original and discounted prices in your product listings or detail pages. | **REQUIRES STANDARD DEVELOPMENT**
XbyK provides [catalog discounts](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/catalog-discounts.md) _Catalog discounts_ apply to individual products during price calculation, such as percentage or fixed-amount discounts, category-based offers, or member-only pricing.
During checkout, the system automatically evaluates all active promotions and applies the most suitable discount available. Administrators create and manage promotions through the admin interface. Developers implement custom discount rules through the promotion framework that integrates with the price calculation API. | See how [catalog discounts](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/catalog-discounts.md) are implemented in the _Dancing Goat_ website, and the detailed documentation. |
| Buy X, get Y | KX13 supports Buy X, Get Y discounts as a way to offer free or discounted products when customers purchase specific items or quantities. These discounts are configured in the administration interface and applied automatically during checkout when the conditions are met.
Store managers define the _required products or quantity_ (X) and the _reward products_ (Y). The system checks the shopping cart for eligibility and applies the discount to the reward items.
KX13 supports both percentage and fixed-amount discounts. Developers can access discount details through the API to display promotional messages or customize logic. | **REQUIRES EXTENDING XBYK**
XbyK doesn’t offer _Buy X, get Y_ discount. Follow [product roadmap](https://roadmap.kentico.com/c/368-digital-commerce-shipping-buy-x-get-y-promotions) for any details. | **How to implement Buy X, Get Y Discounts to XbyK?**
If you need the discount before it's [built-in part](https://roadmap.kentico.com/c/368-digital-commerce-shipping-buy-x-get-y-promotions) of the product, developers can implement this feature.
**Core Strategy**
Detect when the cart meets the _Buy X condition_ (specific product(s) or quantity). Automatically add or discount the _Y product(s)_ in the cart. Ensure the logic works for both anonymous and registered users.
We recommend creating a mechanism in the Admin UI that editors can use to manage products eligible for discounts (e.g., via taxonomy or a custom module).
Optionally, [log custom activity](https://docs.kentico.com/documentation/developers-and-admins/digital-marketing-setup/set-up-activities/custom-activities.md), e.g., _Buy X, Get Y applied_, against contacts that leverage the discount for further segmentation, customer journey, and other reporting. |
| Order discounts | KX13 allows applying discounts at the order level, reducing the total price rather than individual product prices. These discounts can be configured in the administration interface and applied automatically based on conditions such as:
Order value thresholds (e.g., spend over $100)
Customer segments (e.g., registered users, loyalty members)
Promotional codes entered during checkout
Order discounts are calculated during the checkout process and reflected in the shopping cart and order summary. Developers can access discount details through the commerce API to display savings or customize discount logic. | **REQUIRES STANDARD DEVELOPMENT**
XbyK offers the [promotions](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions.md) feature, which businesses utilize to provide discounts and special deals to customers.
Currently, XbyK provides the following promotions, enabling combined savings based on cart contents or total price:
[Catalog discounts](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/catalog-discounts.md) apply per catalog items added to the shopping cart.
[Order discounts](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/order-discounts.md) apply to the entire order total and are evaluated after catalog discounts.
During checkout, the system automatically evaluates all active promotions and applies the best available discount. Administrators can create and manage promotions through the admin interface. Developers implement custom discount rules through the promotion framework that integrates with the [price calculation API](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/price-calculation/implementation.md). | See how order discounts are implemented on the Dancing Goat website. |
| Free (discounted) shipping options | To show discounted prices on your commerce site, KX13 provides the _CalculateRemainingAmountForFreeShipping_ method on the shopping cart object to determine how much more a customer needs to spend to qualify for free shipping. This value can be displayed as a banner or message to encourage higher-order values. | **REQUIRES EXTENDING XBYK**
XbyK doesn’t offer free (discounted) shipping promotion. Follow [roadmap](https://roadmap.kentico.com/tabs/4-planned) for any details. | **How to implement Free (discounted) shipping options?**
If you need the _Free (discounted) shipping option_ before its native to the product, developers can implement this feature through custom logic that extends the Discount engine.
You will need to detect when the cart content meets the free (discounted) shipping rule (specific product(s), quantity, order size, membership/subscription product, or location) and dynamically update the cart storefront UI, e.g., by providing shipping options in drop-down selector. Depending on the project business rules, ensure this logic works for both anonymous and registered users. We recommend creating a mechanism in Admin UI where editors can manage products eligible for free shipping (e.g., a taxonomy group for simple solutions, or a dedicated custom module).
Optionally, you can also log a custom activity, e.g., _Shipping option XYZ selected_, against contacts that utilize the discount for further segmentation, customer journey analysis, and other reporting purposes. |
| Volume discounts | KX13 Volume discounts allow store managers to offer reduced prices based on the quantity of a product purchased. They are configured per product and applied automatically when the customer’s cart meets the defined quantity thresholds. For example:
Buy 5–9 units → 10% off
Buy 10+ units → 20% off
The system calculates the correct price during checkout, and displays it in the shopping cart and product details. Developers can access these prices through the API for custom display or logic. | **REQUIRES EXTENDING XBYK**
XbyK doesn’t provide volume discounts and you will need to extend the. Follow [roadmap](https://roadmap.kentico.com/tabs/4-planned) for any details, namely [Buy X, Get Y](https://roadmap.kentico.com/c/368-digital-commerce-shipping-buy-x-get-y-promotions) opportunity, which will enable extending the built-in XbyK discount engine. | **How to implement Volume discounts to XbyK?**
If you need the discount before it’s built into XbyK, developers can implement this feature through custom logic that extends the _Discount engine_, namely the [Catalog discounts](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/catalog-discounts.md). |
| Bundle discounts | KX13 product bundles enable store managers to offer multiple products of various types as a single product for special discounted prices.
For example, the store can sell combinations of one brand’s T-shirts, shoes, and caps together in bundles as single products. | **REQUIRES EXTENDING XBYK**
XbyK doesn’t have a bundle discount feature. Follow [roadmap](https://roadmap.kentico.com/tabs/4-planned) for any details. | **How to implement bundle discounts in XbyK?**
Developers can create a feature that enables managers to treat a bundle as a single, purchasable entity with custom pricing logic.
Create a bundle definition content type that groups multiple products under a single virtual SKU with a special price or use a dedicated taxonomy tag. Once you define this bundle as “catalog item”, you can use standard [Catalog discounts](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/catalog-discounts.md). Developers need to handle the cart logic so that adding a bundle automatically includes all its products and applies the correct discount. They need to ensure that they track inventory for each individual product in the bundle.
In front-end logic, developers need to display bundles clearly in the storefront and cart as a single item, with details of the included products.
During order processing, developer logic can store bundle details and deduct stock for each product in the bundle.
We recommend logging custom activities for bundle purchases to support analytics, segmentation, and further personalization. |
| Gift cards | Gift cards in KX13 function as a type of discount that customers can apply during checkout to reduce the order total. Each gift card has a unique code and a predefined value. When the code is entered, the system validates it and deducts the amount from the order price.
Store managers work with _Gift cards_ in the administration interface. They can configure gift cards as:
Fixed value (e.g., $50)
Expiration date
Usage limits (single-use or multiple-use)
During checkout, customers enter the gift card code, and the discount is applied automatically. Developers can access gift card data through the API for custom validation or display. | **REQUIRES CUSTOMIZING XBYK**
XbyK doesn’t currently offer a _gift card_ feature yet. Follow [roadmap](https://roadmap.kentico.com/tabs/4-planned) for any details, namely [Buy X, Get Y](https://roadmap.kentico.com/c/368-digital-commerce-shipping-buy-x-get-y-promotions) opportunity, which will enable extending the built-in XbyK discount engine. | **How to implement Gift cards to XbyK?**
You can create a dedicated _gift-card product_ to keep all gift card details, such as a _unique code_ or _initial value_. We recommend developing a _custom module_ to hold the issued gift cards with _ID_, _current balance_, and _expiry_, _customer_ who uses them, and related _transactions_. This more robust implementation will enable additional features, such as _audit trails_, _statuses_, easier _refunding_, and others. At checkout, the system validates the _gift card code_, checks the balance, applies the discount (up to the order total or remaining balance), updates the balance on the customer profile (or gift card record), and marks the card as, e.g., _exhausted_ when it reaches zero. |
| Discount coupons - Generic coupons | KX13 features a discount coupon option that enables store managers to create flexible promotions, thereby boosting customer engagement.
Coupons act as virtual vouchers that customers redeem during checkout to receive specific benefits. | **OUT OF THE BOX**
In January 2026, XbyK expands its promotion capabilities with support for generic coupon codes (the same coupon for every customer). Store managers can manually create coupon codes that customers enter during checkout to claim discounts. This feature works for both catalog discounts on specific products and order discounts on the entire purchase. The discount engine and price calculation have been updated to handle coupon-based promotions, and customer targeting options allow personalized offers. | Refer to the implementation on the Dancing Goat demo website. |
| Discount coupons - Unique coupons | KX13 offers a discount coupon option that allows store managers to create flexible promotions, thereby enhancing customer engagement.
Coupons act as virtual vouchers that customers redeem during checkout to receive specific benefits. | **REQUIRES CUSTOMIZING XBYK**
Unique coupons are typically used for single-use promotions, personalized offers, or loyalty rewards where each customer receives an individual code that can’t be reused.
Currently, XbyK doesn’t support unique (one-time) discount coupons. Follow the XbyK roadmap to stay informed about upcoming enhancements. | The upcoming [Buy X, Get Y](https://roadmap.kentico.com/c/368-digital-commerce-shipping-buy-x-get-y-promotions) feature will make the built-in discount engine even more flexible. You’ll be able to customize it to fit your business needs, such as adding support for unique discount coupons. Keep an eye on the XbyK roadmap for updates and release timelines. |
| Discount statuses | Each discount, gift card, or free shipping offer in KX13 has a status that indicates its current state:
Running – The discount is active (enabled and within its validity period).
Scheduled – Enabled but not yet active (validity starts in the future).
Finished – Enabled but expired (validity period has ended or all coupon codes have been redeemed).
Incomplete – Enabled but missing required setup (e.g., coupon codes not generated).
Disabled – Not active because it’s not enabled, regardless of validity settings.
These statuses help store managers quickly see which discounts are live, upcoming, expired, or need configuration. | **OUT OF THE BOX**
[Promotions](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions.md) have status indicators that reflect their current state.
Scheduled promotions are configured but not yet active and will automatically activate on the specified start date.
Active promotions are currently running and applied to eligible products or orders.
Deactivated promotions are inactive and can be reactivated by updating their activation dates.
_Statuses_ update automatically based on the _Active from_ and _Active to_ dates set during configuration, making it easy to track and manage the lifecycle of each promotion. | See the documentation covering [Promotion statuses](https://docs.kentico.com/documentation/business-users/manage-commerce-stores.md#promotion-statuses). |
| Discount priority | In KX13, _discounts_ are applied in a specific order during checkout to ensure accurate pricing.
First, _catalog discounts_ adjust the base unit price of products, followed by _volume discounts_ for quantity-based reductions. Next, _product coupons_ and _Buy X, Get Y_ offers are applied to individual cart lines. After that, _order-level_ discounts affect the subtotal, and shipping costs are calculated, with _free shipping offers_ applied if eligible. Finally, taxes are added, and any _gift card_ value is subtracted to determine the grand total. | **OUT OF THE BOX**
XbyK automatically ensures the customer receives the best possible discount when a user applies more than one discount.
For [catalog discounts](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/catalog-discounts.md) (product-level discounts), the system compares all applicable promotions and selects the one that provides the greatest savings for each individual product. After catalog discounts are applied, [order discounts](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/order-discounts.md) (cart-level) are evaluated and combined where possible, giving customers additional savings on the entire order total.
This priority system guarantees fairness and simplicity. Customers never need to choose between promotions, and businesses can confidently stack discounts without conflicts. Developers can further customize this logic in the _Discount engine_ if specific business rules are required. | Check documentation covering general information about how [promotions](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions.md) work. |
| Customizing discounts | KX13 gives developers full control over how discounts are applied to products and orders.
You can extend the built-in discount types and tailor the system to match your business needs. For example, you can define and apply custom discounts, such as those provided by an external system or application, or adjust the behavior of existing discount types. If you only need to set up custom conditions for applying discounts, you can achieve this using discount macro rules without deeper customization.
For advanced scenarios, KX13 allows you to extend the discount engine itself. You can create new discount types and register them, allowing the system to use your custom logic instead of the default functionality. This extensibility is built into the discount engine, which works closely with the price calculation service to ensure accurate pricing. | **REQUIRES EXTENDING XBYK**
XbyK enables you to design promotions tailored to your business needs. Out of the box, you can create and customize order discounts and catalog discounts, and apply them with generic coupon codes. While generic coupons can cover many scenarios, more advanced options—such as Cart Item Promotions and the upcoming [Buy X, Get Y](https://roadmap.kentico.com/c/368-digital-commerce-shipping-buy-x-get-y-promotions) feature—are planned for later in FY2026. These will make the discount engine even more powerful.
XbyK does not limited to built-in discount types. You can create entirely new discount types and register them in the engine. This means you can implement custom logic for promotions that go beyond standard use cases. The discount engine is tightly integrated with the price calculation service, ensuring accurate and consistent pricing across your store.
Automatic coupon generation and unique coupons are not available yet, but they’re on the roadmap. Keep an eye on upcoming releases for these enhancements. | See the relevant documentation about [Promotions](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions.md) and watch the public [roadmap](https://roadmap.kentico.com/tabs/4-planned) for [Buy X, Get Y](https://roadmap.kentico.com/c/368-digital-commerce-shipping-buy-x-get-y-promotions) promotion which will make the _Discount engine_ even more customizable. |
| **Checkout process** | | | |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feature name | KX13 feature description | XbyK feature description | Implementation example |
| Checkout process | KX13 implements checkout as a customizable sequence of steps that guide customers from the shopping cart to order completion.
Typical steps include:
Shopping cart review – Customers review items and quantities.
Customer details – Collect billing and shipping information.
Shipping selection – Choose delivery options.
Payment selection – Select and process your preferred payment method.
Order review & confirmation – Display summary and confirm the order.
Developers implement these steps using MVC controllers and views, leveraging Kentico’s commerce API for cart management, shipping, payment, and order creation. The process is fully extensible, allowing custom steps, validation, and integration with external services. | **REQUIRES STANDARD DEVELOPMENT**
The XbyK commerce allows you to customize the shopping cart calculation engine.
Platoform runs this calculation when working with the shopping cart during [checkout](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/checkout-process.md) and when [creating or editing orders](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/configure-order-statuses.md). The calculation determines how the system applies discounts, handles shipping costs, adds taxes, etc.
For example, you can completely replace the shopping cart calculation with a custom solution, or integrate any custom steps into the calculation process. | Follow the detailed documentation about implementing the [checkout process](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/checkout-process.md). |
| Product shipping options | KX13 uses a dedicated table to manage shipping requirements. Each shipping option can be configured with:
Weight limits
Delivery times
Custom charges
Tax class assignment
Shipping options are configurable per store. Store managers can link them to products in the back office. Customers can apply them during checkout. However, KX13 does not include carrier integrations (e.g., FedEx, UPS). These require custom development. | **REQUIRES STANDARD DEVELOPMENT**
XbyK provides shipping configuration objects, not dedicated commerce tables. Shipping options can include:
Delivery details
Charges
Tax class links
To display shipping options in the storefront, you can link them to content items based on custom content types.
XbyK does not include built-in carrier integrations (e.g., FedEx, UPS). These require custom development. | Use recommended approach in [shipping methods](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/shipping-and-payment-methods.md#configure-shipping-methods). |
| Shopping cart management | KX13 provides comprehensive shopping cart management through its _IShoppingService_, which streamlines product additions, quantity updates, and coupon code handling.
X13 features a sophisticated seven-stage calculation pipeline powered by _IShoppingCartCalculator_ and _IShoppingCartRepository_ services. This pipeline systematically processes cart evaluation through item-level calculations, catalog pricing, multibuy discounts, order-level discounts, shipping costs, tax computation, and final rounding.
This architecture enables developers to customize individual calculation steps while maintaining the integrity of the overall pricing logic, making it well-suited for complex commerce scenarios that require granular control over pricing and discount application. | **REQUIRES STANDARD DEVELOPMENT**
XbyK provides shopping cart functionality through _ICurrentShoppingCartCreator_ and _ICurrentShoppingCartRetriever_ services that handle cart creation and retrieval across user sessions and devices.
XbyK performs server-side cart calculations and integrates with a price calculation API featuring sequential processing steps for unit pricing, taxes, shipping, and promotions. While the calculation structure is streamlined compared to KX13's seven-stage pipeline, XbyK provides flexible customization through the implementation of calculation step interfaces. XbyK supports multiple calculation modes (_Catalog_, _ShoppingCart_, and _Checkout_) for different commerce workflow stages. | Use recommended approach for implementing [checkout process](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/checkout-process.md). |
| Invoices | KX13 provides a built-in **Invoices** feature managed through the _Store configuration_ application (site-specific) or _Multistore configuration_ (global).
Store managers configure the invoice template using HTML markup and macro expressions (e.g., `Order.OrderInvoiceNumber`) without developer involvement. KX13 generates a printable invoice for each order, accessible on the _Invoice_ tab in the _Orders_ application. Invoice number patterns are configurable.
Sending an invoice via email requires setting up a corresponding email notification template. Developers can further customize the invoice design and behavior through the commerce API. | **REQUIRES CUSTOMIZING XBYK**
XbyK does not include a built-in invoice feature. There is no invoice template editor, invoice number configuration, or order-level invoice tab out of the box. Developers must implement the entire invoice solution from scratch. | **How to add Invoices to XbyK?**
Supporting invoices in XbyK requires custom development that covers three areas: gathering invoice data, generating invoice, and invoice delivery.
**Invoice number generation**
You can store a sequential invoice number on each order using a [custom order field](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/checkout-process/customize-order-creation.md) and assign the invoice number during order creation. For example, you can implement a custom `IOrderDataMapper` and hook into to the order creation pipeline. To ensure unique invoice numbers, you can use a custom module class table.
**Invoice generation**
Generate the invoice as a PDF (most common) or as an HTML view that store managers can print using standard .NET Core approaches.
**Storing invoices**
Depending on your project requirements, you can store generated invoices (e.g., in Azure Blob Storage or as binary data in a custom module table) or regenerate them on demand from order data. (Storing invoices provides a stable audit record; regenerating on demand avoids storage costs but risks layout drift if templates change.)
**Invoice delivery**
You can attach the generated invoice to the order confirmation email using XbyK's [Email Builder](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/configure-order-statuses.md#configure-notifications-for-order-statuses) or implement a custom email service that sends invoices from code. Optionally, consider exposing a customer-facing _Download invoice_ link in the order history section of the live site (accessible after login for registered [customers](https://docs.kentico.com/documentation/business-users/manage-commerce-stores.md#manage-customers)).
**Admin UI**
Extend the XbyK administration to allow store managers view and download invoices per order, for example, as a custom tab on the Order detail page implemented as a [UI page extension](https://docs.kentico.com/documentation/developers-and-admins/customization/extend-the-administration-interface.md). |
| **Store management** | | | |
| ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feature name | KX13 feature description | XbyK feature description | Implementation example |
| Multilingual store, managing multilingual stores, global and site customer settings | KX13 supports multi-store configurations through site-specific and global commerce objects. You can choose between managing each store independently with site-specific products, currencies, and settings, or sharing resources globally across multiple stores running on a single instance. This approach supports wide scenarios from businesses running multiple stores with identical product catalogs but different designs, or completely separate stores with distinct inventories.
KX13 supports multilingual commerce capabilities, including multi-currency support with exchange rate tables, product translations across multiple languages, and localized content for different markets. Stores can define a primary currency for administrative purposes while allowing customers to shop in their preferred currency, with automatic price conversion based on configured exchange rates.
Products can be translated into multiple language versions alongside other website content, and the system supports culture-specific URLs and content delivery. Tax calculations can be adapted to different regions, and the platform enables businesses to configure shipping options, payment methods, and promotional rules that work across various languages and currencies, supporting international operations. | **REQUIRES CUSTOMIZING XBYK**
XbyK takes a different architectural approach to multi-store scenarios compared to KX13.
The platform does not include out-of-the-box multi-store configuration options with global and site-specific commerce objects. If your project requires multi-store functionality, you will need to evaluate specific requirements and work with development teams to implement custom solutions. | **How to approach implement multi-store capability in XbyK?**
To implement multi-store functionality in XbyK, you can leverage its channel-based architecture, where store identifiers can provide a viable solution for certain scenarios.
Assign each website channel a unique store identifier that determines product availability, pricing, and customers assigned to this channel. We recommend storing products centrally in the Content Hub with fields indicating which stores can display them. Alternatively, you can leverage a page-based content model and make product website pages.
Extend the customer profile to include a store ID, allowing for filtering of their shopping experience, order history, and available products. Implement custom services to handle the filtering logic on the storefront, ensuring that customers only see products and pricing relevant to their assigned store. You’ll also need to implement backoffice features, for example, to allow managers to handle relevant currencies or the availability of content in different languages.
However, please note that this approach is not a universal solution and may not fit every project's requirements.
The architecture works best for scenarios with moderate complexity, such as regional stores sharing similar catalogs with localized pricing or brand families with overlapping product lines. More complex requirements, such as real-time inventory synchronization across stores, sophisticated cross-store promotions, or advanced B2B procurement workflows, may require significantly more development effort or alternative solutions.
You should carefully evaluate their specific multi-store needs, expected growth, and operational complexity before committing to this custom implementation approach, as the development and maintenance costs may outweigh the benefits for particularly simple or exceptionally complex scenarios. |
| Currencies | KX13 offers multi-currency commerce functionality, allowing customers to purchase products in their preferred currency, with all prices automatically converted based on a configured exchange rate table.
Store managers set all product prices, shipping costs, and other fees in a designated main currency, which serves as the foundation for all conversions. KX13 allows selection between global currencies (shared across all sites) or site-specific currencies tailored to individual storefronts. | **REQUIRES CUSTOMIZING XBYK**
XbyK doesn’t provide support for managing currencies from within the administration interface. | |
| Permissions for store managers | KX13 manages permissions through a role-based system.
Administrators assign users to roles that control access to store management functions and commerce applications. KX13 platform allows creating specialized commerce roles including _EcommerceAdmin_ for site-specific store administration and _EcommerceGlobalAdmin_ for managing global commerce objects across multiple stores, with each role granting specific module permissions for tasks like managing products, orders, customers, discounts, and store configuration.
Users can be assigned multiple roles, with their effective permissions being the sum of all assigned roles. KX13 distinguishes between site-level permissions for individual store management and global permissions for administrators who need to work with shared commerce objects across the entire XbyK instance. | **OUT OF THE BOX**
XbyK offers a role-based permission system, where administrators create roles with specific permissions for individual administration applications. They then assign users to these roles to control access and capabilities within the platform. Roles grant four primary permission types: _View_ (required to access an application), _Create_, _Update_, and _Delete_. Besides primary, some applications include specialized permissions such as _Access channel_ for website channels, _Manage permissions_ for granting page permissions to other roles, or _Send email_ for email channels.
Users can be assigned multiple roles. Their effective permissions are the union of all permissions granted by their assigned roles. You can scope permissions to specific workspaces per applications like _Content hub_ for granular control. For example, a store manager can have read-write permission for one workspace but only view permission for other product items stored in another workspace.
Important note for commerce Stores
In XbyK, store manager permissions are always global rather than site-specific. This means that store managers in XbyK have system-wide access to commerce functionality across all channels. You need to consider this limitation for multi-store environments, where managers should have restricted access to specific stores or a subset of customer data. | Follow documenatation to implement the [role](https://docs.kentico.com/documentation/developers-and-admins/configuration/users/role-management.md) and [permission](https://docs.kentico.com/documentation/developers-and-admins/configuration/users/role-management/page-permission-management.md) access cotrol systems. |
| Customizing commerce | KX13 employs a decoupled architecture: the backoffice platform stores commerce data (products, pricing, shipping options) while developers build separate live site applications that connect through APIs. This approach allows teams to create custom shopping experiences while leveraging the backend infrastructure for data management and calculations.
Developers utilize KX13 commerce APIs to display product catalogs, implement shopping carts, and process orders through the built-in calculation pipeline, which handles discounts, shipping, and taxes.
You can customize pricing logic, payment methods, and order management interfaces while maintaining centralized control over commerce data and business rules.
Developers can enhance or adjust the system by adding their own custom code implementations or even entire modules and applications. | **REQUIRES CUSTOMIZING XBYK**
XbyK allows you to extend the scope of the available commerce features and customize the default functionality.
You can provide custom functionality by extending existing features, building custom classes (modules), or integrating tools developed by third parties, such as applications, utilities, services, or website templates. | |
| **Additional commerce-related features** | | | |
| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Feature name | KX13 feature description | XbyK feature description | Implementation example |
| Search | KX13 offers an index-based search solution for querying website content and various system data.
Architects can choose between two approaches: **Azure Cognitive Search** or **locally stored indexes** (built on Lucene).
**Azure Cognitive Search**
This cloud-based option stores indexed content in Azure Cognitive Search, providing advanced capabilities such as faceted navigation, scoring, and language analysis. It requires an Azure subscription, with pricing based on the selected tier. Note that search queries can target only one index at a time. This approach is ideal for projects leveraging cloud scalability and rich search features.
**Locally stored indexes**
Indexes are stored as files on the web server, supporting multiple specialized index types (e.g., custom tables, forms, or developer-defined functionality). Unlike Azure, local search can query multiple indexes simultaneously, offering flexibility for complex scenarios without additional cloud costs. This approach suits on-premise or cost-sensitive deployments. | **REQUIRES STANDARD DEVELOPMENT**
XbyK doesn’t provide a built-in search mechanism. Instead, we provide integrations with search solutions:
[Lucene](https://github.com/Kentico/xperience-by-kentico-lucene)
[Algolia](https://github.com/Kentico/xperience-by-kentico-algolia)
[Azure AI Search](https://github.com/Kentico/xperience-by-kentico-azure-ai-search) | Use recommended integrations, see [related documentation](https://docs.kentico.com/documentation/developers-and-admins/third-party-integrations.md). |