Upgrade - Commerce features overview
When planning a migration from Kentico Xperience 13 (K13) 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 (K13) and Xperience by Kentico (XbyK). It includes four columns:
- Feature name - Lists key commerce and content-related capabilities.
- K13 feature description - Details how the feature functions within K13.
- 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 |
K13 feature description |
XbyK feature description |
Implementation example |
|
|
Product (SKU) |
K13 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 |
OUT OF THE BOX XbyK products are content items in the Content hub or as website pages with structured data. 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. |
Follow the recommendations how to model product catalog. |
|
|
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. For example:
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. When building nested filters, developers must carefully design and optimize queries. |
|
|
Display product details |
K13 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 section. |
|
Products |
||||
|
Feature name |
K13 feature description |
XbyK feature description |
Implementation example |
|
|
Standard products |
K13 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 to synchronize the XbyK product catalog with external ERP/PIM. |
|
|
E-products |
K13 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) - Fields: - ProductName (Text, required) - ProductCode (Text, unique, required) - Price (Decimal, required) - Description (Rich text) - ProductImages (Assets) - DownloadFile (Asset or secure file reference) - DownloadLimit (Integer – max number of downloads) - ExpirationDate (DateTime – access expiry) - AccessToken (Text – for secure access, generated per order) - AvailabilityStatus (Multiple choice – e.g., Available, Expired) Implementation notes:
|
|
|
Membership |
Kentico 13 supports membership products through dedicated system tables. When a user purchases a membership:
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. Note that the built-in Membership Roles feature is on the roadmap. The second related roadmap item is Subscriptions. |
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:
|
|
|
Bundles |
K13 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. K13 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:
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 |
K13 product images are managed using the standard media library. 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 K13 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.
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 (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 In the most basic implementation, you can build an Asset content type with:
|
|
|
Product options |
K13 features built-in support for product options, such as size, color, or custom text. These options are grouped into categories and linked to products. K13 provides three types of options:
|
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 K13 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:
|
|
|
Product variants |
In K13, 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:
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. 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.
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 |
K13 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 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, and a description. Then, link assets to your Product content type.
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 |
K13 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 and restrict editors to only assign, but not modify the collection items. Dedicated content type also supports translations , versioning, and workflows. Employ Smart folders Use 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 |
K13 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. Supplier as a Taxonomy tag Similarly to Brands, you can use Taxonomy 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 K13 patterns). Define supplier fields following the content modeling guide:
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.
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
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 and availability. 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. |
|
|
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. K13 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:
Capabilities for product-related content come from the content management part of the K13, 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 K13. Because products are content items, they automatically inherit all workflow features, including:
These features are available out of the box for any content item, including products, without needing additional configuration. |
Use out of the box workflow feature. You can extend existing behavior to provide custom workflow notifications. |
|
|
Product metadata |
In K13, 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. K13 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. 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 |
K13 feature description |
XbyK feature description |
Implementation example |
|
|
Order management by admin, including displaying a list of orders, managing order items |
In K13, 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 K13 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:
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, K13 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 K13 and doesn’t use a detailed multi-stage pipeline. Developers can extend the calculation logic. |
Follow the recommended approach for price calculation. |
|
|
Order notifications |
K13 uses macro-based email templates to send notifications to customers about their orders. These emails include:
Admins create email templates using HTML and Kentico macros to insert dynamic order data using a simple email editor. K13 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 K13 macros. |
Follow recommended approach for order status notifications. |
|
|
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. K13 doesn’t handle payment authorization or capture itself. K13 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 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. |
|
|
Order addresses |
In K13, 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. K13 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 in the documentation. |
|
Customers |
||||
|
Feature name |
K13 feature description |
XbyK feature description |
Implementation example |
|
|
Users and customers |
K13’s COM_Customer table links to CMS_User for registered customers with bidirectional synchronization of name, email, and phone. K13 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 K13, customer data and 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:
The Customer profile is tightly integrated with core commerce features such as:
Managing Customer Profiles K13 contains several applications that enable users to manage customer data across different systems.
Additionally, K13 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 K13. 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 linking the Customer entity with other representations such as:
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.
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 like contacts, members, and subscribers for cross-feature use, or the abandoned cart 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. This involves:
This will allow store managers and marketers to leverage commerce data in real-time personalization, segmentation, and marketing automation scenarios. |
|
|
Customer registration/profile |
K13 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:
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:
K13 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. Follow namely Custom Data Platform initiative on the roadmap. |
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, we recommend to extend the Customer object by creating custom fields, following the same best practices applied to the Member 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:
In addition to enriching contact profiles with static data, we also recommend logging custom activities that capture customers’ behavioral events. Marketers can use activities to drive real-time marketing automation (and deeper analytics via Customer journey). Examples include:
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 K13 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:
Optionally, create a custom object (e.g., CreditTransaction) to log credit-related events (earn, redeem, expire) with metadata like:
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:
|
|
|
Abandoned shopping cart |
K13 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. |
How to add the abandoned cart flow in XbyK? To recover abandoned shopping carts in XbyK, developers can create custom activities 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 to check for these abandoned carts and log the activity. Logging the activity triggers automation sequence 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. |
|
Discounts |
||||
|
Feature name |
K13 feature description |
XbyK feature description |
Implementation example |
|
|
Displaying discount |
To show discounted prices on a K13 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 and Order discounts. |
See implementation details in the documentation. |
|
|
Catalog discounts |
K13 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 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 are implemented in the Dancing Goat website, and the detailed documentation. |
|
|
Buy X, get Y |
K13 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. K13 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 for any details. |
How to implement Buy X, Get Y Discounts to XbyK? If you need the discount before it’s built-in part 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, e.g., Buy X, Get Y applied, against contacts that leverage the discount for further segmentation, customer journey, and other reporting. |
|
|
Order discounts |
K13 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:
|
REQUIRES STANDARD DEVELOPMENT XbyK offers the promotions 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:
|
See how order discounts are implemented on the Dancing Goat website. |
|
|
Free (discounted) shipping options |
To show discounted prices on your commerce site, K13 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 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 |
K13 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:
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 for any details, namely Buy X, Get Y 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. |
|
|
Bundle discounts |
K13 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 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. 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 K13 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:
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 for any details, namely Buy X, Get Y 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 |
K13 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 |
K13 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 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 K13 has a status that indicates its current state:
These statuses help store managers quickly see which discounts are live, upcoming, expired, or need configuration. |
OUT OF THE BOX Promotions have status indicators that reflect their current state.
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. |
|
|
Discount priority |
In K13, 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 (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 (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 work. |
|
|
Customizing discounts |
K13 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, K13 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 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 and watch the public roadmap for Buy X, Get Y promotion which will make the Discount engine even more customizable. |
|
Checkout process |
||||
|
Feature name |
K13 feature description |
XbyK feature description |
Implementation example |
|
|
Checkout process |
K13 implements checkout as a customizable sequence of steps that guide customers from the shopping cart to order completion. Typical steps include:
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 and when creating or editing orders. 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. |
|
|
Product shipping options |
K13 uses a dedicated table to manage shipping requirements. Each shipping option can be configured with:
Shipping options are configurable per store. Store managers can link them to products in the back office. Customers can apply them during checkout. However, K13 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:
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. |
|
|
Shopping cart management |
K13 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 K13’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. |
|
Store management |
||||
|
Feature name |
K13 feature description |
XbyK feature description |
Implementation example |
|
|
Multilingual store, managing multilingual stores, global and site customer settings |
K13 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. K13 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 K13. 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 |
K13 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. K13 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 |
K13 manages permissions through a role-based system. Administrators assign users to roles that control access to store management functions and commerce applications. K13 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. K13 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 and permission access cotrol systems. |
|
|
Customizing commerce |
K13 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 K13 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 |
K13 feature description |
XbyK feature description |
Implementation example |
|
|
Search |
K13 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: |
Use recommended integrations, see related documentation. |
|