A New ERP, A Familiar Problem
We recently took on a project that required deep integration with Infor M3 – the ERP system widely used in manufacturing and distribution. The requirement was straightforward: display real-time, customer-specific net prices on an Intershop B2B e-commerce platform. No catalogue prices. No generic retail markup. The actual negotiated price for each customer, for each product, for each quantity.
Infor M3 exposes this through its API programme OIS320MI, transaction GetPriceLine. You send a customer number, an item number, and a quantity. M3 returns the net price, factoring in contract pricing, discount matrices, and whatever pricing logic the business has configured.
It works. But it is not fast.
The Problem With Live ERP Pricing
Here is what we measured when calling the M3 pricing API directly from our application:
| Test | Response Time |
|---|---|
| First call (cold) | 754 ms |
| Second call | 427 ms |
| Third call | 423 ms |
| Average | ~535 ms |
Half a second per price lookup. For a single product on a single page, that is acceptable. For a catalogue page displaying twenty products, each with a customer-specific price, it means ten seconds of ERP calls before the page can render.
B2B buyers do not wait ten seconds. They leave.
This is not an M3-specific problem. Every ERP pricing API – whether it is SAP, Oracle, or Infor – faces the same constraint. ERP systems are built for accuracy, not for the sub-second response times that e-commerce demands. They calculate prices by traversing complex rule chains: base prices, customer agreements, volume tiers, promotional discounts, currency conversions. That computation takes time.
The naive solution is to call the ERP on every page load and accept the latency. The wrong solution is to bypass the ERP entirely and hardcode prices in the commerce platform. Both approaches fail – one on performance, the other on accuracy.
The Right Solution: A Smart Caching Layer
We built an intermediate caching layer that sits between the e-commerce frontend and the M3 pricing API. The architecture is simple:
- First request for a given customer-item-quantity combination hits M3 directly. The response is cached with a 24-hour TTL.
- Subsequent requests for the same combination are served from cache. No ERP call.
- Cache invalidation is triggered when pricing rules change in M3, or automatically after the TTL expires.
The cache key is a composite of customer number, item number, and quantity – the same parameters that M3 uses to calculate the price. This ensures that every unique pricing context gets its own cached result. No stale prices. No cross-customer contamination.
The Numbers
Here are the actual results from our production environment:
| Metric | Without Cache | With Cache |
|---|---|---|
| Response time | ~535 ms | 0.15 ms |
| Response time (human-readable) | Half a second | 151 microseconds |
| Speedup factor | 1x | 3,500x |
| Performance gain | Baseline | 99.97% |
| ERP load per repeat request | Full API call | Zero |
Read that again: 0.15 milliseconds. That is 151 microseconds. A page displaying twenty customer-specific prices loads them all in 3 milliseconds instead of ten seconds. The difference is not incremental. It is the difference between a usable platform and an abandoned cart.
What This Means for B2B Commerce
Enterprise pricing is the hardest data problem in B2B e-commerce. Unlike B2C, where a product has one price for everyone, B2B pricing is a matrix:
- Customer-specific contracts – each buyer has negotiated rates
- Volume-based tiers – price changes with quantity
- Discount cascades – multiple discount rules applied in sequence
- Currency and regional variations – the same product priced differently across markets
All of this logic lives in the ERP. It must stay in the ERP – that is where the business rules are maintained, audited, and governed. But the e-commerce frontend cannot afford to wait for the ERP on every page load.
Our caching layer solves this by treating the ERP as the source of truth and the cache as a performance accelerator. The business keeps full control over pricing in M3. The storefront delivers those prices instantly.
Beyond Pricing: The Pattern Applies Everywhere
The same caching pattern works for any ERP data that is read frequently but changes infrequently:
- Stock levels – updated every few minutes, queried thousands of times per hour
- Customer credit limits – checked on every order, changed rarely
- Delivery dates and lead times – calculated by the ERP, displayed on every product page
- Product availability by warehouse – critical for B2B, expensive to compute in real time
Each of these follows the same principle: let the ERP own the data, let the cache own the speed.
Why This Matters for Infor M3 Specifically
Infor M3 is a powerful ERP with deep B2B capabilities – particularly in manufacturing, distribution, and industrial supply chains. Its pricing engine handles scenarios that simpler systems cannot: multi-level discount agreements, customer-specific price lists, promotional overlays, and quantity-break pricing across complex product hierarchies.
But M3’s API layer was designed for system-to-system integration, not for the request volumes and response time expectations of a modern e-commerce frontend. When you connect a storefront directly to M3’s pricing API without an intermediary layer, you are asking an ERP to perform like a CDN. It will not.
This is where integration expertise matters. Knowing the M3 API programme, understanding which transactions support batch operations, and designing a caching strategy that respects the ERP’s pricing logic while delivering e-commerce-grade performance – this is the work that turns a sluggish integration into a competitive advantage.
Bridging the Gap Between Intershop and Infor M3
Intershop is built for high-performance B2B commerce. Infor M3 is built for complex enterprise resource planning. Both are excellent at what they do. But they were never designed to talk to each other at e-commerce speed.
That gap – between the storefront’s need for instant responses and the ERP’s need for accurate computation – is where most integrations fall apart. The frontend team blames the ERP for being slow. The ERP team points out that pricing logic cannot be simplified. The buyer gets a sluggish experience while both sides argue.
Our job is to bridge that gap. We connect Intershop’s composable frontend to M3’s pricing engine through an intelligent middleware layer that gives both systems what they need: M3 keeps full ownership of pricing logic, Intershop gets sub-millisecond responses. No compromises on either side.
This is what deep integration expertise looks like – not just wiring two APIs together, but understanding the performance characteristics of both systems and designing the layer between them so that neither is asked to do something it was not built for.
The Takeaway
If your B2B platform is calling an ERP pricing API on every page load, your buyers are paying the cost in wait time. A well-designed caching layer – with proper TTLs, composite cache keys, and invalidation triggers – can reduce response times by 99.97% without sacrificing pricing accuracy.
We have done this for Infor M3 and Intershop. The pattern is proven, the numbers are real, and the impact on buyer experience is immediate.
If your platform is struggling with ERP pricing performance, get in touch. We will show you the numbers from your own environment.
