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 and order discount 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) 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.