Before you buy another Commerce and/or Pricing engine, look at Dynamics 365 CSU

Dynamics 365 Commerce Scale Unit can expose ERP-native pricing and commerce logic to B2C, B2B, POS, service and agentic channels — without rebuilding that logic in a second platform.

A headless commerce programme often starts with a storefront selection. Then somebody asks where pricing will live.

That is usually the wrong order.

For a Dynamics 365 customer, the more useful question is:

Before adding a pricing engine, have we assessed the engine already sitting next to our ERP?

Dynamics 365 Commerce Scale Unit (CSU) is the runtime behind Microsoft’s own POS and e-commerce channels. It can also serve third-party storefronts, apps, customer-service solutions, Dataverse applications and partner channels. This is not an argument for using the Microsoft storefront everywhere. It is an argument for separating the frontend decision from the commerce-engine decision.

I have used this pattern in customer solutions since 2016. What has changed is its visibility.

CSU is more than Microsoft’s storefront runtime

For years, most public examples centred on Store Commerce and Microsoft’s e-commerce stack. That made CSU look like internal plumbing.

Microsoft now describes CSU as the central integration point for commerce business logic and partner channel solutions. Retail Server exposes the APIs, Commerce Runtime executes the logic, and the channel database provides the channel-side data store. External applications consume the same headless engine over HTTPS.

The API surface is substantial and release-dependent. In CSU 9.58 / Dynamics 365 version 10.0.48, my independent Commerce API Explorer indexes 650 endpoints. Recent Headless Commerce Integration guidance and the Microsoft FastTrack samples also make patterns for products, customers, inventory, pricing, orders and payments easier to discover.

That shift deserves credit: the product group, FastTrack contributors and the Commerce community have made third-party use far more accessible.

Data is distributed from Dynamics 365 headquarters through Commerce Data Exchange, with real-time services used where required. The customer-facing channel talks to CSU instead of treating the transactional ERP application as a storefront runtime.

I have seen teams try the direct ERP route. It can be appropriate for controlled system-to-system calls. It is a poor fit for browse, basket and checkout traffic with high concurrency and peak load. Microsoft makes the same distinction: the direct Unified Pricing Management calculation API is intended for low-to-moderate-frequency requests and is not a replacement for the CSU pricing APIs.

Customer-service and Dataverse applications can use the same secured CSU pattern. Whether dual-write is used for surrounding process data is a separate architecture decision; it does not have to sit in the synchronous pricing path.

Pricing is executable logic

A price is not a row in a table. It is the result of context, commercial data and ordered rules:

• customer, price group, affiliation and loyalty status;
• channel, currency, date, unit, quantity and basket composition;
• trade agreements, pricing attributes, coupons and advanced discounts;
• priority, best-price, compound-concurrency and authorised overrides.

Commerce pricing APIs include operations such as GetActivePrices, CalculateSalesDocument, promotions and coupons. CalculateSalesDocument can evaluate products together in one basket — essential when a discount depends on the complete transaction.

A platform such as commercetools can still be the right choice, especially when pricing must become ERP-independent. Its documentation is equally clear: with external prices, the implementation must retrieve the correct price and place it on the cart. The platform provides flexibility; it does not remove integration ownership.

Compare the operating model, not only the licence

The relevant comparison is not Microsoft licence versus third-party licence. It is the cost of operating one commercial model versus two connected models — once, up front, and then every year.

Read that table from the top down. On the visible licence line the third-party engine wins by €76,000 a year — the number that tends to reach the steering committee. Total OPEX then runs €258,000 a year the other way, and the one-time build is €550,000 lower. The line that is easiest to compare is the only line that favours the alternative.

A separate engine is a sound choice when independence is a deliberate capability: several ERPs must be served, pricing has its own product team, or vendor neutrality outweighs reuse of Dynamics logic.

When Dynamics remains the commercial source of truth, the less visible costs deserve equal weight: mappings, events, queues, storage, retry handling, monitoring, reconciliation, regression testing and incidents caused by two systems calculating a different answer. These start as CAPEX and become recurring OPEX.

