Types of Prices

Terminology

To understand pricing, you need to understand some common terms in the domain and how they relate to Composable Commerce.

Price

The monetary value for which a Product Variant is purchased. A Price consists of at least a numerical amount and a currency code.

Cart

A collection of Product Variants that a customer wants to buy. Adding a Product Variant to a Cart converts it to a Line Item. A Line Item is a snapshot of the Product Variant's state and pricing at the time it is added to the Cart. A Cart's total Order Price is a combination of the Price of all Line Items, shipping costs and taxes. The Cart is the entry point for the checkout.

Price tier

A Price tier or Price tiers indicate the monetary value for different Line Item quantities of the Product Variant in the Cart. Each Price tier consists of the minimum quantity and the value. For example, the base Price for a Product Variant may be 5 Euro per item, but purchasing a minimum quantity of 5 might reduce that to 4 Euro per item and a minimum quantity of 10 might reduce that to 3 Euro per item. This is useful for B2B scenarios, where products are often bought in bulk.

3 Types of Prices

Three types of Prices are available to use in Composable Commerce. Two of these are internal to Composable Commerce: Embedded Prices and Standalone Prices. The third type of pricing is to use an external pricing solution.

The Product Price Mode on a Product tells Composable Commerce which type of Price to use in Line Item Price and Product Price Selection. This can be set in the Merchant Center, as seen in the image below. A Product can have Embedded Prices and Standalone Prices at the same time. However, this field determines the Price used when the Line Item is added to the Cart.

Embedded Prices & Standalone Prices

For Embedded Prices, the Price data is stored as part of the Product record. Because of this, the limit on Embedded Prices is 100 Prices per Product Variant. Remember, there can be up to 100 Product Variants in a single Product, so 100 Product Variants, each with 100 Prices means we could be storing 10,000 Prices within one Product. With the 16 megabytes limit on any JSON document that we persist (a Product is stored as a JSON document), we run the risk of breaching this limit. Always keep in-mind how the Price and Product Type modeling together will impact this limit.

Standalone Prices, as the name suggests, are actually stored separately from the Product data. Standalone Price records are identified by the SKU, allowing the Product Variant to have up to 50 000 Standalone Prices. Deciding whether or not to use Embedded or Standalone Prices will therefore depend on the size and complexity of your product catalog.

Similarities between Embedded and Standalone Prices

Both types of Prices allow specifying the Price scope with having at least the currency field set. Optionally, the Price scope is further defined by:

• Customer Group
• Channel
• Country

To see the precedence of these fields when selecting a Price for use in the Cart, visit Line Item Price selection in the documentation.

Both Embedded and Standalone Prices can also have validity dates - start and end dates within which the Prices can be used. This allows you to set up Prices before they are active, knowing that when the time comes, the correct Price will automatically be used. Validity dates are not required - Prices without validity dates are always considered valid.

Finally, you can set up a tiered Price structure with both types. Both Standalone and Embedded Prices can have an array of Price tiers which have a minimum quantity and the associated monetary value. For any Price, you can specify what the Price would be if your customer purchases more than one.

How to choose between Embedded or Standalone Prices

The first thing to consider is the number of Prices that your Product will need. The maximum number of Prices per Variant is 100, though this is a soft limit. You can try to get this increased on a per Project basis. If you have significantly more than 100 Prices however, the decision has been made for you - you can only use Standalone Prices. If it is more than 50 000, then you must use some form of external Prices.

Since Standalone Prices are stored separately and are managed through the Standalone Prices API endpoint, there is better query performance when managing your Prices. However, one drawback to Standalone Prices currently is that they cannot be used in the Product Projection Search endpoint for filtering, faceting, or sorting.

External Prices

External pricing solutions are necessary when Composable Commerce pricing doesn't suit your specific situation. This could be because:

• you have more than 50 000 Prices for a Product Variant.
• your pricing is very dynamic.
• your Prices are stored externally to Composable Commerce.
• your Prices are stored as a Custom Object within Composable Commerce.

For this, your code will need to find the correct Prices to display on your storefront and to set the Line Item price when you add a Line Item to a Cart. External Prices currently cannot be used in the Product Projection Search endpoint for filtering, faceting, or sorting.

When to choose external Prices

When we say external Prices, we could be referring to any of the scenarios above. In the B2B world, it is common to have a separate Price for each Customer for each Product Variant. If this is your case and you have over 50,000 Customers, you would need some type of external Prices.

