Pricing and Promotions Overview

The Big Picture

Understanding pricing in Omnium starts with one key concept: price creation and price storage are separate concerns.

Prices in Omnium are always stored on products (or in a dedicated price index for large catalogs). But prices can be created by many different mechanisms — an API call, a price list, a promotion, or an external system. Once a price is created, it lives on the product like any other price, regardless of where it came from.

This separation means you can mix and match pricing strategies without changing how prices are consumed. Your e-commerce frontend, cart engine, and API integrations all read prices from the same place — the product — no matter how those prices got there.

                        PRICE CREATION
  ┌───────────────────────────────────────────────┐
  │                                               │
  │  Price API    Price Lists    Promotions        │
  │  (ERP sync)   (UI mgmt)     (campaigns)       │
  │     │             │             │              │
  │  Product API  External      Future             │
  │  (in feed)    Price Svc     features           │
  │     │             │             │              │
  └─────┼─────────────┼─────────────┼──────────────┘
        │             │             │
        ▼             ▼             ▼

                     PRICE STORAGE
  ┌───────────────────────────────────────────────┐
  │     Products  (or separate price index)       │
  └───────────────────────────────────────────────┘
                        │
                        ▼

                   PRICE CONSUMPTION
  ┌───────────────────────────────────────────────┐
  │  Product pages · Cart / Checkout · API        │
  └───────────────────────────────────────────────┘

How Prices Are Created

Omnium offers several ways to create prices, each suited to different scenarios:

These approaches can be combined freely. For example, you might sync base prices from an ERP via the Price API, use price lists for store-specific overrides, and use promotions for seasonal campaigns — all at the same time. The price prioritization rules determine which price wins when multiple apply.

How Prices Are Stored

All prices end up in one of two places:

• On the product — The default. Prices are part of the product document and returned with every product query.
• In a separate price index — For products with very large price sets (150+ prices per product, common in B2B with customer-specific pricing). Prices are stored separately but still returned with product searches.

The storage mechanism is transparent to consumers. Whether a price came from the API, a price list, or a promotion, it looks the same once stored.

For details on price structure, levels, and ID generation, see the Prices reference.

How Prices Are Selected

When a product has multiple valid prices (different markets, stores, customers, date ranges), Omnium uses a prioritization strategy to select the most relevant one:

1. Unit-specific prices take highest priority
2. Then store-specific prices
3. Then store group prices
4. Then customer-specific prices
5. Then market-level prices

Within each level, the lowest price wins. For the complete rules and examples, see Price Prioritization.

How Promotions Fit In

Promotions serve a dual purpose in the pricing system:

1. Price generation (pre-cart)

Some promotion types automatically generate prices on products when the promotion is active. These prices appear in product listings and search results, so customers see the promotional price before adding anything to their cart.

When a price-generating promotion is activated, Omnium calculates the promotional price for every matching product and stores it alongside the product's other prices. When the promotion ends or is deactivated, those prices are removed.

2. Cart-time discounts (at checkout)

All promotion types are evaluated when items are in a cart. The promotion engine checks active promotions against the cart contents, customer, market, and store, and applies matching discounts. This is where context-dependent promotions like multi-buy ("3 for 2") and order-amount discounts ("10% off orders over 1,000 NOK") take effect.

Promotion Types at a Glance

Promotion Conditions and Targeting

Every promotion can be targeted using a combination of conditions:

Who sees it

What it applies to (product-level promotions)

When it's active

Coupon Codes

Promotions can optionally require a coupon code. Three types are supported:

When a coupon code is required, the promotion does not generate prices on products — it only applies at cart time when the customer enters the code.

Promotion Priority and Stacking

Priority

Promotions are evaluated in order:

1. By type — Order-line promotions first, then shipping, then order-level
2. By priority value — Lower numbers are evaluated first (use increments like 100, 200, 300 to leave room for future campaigns)
3. By discount value — Higher discounts are preferred when priorities are equal

Stacking rules

Common Pricing Patterns

Base prices with store overrides

1. Sync base prices (RRP) from your ERP via the Price API
2. Store managers create price lists in the UI for local adjustments
3. Price prioritization ensures the store-specific price wins when available

B2B customer-specific pricing

1. Sync customer-specific prices via the Price API with the customerId or customerGroup field
2. Enable separate price storage if you have large price sets
3. Customer group promotions give additional discounts on top

Seasonal campaigns

1. Create a promotion with date range, category/brand filters, and discount
2. Omnium generates promotional prices on matching products
3. Customers see the campaign price in search results and product pages
4. When the campaign ends, promotional prices are automatically removed

Coupon-only campaigns

1. Create a promotion with a coupon code and no date-based price generation
2. The promotion only applies when the customer enters the code at checkout
3. Useful for influencer codes, loyalty rewards, or targeted offers

Related Documentation