Commercial reality: model it early

Microsoft’s public e-commerce model is based on transaction volume and average order value and includes a cloud CSU. It is not presented as a separate public headless-only SKU. Commercial terms can vary, so price the actual scenario with Microsoft before licensing becomes an architecture assumption.

The following heatmaps show annual licence cost per order as a percentage of order value, across a range of volumes and average order values. They are illustrative — a model to think with, not Microsoft list pricing and not a commercial promise.

With those percentages in mind, be clear about what they buy. That is the price per order for a scalable commerce and pricing engine with 650+ APIs, integrated with D365 ERP out of the box, executing the ERP’s own business logic across cart handling, price calculation and stock availability — and managed by Microsoft rather than by you.

It is easy to buy a collection of best-in-class applications and assume that what you now own is a best-in-class architecture. Usually it is not. The cost and the complexity do not disappear — they move, and the integration layer is where they land.

That is why licence against licence is the wrong comparison. A third-party commerce or pricing engine can look cheaper on the visible line and still cost more per order once you count the estate around it: the mappings, events, queues, storage, reconciliation and monitoring that CSU largely brings out of the box.

Capability deserves the same scrutiny. Assume for a moment that a platform is genuinely richer in functionality than CSU for a given requirement. It is still bounded by what reaches it. An engine can only price as well as the data it is given, and the quality, freshness and semantics of that data are decided by the integration rather than by the engine. A better engine, poorly fed, is an expensive way to be disappointed.

None of which makes CSU the cheaper answer by default. It makes the visible licence line an incomplete basis for the decision. Compare the total cost per order, and compare it against the integration estate you would no longer need.

The next channel may be an agent

Microsoft’s Commerce MCP server is now in preview and exposes the existing headless engine to compatible agents. Pricing, promotions, inventory and order logic remain in the same runtime instead of becoming shadow logic for another channel.

My recommendation

Before adding another commerce and/or pricing engine, do not start by comparing features, or the licence cost of the engine itself.

Take an omnichannel view — e-commerce, customer service, business partners, reseller platforms — and look at the wider context: integrations, data freshness, maintenance and support for the solution as a whole, and TCO. Then make an honest decision about price and quality at the bottom line, rather than on the line that is easiest to compare.

Then go and get the evidence. Run a focused proof of concept with the hardest basket the business can produce: customer-specific pricing, quantity and threshold discounts, a coupon, loyalty, mixed products and a fulfilment decision. Measure price correctness, latency under realistic concurrency, operational ownership, and total cost of ownership including the integration estate.

Sometimes the best new commerce and/or pricing engine is the one already sitting next to your ERP.

---

Sources and further reading

1. Microsoft — Dynamics 365 Commerce architecture overview
2. Microsoft — Headless commerce architecture
3. Microsoft — Get started with Headless Commerce Integration
4. Microsoft FastTrack — Headless Commerce Integration Samples
5. Microsoft — Commerce pricing APIs
6. Microsoft — Pricing calculation API for external systems
7. commercetools — Pricing and discounts overview
8. Microsoft — Dynamics 365 Commerce MCP server (preview)
9. Microsoft — Dynamics 365 licensing guidance
10. Commerce API Explorer and community tools
11. Case #3: why using Commerce CSU headless beats custom-built solutions

Disclaimer

The content of this article represents my independent technical analysis and personal interpretation of publicly available software artefacts. It is not endorsed by, affiliated with, or authorised by Microsoft Corporation. Nothing in this article constitutes official Microsoft documentation, guidance, or product commitments.

All cost figures are illustrative and exist to show the shape of the comparison, not to predict a price. Actual costs depend on volume, scope, discounting, implementation, operations and existing architecture. Licensing and commercial terms vary by customer and change over time — validate the current Product Terms and your own agreement with Microsoft or your licensing partner before treating any of this as a basis for a decision.

Information regarding features described as preview is subject to change at Microsoft’s sole discretion and should not be relied upon for planning, purchasing, or architectural decisions. This article describes the product as at the date of publication above.

For authoritative product information, consult Microsoft’s official documentation at learn.microsoft.com.