Customer-specific pricing without sacrificing storefront performance.
Real-time, cached, persisted or hybrid — choosing the pricing architecture that survives ERP latency, timeouts and price-consistency requirements.
Why pricing goes wrong online
The storefront caches prices for performance and nobody defined when the cache is wrong. Complex condition logic lives in the ERP but was partially reimplemented in commerce. Availability is shown without agreed tolerances, so promises break at fulfilment. Price calls slow down product listing pages, so the team disables them selectively and inconsistently.
What we put in place
Pricing architecture: Which prices come live from the ERP, which are replicated, and the rules that govern each. Caching & invalidation: Explicit freshness windows per price type, with invalidation triggered by real events. Fallback behaviour: Defined behaviour when the ERP is slow or unavailable — including refusing to show a price. Availability logic: Stock and delivery-date views with tolerances the business signs off on. Performance work: Listing and detail page pricing that stays fast under real catalogue sizes and cart depth. Verification: Automated comparison between storefront prices and ERP results on sampled scenarios.
How we approach pricing
Inventory every price type and where its logic actually lives today. Agree accuracy and freshness requirements per scenario with the commercial team. Design caching around those requirements rather than around convenience. Instrument price calls so latency and error rates are visible. Verify continuously by comparing displayed prices with ERP results.
Pricing questions
Should B2B prices always be fetched live? Not always. Live retrieval is right where conditions are complex or volatile; replication with controlled invalidation is fine elsewhere. The important part is deciding deliberately and documenting the freshness rule per price type. How do you keep pricing fast on listing pages? Through batched price retrieval, targeted caching, and limiting live calls to the scenarios that genuinely need them — measured rather than assumed. What should happen if pricing is unavailable? That is a business decision we make explicit: show a cached price with an indication, hide the price, or block the journey. Silent guessing is the one option we rule out. Can you verify the storefront matches the ERP? Yes. We set up automated comparison on sampled customer and product scenarios so drift is detected before customers find it.