You may have pricing data stored in a product information management (PIM) system or any other external system. If you keep those external to Composable Commerce, you may make API calls to the external system when you need to display Price information for a Product Variant or when you add the Product Variant into the Cart.

You should choose external Prices if your pricing data is dynamic, meaning it changes very frequently or it must be calculated on-the-fly based on some external values, like currency conversion rates. For that currency conversion example, you probably get the conversion rates through some API calls to some external third party system before you calculate the converted prices to display in your storefront and to use on the Line Items in the Cart.

It may also be that you have your pricing data stored in some datastore that is colocated with your application code. In this case, rather than external API calls, you will need to make database calls to get the pricing information you need when you want to display or add pricing information into the Cart.

And finally, even though Custom Objects are actually stored within the confines of Composable Commerce, these can be used to store pricing data and even though you would access this data through commercetools API calls, they are still considered external Prices since your code would need to access this data when you need to display or add pricing information into the Cart. With this option you would miss out on all the price selection logic that you get with Embedded Prices or Standalone Prices.

Tiered Prices

Composable Commerce allows you to set tiered Prices, where the Price of an item changes depending on the quantity purchased. With tiered Prices, a base Price is first set, which is the Price applied to a single unit of a Product Variant when purchased. Setting the tiered Price then allows you to define pricing based on the quantity of an item added to the cart - for example, if a customer buys 10 of an item, they get a lower price per item.

Lets use the above tiered price examples and determine what the price will be for a few different scenarios.

You can set tiered Prices with both Embedded and Standalone Prices using the Merchant Center or API. This allows you to use the same price constraints to target different tiered prices for different customers (based on country, Customer Group, Channel, currency, and validity period).

Although tiered prices will commonly be used to offer a lower price per quantity threshold, you can also offer a higher price per tier. This is useful when you want to disincentivize Customers from purchasing too many of the same Product Variant.

Tiered pricing vs Volume pricing

Another type of pricing that is very close to tiered pricing is volume pricing. In this section we want to clear up some of the misunderstandings that may exist with how these terms relate to Composable Commerce as they might differ from other e-commerce systems.

Let’s first look at how these terms are commonly understood outside of the world of Composable Commerce:

• Volume pricing: a sales strategy that sees the price per unit of a product lowered as the quantity of the product increases. With volume pricing, every item is purchased at the same price, and the price is triggered by the number of items purchased. For example, all 7 apples are bought at $1 each, as the third tier was reached and triggers the same price for every item.
• Tiered pricing: works somewhat similarly, in that the price per unit of a product is lowered as the quantity changes, but the calculation method is different. Instead of every item being purchased at the same price, the items in the first tier are bought at the price corresponding to that tier, and then when you purchase further items in the next tier, only those new additional items get the new tier price. For example, the first apple is bought at $2, then apples two to four are $1.50 each and so on.

Now, things get a little confusing when we look at these features in Composable Commerce:

• To achieve Volume pricing in Composable Commerce, we use the Tiered Prices feature.
• To achieve Tiered pricing as we described it in the preceding paragraph, you have two main options: you can use Cart Discounts or you can use an external pricing system. We explore the Cart Discounts process in our Cart Discounts module.

Tiered Prices and Product Discounts

Managing Tiered Prices in Composable Commerce means you need to also watch your Product Discounts and how they interact with your Tiered Prices.

Composable Commerce allows you to set Product Discounts for each Product Variant. It's important to note that if a Product Discount is set for a particular Product Variant, the Product Discount overrides any existing tiered Price.

For example, if a customer purchases multiple quantities of a certain Product Variant (such as apples) that uses Tiered Prices, instead of receiving the Tiered Price in their Cart or Order ($1.50 per apple when you buy more than 5), they would instead receive the Price related to the Product Discount (50% off all fruit!). Keep this in mind when creating and managing your discounts and you will avoid situations where your customers may end up paying an unintended price.

Although tiered pricing is not classified as a Discount, it offers administrators an alternate way to discount prices for customers without using Product Discounts. Tiered pricing, however, need not always be used to reduce prices; it can also be used to increase the price when more items are bought by a customer. For example, to try to restrict goods from being bought in bulk and then being sold in other secondary or tertiary markets.

You can use tiered Prices with both Embedded and Standalone Prices.

Test your knowledge