Best practices

B2C vs. B2B pricing

Business-to-consumer and business-to-business models have very different pricing needs. In general, B2C tends to require less complex pricing than B2B.

B2C businesses tend to use base prices with different characteristics defined. For example, they might have different base prices for different countries. B2C pricing also uses more product and cart discounting instead of tiered pricing. B2C sales are driven more by emotion than need, and promotions are more important. B2C pricing involves low complexity in base pricing with many active promotions.

B2B businesses, however, use more complex pricing models involving high-precision money, tiered pricing, and customer-specific pricing. For example, an electronic parts manufacturer might negotiate pricing with each manufacturing customer individually, taking into account order volume, delivery frequency, and contract length.

Use prices as prices, not marketing

One of the most common pricing mistakes is using Composable Commerce prices outside of their intended use case. This could include:

• Using prices to store manufacturer suggested retail price (MSRP), recommended retail price (RRP), or suggested retail price (SRP) information.
• Implementing 'buy 2 get 1 free' scenarios using tiered pricing.
• Using prices to store discounts targeted at specific customer groups.

Price calculation is an expensive operation in Composable Commerce due to the ability to store multiple prices per Product Variant and the complex fallback logic for price selection. Therefore, prices should only be used to store actual purchase prices. Promotions should be modeled as Cart or Product Discounts, and marketing information such as MSRPs should be stored as Attributes.

We can simplify this to the following rule: keep it simple; use Prices only for pricing!

Always have a fall-back base Price

If Composable Commerce cannot find a Price for a Product, it cannot add that Product Variant to a Cart. Regardless of how you price your products, you should always implement at least one Price in each currency you sell. This should not use scoping, tiered pricing, validity periods, or other features. This will ensure that Product Variants can always be added to your Cart.

Use Product Discounts to show sale prices

Due to the limit of 100 Prices per Product Variant, we do not recommend using base prices on a Product Variant to show sale prices. The better option is to use a Product Discount. This adds a special field to the Product Variant response, discountedPrice, which contains the discounted Prices to display in your storefront. This way you can use the discounted price to display the sale price, and the original price can then be displayed as the strike-through price. Keeping these best practices in mind will surely lead to you creating efficient and accurate pricing solutions for your business!

Example scenario: pricing efficiently

To illustrate the best practices described, let’s consider the following example.

A business sells a Product with three Product Variants in three countries (Germany, England, and Denmark), each country with its own currency.

The MSRP of the product for each country is as follows:

• DE: 49,99 EUR
• GB: 43.99 GBP
• DK: 369,99 DKK

The business decides on a lower base price for each currency to sell the product at. We’ll call these the base price:

• DE: 44,99 EUR
• GB: 38.99 GBP
• DK: 329,99 DKK

The business also decides to implement a price tier: if a customer purchases 3 or more of the product in Germany or Denmark, or 4 or more in the UK, they will receive a lower price, as follows:

• DE: 39,99 EUR
• GB: 35.99 GBP
• DK: 299,99 DKK

An inexperienced price manager would set up these 9 monetary values as 9 Price objects, as follows:

As the example shows, this leaves a total of 27 Price objects for a Product—a huge amount of data to sort through when a Product is added to a Cart.

When selecting a Price for a Product Variant, Composable Commerce needs to evaluate the validity of the Price before selecting it. The more Prices you have, the worse the performance when retrieving a Price.

A more efficient way to set this up would be to reduce the number of Prices defined. You can do this in the following ways:

• Factoring out the MSRP to an Attribute with type money.
• Using a combination of tiered and base prices for each currency.

Using this strategy, we end up with the following:

With one move, we reduce the total number of Price objects from 27 to 18, improving performance. Since each country uses its own currency, there’s only one Price available for each country, which further improves performance. The two irrelevant Prices are automatically disqualified and the correct Price is then selected based on the quantity purchased.

We can extend this logic further when we think about pricing in the same currency for multiple countries. In Europe, many countries use a common currency, the Euro. Let's imagine a situation where we sell in three countries that use the Euro: Germany, France, and Spain. We want to sell our product for 44,99 EUR in Germany and France but for 42,99 EUR in Spain. We can do the following:

Instead of setting three base prices—one for each country—we can set one base price in Euros with no restrictions and one base price for Spain only. If a customer is in Spain, Composable Commerce will show them the base price for Spain; otherwise, it will show them the Euro base price. The fallback logic in Composable Commerce allows us to define a base price and then specify any exceptions to that base price as needed.

Test your knowledge