Customer-Specific Pricing and Availability in B2B E-Commerce

The topic of customer-specific pricing and availability frequently arises in the B2B space. Businesses strive to offer personalized conditions for their clients, and many have ERP systems capable of handling this. However, the challenge lies in translating this logic into an e-commerce platform. Should it even be fully transferred?

To clarify, this topic actually consists of two distinct but related aspects:

• Customer-Specific Availability

• Customer-Specific Pricing

While these concepts are closely linked, they require different solutions.

Customer-Specific Availability determines which products are accessible to a given customer, whereas Customer-Specific Pricing defines what prices should be displayed for the available products. The availability criterion can be simple, such as “if a price exists, the product is available; otherwise, it is not.” However, in many cases, the logic is more complex—a price may be available, but the product itself is not. The reasons for this vary across businesses.

To better frame the problem, imagine a spectrum: on the far left, prices are calculated in real-time by the ERP for each product viewed by the customer. On the far right, all prices are precomputed, with no real-time calculations—at least until checkout or add-to-cart, where prices must still be verified. But pre-computing means also “delaying when the prices changes”.

 

Both of these extremes have out-of-the-box solutions in SAP Commerce Cloud. The far-left approach is handled by Synchronous Pricing, where prices are retrieved from the ERP in real time. On the far-right side, the default solution stores all prices in a database table within SAP Commerce, eliminating real-time calculations.

(We are not considering Promotions here, as they come into play at the cart stage rather than during product price display. Additionally, we are not addressing user price groups at this stage. Handling a small number of groups is trivial, while managing a large number of them presents the exact challenge that this article aims to solve)

However, both approaches come with drawbacks that, in certain cases, become critical. Addressing these limitations may require a complete redesign of the pricing mechanism.

For Synchronous Pricing, the main bottleneck is the relatively slow real-time price calculation, which typically occurs on the ERP side. This latency can impact the overall user experience, especially when handling a high volume of concurrent requests.

Out-of-the-Box Price Calculation in SAP ERP

SAP ERP provides a flexible and robust pricing system that enables businesses to configure complex pricing models based on various factors such as customer agreements, discounts, taxes, surcharges, and special conditions. At the core of this system are Condition Records, which store pricing rules in the database and determine applicable prices or surcharges based on a combination of parameters (e.g., product, customer, currency, order quantity). The pricing logic is built around Condition Types, defining the role of each condition (e.g., base price, discount, tax).

Price calculation in SAP ERP follows a Pricing Procedure, which is a structured sequence of conditions determining how the final price is derived. Each condition can be mandatory, optional, dependent on other conditions, or calculated using formulas. For example, a base price may be adjusted by applying discounts, transportation costs, or surcharges. This process is further refined by Access Sequences, which control how the system searches for the appropriate price, checking different data levels (e.g., first for a specific customer, then for a customer group, and finally applying a default price if no specific condition is found).

The complexity increases when business-specific customizations are introduced, adding further layers of logic that can slow down processing. SAP Commerce Cloud integrates with SAP ERP via RFC calls to retrieve real-time prices. The main BAPI used for this purpose is BAPI_PRICES_CONDITIONS, which triggers the standard ERP pricing engine. The request typically includes customer details, product data, and order context.

While this mechanism offers high flexibility, it is not optimal for real-time execution at scale, especially in e-commerce scenarios with a high volume of requests. In standard SAP ERP implementations, prices are typically calculated during order creation or updates. However, when integrating with e-commerce platforms such as SAP Commerce Cloud, businesses often rely on price caching or an intermediary pricing layer to reduce ERP load and ensure acceptable performance. This article focuses on that intermediary layer.

Exporting All Prices to SAP Commerce

A full export of all prices for every pricing condition may not always be feasible, as the number of possible price combinations—multiplied by the number of customers and products—can result in massive data volumes that are impractical for an e-commerce system to handle. However, this approach is sometimes viable when the number of influencing factors is minimal, the product catalog is manageable, and customers can be grouped effectively. Still, when the total dataset reaches tens of millions of price records, it pushes the limits of what is recommended for this method.

The feasibility of this approach improves significantly when users can be grouped, reducing the overall number of required price entries. Similarly, minimizing other contributing factors can help keep data volumes under control. Whether this method is suitable should be assessed on a case-by-case basis, balancing current system constraints with the desired flexibility for future pricing adjustments.

Exporting Pricing Rules to SAP Commerce for On-the-Fly Calculation

This is the most controversial approach, yet it occasionally emerges as a potential option. Replicating the full pricing logic of SAP ERP within SAP Commerce Cloud is neither practical nor advisable, given the complexity of ERP’s pricing engine. However, in rare cases, businesses have seriously considered implementing a simplified version of this approach to reduce dependency on real-time ERP calls.

Hybrid Approaches

