--- title: Model price options for variants --- > 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). ## Model price options for variants One of the most common challenges in product variant modeling is handling pricing. While some products cost the same across all variants (a dog collar might be $15.99 in any color), many products have variant-specific pricing. Understanding how to model price variations is crucial for your content structure. Let's explore different pricing scenarios and how to model them in Xperience by Kentico. ### Pricing options 1: Price Adjustments (price-modifier pattern) In this pattern, the parent _product_ has a base price, and variants store price adjustments that are added to the base price. Example: Premium Dog Collar - Base price (parent): $15.99 - Small, Medium: No adjustment ($15.99) - Large: +$3.00 ($18.99) - X-Large: +$5.00 ($20.99) To implement the price-modifier pattern, create a dedicated field on the parent _Product_ content type: - _ProductPrice_ (Decimal): 15.99 (base price) On the _ProductSizeVariant_ content type, define an adjustment field, provide editors a dropdown selector or a decimal input field: - _ProductSizeVariantPriceAdjustment_ (Decimal): 0.00, 0.00, 3.00, 5.00 Developers need to implement logic that dynamically calculates the final price by adding the base price and the adjustment. For example, a large collar costs _$15.99 + $3.00 = $18.99_. #### Benefits of price-modifier pattern - Data entry is straightforward: "Large costs $3 more than base price". - Simplifies pricing updates; editors can change the base price once, and adjustments remain valid. - Editors see price differences relative to the base, making the prices clear to understand. - Highlights the relationship between variants and the parent product. #### When to use price modifier pattern - Most variants in your store have the same price, with occasional exceptions. - Price differences are predictable and consistent (larger sizes cost more). - You want to emphasize that variants are closely related. - Your pricing logic is straightforward and doesn't require per-variant adjustments. ### Pricing options 2: Independent variant pricing In this pattern, each variant has its own complete price. The parent product may or may not store a price. Example: Premium Dog Food Parent: No price stored (or "starting at $12.99" for display purposes) - Small (3lb): $12.99 - Medium (7lb): $24.99 - Large (15lb): $44.99 - X-Large (30lb): $79.99 Note that prices don't increase uniformly due to volume discounting. The 30lb bag doesn't cost 10 times what the 3lb bag costs because bulk sizes are discounted. #### How to model independent variant pricing You can omit the price field on the parent _Product_ content type, or include an optional starting price field for display purposes, e.g., in product listings on storefront. DTo support independent pricing, define the following fields on the _ProductSizeVariant_ content type: - _DogFoodVariantPrice_ (Decimal, required): The exact price for this variant - _ProductSizeFieldsValue_ (Text): 3lb, 7lb, 15lb, 30lb #### Benefits of independent variant pricing - Each variant item stores its own price, which offers complete pricing flexibility. - Simplifies data entry by making it clear: "This variant costs exactly $24.99". - Allows stores to cover complex pricing models, including volume discounts, promotional pricing, or market-specific pricing. - Developers don't need to prepare price calculation logic, as prices are directly stored in the product variant items.. #### Trade-offs of independent variant pricing - Updating prices can be time-consuming, as each variant must be updated individually. - Editors don't see at a glance in the Content hub/content tree that larger sizes have volume discounts. #### When to use this pattern - Your prices don't follow a predictable pattern. - You have volume discounting or bulk pricing. - Different variants have fundamentally different costs. - You need market-specific or promotional pricing per variant. - You want complete pricing control without constraints. ### Other approaches to modeling pricing We have covered the two most common patterns for modeling prices, but the reality of digital commerce is much more complex. Understanding the project requirements and the business model will also determine whether you need to model price variations. You might want to introduce complex pricing calculations based on customer type, geographical location, or order values. Your project might require independent variant pricing for products with volume discounts. Alternatively, you may need price list references for B2B customer-specific pricing. Xperience by Kentico includes built-in [catalog discount](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/catalog-discounts.md) and [order discount](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/promotions/order-discounts.md) features that handle common pricing scenarios like percentage discounts, fixed amount reductions, and promotional campaigns. These features work well for straightforward pricing needs and integrate directly with the commerce functionality. For many implementations, these built-in capabilities provide everything you need without custom development. However, complex commerce implementations often require sophisticated pricing models beyond these standard discounts. You might need price adjustments where larger sizes cost incrementally more. Your project might require independent variant pricing for products with volume discounts or price list references for B2B customer-specific pricing. You might need to introduce complex tiered pricing for product- or product-combination-specific quantity breaks, or promotional pricing with time-based sales. In these cases, you can model pricing fields directly in your content types to support your specific business logic. This enables editors to tailor prices and gives developers the structured data they need to implement complex pricing (and [price calculation](https://docs.kentico.com/documentation/developers-and-admins/digital-commerce-setup/price-calculation/implementation.md)) rules. It works well when pricing logic is primarily managed within XbyK and follows patterns that are relatively stable and transparent to content editors. Alternatively, pricing can be managed through external integrations. XbyK can send product ID, quantity, channel, or customer group data to a third-party system for price calculation. This approach is useful when you manage pricing by systems like an ERP or when rules, such as dynamic discounts, contracts, or regional pricing are too complex to model directly in content. In this setup, XbyK provides the product data and context, while the external service returns the calculated price for display or further processing.