Some projects adopt a hybrid strategy, where base prices are preloaded and cached in SAP Commerce Cloud, while customer-specific discounts and conditions are calculated in real-time via RFC/BAPI. This approach reduces ERP load while still allowing for dynamic, customer-specific pricing adjustments.

However, the main drawback remains the same as with exporting pricing rules: maintaining consistency and performance while handling dynamic calculations at scale.

Pricing Service Middleware: Lazy Loading and Caching

A more optimal approach, in my view, is implementing a Pricing Service Middleware layer between SAP Commerce and SAP ERP.

With a flexible architecture, this middleware can operate anywhere along the pricing spectrum, dynamically adjusting between real-time calculations and precomputed caching, depending on business needs and performance considerations.

Pricing Service Middleware: Lazy Loading with Predictive Optimization

Essentially, this approach is a lazy loading mechanism for pricing, enhanced by a predictive load-balancing system that optimizes cache usage based on demand patterns.

This architecture allows for a dynamic balance between real-time calculations and cached pricing, adapting to the system’s needs while maintaining performance and accuracy.

Pricing Service Middleware Components

Pricing API

The Pricing API is an external component, exposed to the public Internet, that serves as the interface for retrieving prices, independent of SAP Commerce. It integrates with both the frontend (to display product prices in product listings and detail pages) and the backend (to validate prices in the cart and during order placement). If a requested price is not present in the cache or has expired, the service fetches it from SAP ERP in real time.

In its most basic form, price calculation requires only a list of products and the identifier of the current user. However, security must not be overlooked—if the service is exposed to the public internet, there will inevitably be malicious users trying to check whether they can retrieve prices for other customer IDs. It is essential to ensure that this is not possible. There are multiple ways to achieve this, such as embedding the customer ID within a JWT token sent to the service.

Additionally, price calculation may require more parameters beyond just the customer ID and product ID, either optionally or mandatorily. For example, the quantity of products might be a factor—on product pages and product listing pages, this value is typically set to a default unit if not explicitly provided.

I highly recommend considering streaming for faster price retrieval. Details can be found below in the Performance Optimization section.

Pricing Storage

This external component stores prices in a persistent cache, such as Redis. Each price entry has a defined expiration period, determining how long it can be shown to customers before requiring an update. The Pricing Storage component also supports bulk price loading directly into the cache—for example, from an ERP price export file. Additionally, it provides bulk removal functionality for specific customers, products, categories, or their combinations, triggering a price refresh when necessary.

 

Price Query Logger

This component collects statistical data on price requests, tracking which products and customers are generating the most queries. The collected data helps inform caching strategies, ensuring that frequently accessed prices are preloaded before customers visit the site.

Price Demand Analyzer

The Price Demand Analyzer processes the data collected by the Price Query Logger, identifying patterns and trends in pricing requests. Based on this analysis, it determines which prices should be preloaded into the cache to improve response times and reduce ERP load.

Predictive Price Preloader

Using insights provided by the Price Demand Analyzer, this component proactively loads prices into the cache ahead of expected requests. It also enables priority price updates for specific customers, products, or categories, either on a scheduled basis or triggered manually by a pricing manager.

Pricing Cache Management UI is a tool for viewing, refreshing, and managing cached prices. It allows manual cache updates, scheduling preloads, and monitoring cache performance to ensure accurate and optimized pricing while minimizing ERP load.

 

Performance Considerations

The first question is—will this approach be fast enough? Since price fetching relies on an external service relative to SAP Commerce Cloud, won’t users notice a delay? Not necessarily.

With a well-implemented system, the delay will be imperceptible—as long as the requested price is in the cache. If the price is missing from the cache, response time will depend on the performance of the SAP ERP API. While I can’t make definitive claims about the speed of your specific ERP system (and if it is too slow, that could jeopardize the entire solution), I can confidently say that if the price is already cached, response times can be extremely fast.

Several optimizations contribute to this:

Fast Storage – Redis

Retrieving data from Redis using simple keys is a blazingly fast operation, as is logging requests. You can reliably expect response times of 50–100ms, which is faster than loading images on most web pages.

Streaming Response Handling

Since the service processes a list of SKUs, some prices may already be cached, while others need to be fetched from ERP. A streaming approach allows immediate delivery of cached prices, displaying them ahead of the ones still being retrieved. The frontend can then progressively update the page as additional prices arrive, ensuring a smooth user experience.

ERP API Limiter

Since there is a chance that not all prices requested by the frontend will be found in the cache (which ideally shouldn’t happen if the Predictive Price Preloader is functioning well), the system will need to fetch missing prices from SAP ERP. This raises a critical concern: how to prevent excessive load on SAP ERP, especially when running a clustered Pricing API.

The challenge here is that multiple instances of Pricing API may independently send requests to ERP. While some aggregation of requests can be done at the service level, there needs to be a global mechanism at the cluster level that regulates request frequency per ERP rate limits.

If such problem really exists, to properly manage ERP load, I suggest introducing a centralized ERP Request Coordinator that acts as a global rate limiter and aggregator. It can serve as a central service responsible for throttling and aggregating requests before calling ERP. It can collect incoming pricing requests from multiple Pricing API instances, group similar requests (e.g., the same SKU for different customers), enforce ERP rate limits using Token Bucket or Leaky Bucket Algorithm, and send requests to ERP in controlled batches instead of one-by-one.

However, this solution is likely overkill, and focusing on the right predictive preloading mechanism seems to be a better approach to addressing the problem.

Predictive Preloading

The Predictive Price Preloader can further optimize performance by ensuring frequently requested prices are proactively cached before users request them. This minimizes real-time calls to ERP, reducing overall latency.

Since you will have insight into the ERP system’s load capacity at different times of the day, the Predictive Price Preloader can be configured to distribute its workload evenly. By scheduling cache preloading during periods of lower ERP activity, the system can efficiently fill the cache without causing performance bottlenecks.

Additionally, this process can be prioritized, ensuring that the most likely-to-be-used price entries are preloaded first. This proactive caching strategy optimizes response times for users while preventing sudden spikes in ERP load, making the entire system more stable and scalable.

Involving real-time events from the e-commerce system

The priority of price preloading can also be dynamically adjusted based on real-time events received from the e-commerce platform. One such event is “user is logging in.”

If there are pending price preloading tasks for products relevant to this user, the system can increase their priority. This ensures that frequently accessed products—especially those from categories the user interacts with most often—are preloaded first.

By leveraging user behavior data and integrating it into the Predictive Price Preloader, the system can further optimize caching efficiency, reducing wait times and improving the overall user experience.

Preloader: architecture

Among all the components listed, this is essentially the most complex one. However, its complexity can be gradually increased as the system evolves, while the initial MVP version can remain relatively simple. Below, I will describe a fully functional solution, but it is not necessarily required for the first version. Additionally, a fully featured implementation might be overkill for your business.

Preloading Scheduler (Orchestrator)

this is a central component that manages price preload jobs. It maintains a priority queue of SKU-customer price fetch requests. The component adheres to ERP rate limits by pacing requests appropriately. Dynamically reprioritizes tasks based on incoming events (e.g., “user logs in”)

Priority Queue (Task Manager)

This component implements multi-level priority handling the numeric score reflecting basically three groups:

• High priority – SKUs frequently viewed by active users.

• Medium priority – SKUs predicted to be needed soon.

• Low priority – Background batch updates.

To organize the queue, it uses FIFO within each priority level, but allows reordering based on new incoming signals and score. It also ensures fairness so that low-priority tasks are not completely starved.

ERP API Rate Limiter

Monitors and controls API calls to prevent exceeding ERP rate limits.

User Event Listener

It subscribes to e-commerce platform events (e.g., User Logs In). The priority of relevant SKU preloading tasks is adjusted when a user session starts. Works with historical data to determine which SKUs/categories the user is likely to need first.

The stats analyzer is a separate component. That component processes past user interactions to predict future demand by maintaining a heatmap of SKU/category popularity per customer. It feeds recommendations into the scheduler to ensure proactive caching. Basically, the stats analyzer knows what SKUs/categories are to be loaded before others.

Monitoring

Effective monitoring is essential for ensuring that the Predictive Price Preloader and Pricing API function optimally without overloading the ERP. A well-designed monitoring system should track cache hit rates, ERP request frequency, response times, and system load. By continuously analyzing these metrics, it becomes possible to fine-tune caching strategies, adjust preloading logic, and proactively address performance bottlenecks before they affect the user experience. The monitoring framework should be capable of providing real-time insights while also retaining historical data to help identify trends and optimize long-term system behavior.

One of the key indicators of system efficiency is the cache hit rate per user, which represents the percentage of requested prices that were found in the cache instead of being fetched from ERP. The higher this percentage, the better the system is performing, as it reduces reliance on real-time ERP requests and improves response times. If the cache hit rate is consistently low for certain users, categories, or SKUs, this signals that the preloading algorithm is not sufficiently aligned with real-world usage patterns. Such insights can drive adjustments to prioritization logic, ensuring that frequently accessed price data is proactively cached before users request it.

Monitoring should also include dynamic rate adjustment based on ERP performance. If ERP response times degrade, the ERP Request Coordinator should slow down its request rate dynamically, preventing system overload. Additionally, alerting mechanisms should be in place to notify administrators when cache hit rates drop below an acceptable threshold, indicating the need for adjustments in preloading or prioritization logic. By continuously analyzing real-time data and adapting the system accordingly, monitoring ensures that price retrieval remains fast, efficient, and scalable.

With these optimizations in place, price retrieval remains fast and seamless, making the system scalable and performant even under high user load.