Case #3: Why using Commerce CSU for Headless Commerce beats custom-built Solutions

In this series of blog posts I’ll share insights, strategies, and proven solutions to address the most common roadblocks and challenges in connecting non-Microsoft e-commerce to D365 ERP.

Today’s Case

Introduction

In this blog post, we’ll take a look at the benefits of using Commerce CSU to expose D365 ERP data for Headless e-commerce solutions. We’ll do this by comparing with more traditional custom approaches.

To take an honest approach, we must first distinct the various types of e-commerce solutions:

Traditional Commerce Platforms: In traditional Commerce platforms, the frontend (user interface) and backend (server, database) are tightly integrated. Backend systems like D365 ERP often deliver data to the platform by periodic data sync and receive transactions via periodic data sync.
Headless Commerce: Headless commerce decouples the UX frontend from the backend. Backend systems like D365 ERP could deliver their product, pricing, attribute, payment, order history and other data by direct API connectivity if performance allows that.
Hybrid: combines elements of both traditional and headless architectures. Businesses might use a traditional platform for core e-commerce functionalities while integrating headless solutions for specific channels or services. Backend systems like D365 ERP could deliver their data by direct API connectivity, data synch or a combination.

Traditionally, companies implemented more monolithic commerce platforms to benefit from its ‘all-in-one’ nature. The platforms were connected to backend systems like D365 ERP and CRM by data synch.

Over the last 5 years, the benefits of more monolith platforms have been challenged fundamentally by the following trends:

Shift in Consumer behavior: Shoppers demand seamless omnichannel experiences, AI-driven personalization, and flexible business models (subscriptions, marketplaces), which platform monoliths struggle to support.
Digital Touchpoints – A traditional website is no longer spearheading sales. Sales is happening via a variety of digital touch points like mobile apps, social commerce (TikTok, Instagram etc), marketplaces, AI chatbots and agents and smart devices (like fridges which can re-order). This requires a headless architecture which enables brands to serve all these touchpoints from a single backend by exposing APIs, whereas traditional commerce platforms struggle because they were built for a single-channel experience (usually web-based).
AI & Automation Require API-First Integration – AI-powered search, recommendations, and automated workflows need real-time data access, which rigid, monolithic architectures cannot efficiently provide.
Regulatory & Security Pressures Have Increased – Compliance with GDPR, CCPA, and PSD2 is complex, and traditional platforms require costly updates to stay compliant, whereas headless solutions can lean on backend systems like D365 ERP which are already compliant.

Because of these trends, headless commerce is quickly winning ground over traditional commerce platforms, both in B2C and B2B.

The role of D365 Commerce CSU

I’ve been working in the domain of D365 Business Applications and Commerce for more than 15 years. If I take an honest look at this domain I can only conclude that D365 ERP and Dataverse (baseline for D365 CE, Customer Service etc) are not suitable to serve Headless Commerce solutions. This is exactly the reason why so many partners and customers have developed a wide variety of custom services and solutions to integrate D365 ERP and CRM/Customer Insights with e-commerce solutions.

In most cases, these efforts hit hard walls like:

Excessive CAPEX investment: most available D365 ERP and Dataverse APIs are Create, Read, Update, Delete (CRUD), but headless commerce requires business-process APIs for areas like Cart management (pricing, promotions, taxes, shipping), Real-time inventory availability (e.g., ATP calculations, warehouse fulfillment) and AI-driven product search and recommendations.
Poor performance: standard D365 ERP OData APIs and Dataverse APIs are not designed for high-throughput, low-latency e-commerce transactions. APIs are often batch-oriented, making them inefficient for real-time customer interactions (e.g., live cart updates, checkout). Dataverse throttling and API rate limits can block high-volume requests, making it unsuitable for peak traffic.
Lack of omnichannel focus: the solution if often architected to serve only a single channel or digital touchpoint.

Dynamics 365 includes a built-in headless architecture that enables direct use of Dataverse and D365 ERP data in headless frontends. This architecture is designed to support own D365 e-commerce and D365 Store Commerce (POS) solutions, making it a robust and well-suited backend for any headless commerce frontend.

This picture outlines the architecture which is part of the standard D365 offering:

1. Dual Write: Data can be synched bidirectionally between Dataverse and D365 ERP in real time by using Dual Write. D365 ERP comes with D365 headless commerce engine (CSU) which consists of a database, microservices and OData API layer with 650 APIs.

2. D365 headless commerce engine: Synching data from Dataverse (via Dual Write) and D365 ERP to the CSU database is out-of-box available bi-directional and near-real time (usually with synch intervals between 1 and 3 minutes**).**

3. Headless commerce architecture: The CSU database acts as a local data cache. It is also possible to deploy multiple CSUs which keep latency to the digital touch points low. Operating on top of the local data cache and microservices architecture, the 650 APIs are performant enough to directly serve as backend for headless commerce. The APIs include commerce specific APIs which are not available in D365 ERP or Dataverse, but which operate directly on top of master data, setup and parameters in D365 ERP and Dataverse. Examples are Cart APIs and APIs which expose Unified Pricing.

4. Additional services. Dataverse Apps and D365 ERP struggle to provide a performant search experience across Inventory, Products and Customers. D365 Commerce headless engine resolves this by teaming up with Azure AI powered search. For example, D365 ERP Product and Attribute information is indexed in Azure AI Search (formerly known as Cognitive search) which is utilized by the Commerce Product Search APIs directly. D365 Commerce CSU also integrates with Customer Insights utilizing Microsoft Copilot and Inventory Visibility.

5. Ready-for-use integration.

The 650 APIs provided by the D365 headless commerce engine (CSU) are ready-for-use. Here on my website you can find a list of all available APIs presented in Swagger UI.

Preliminary conclusions

An article like this can never outline all arguments why D365 commerce headless engine is such a treasure for quick development of high performant and rich frontends for any digital commerce touch point in headless architectires.

But by highlighting just a few benefits compared to custom integration solutions based on D365 ERP and Dataverse, I hope I could convey my personal experience that the use of d365 commerce headless engine will always beat any other custom solution. Whether looking from the angle of efficient investment, time-to-market, omnichannel strategy, scalability or performance, D365 commerce headless engine is always a better alternative than a custom solution.

However, all of these benefits would all be wiped out in one sweep if D365 headless commere engine would not be affordable.

So, before jumping into final conclusions, let’s first address this often-heard argument against the use of D365 Commerce headless engine.

Is D365 Commerce CSU affordable?

To answer this question, let’s first align on some fundamental assumptions:

ERP Backend licensing. Deploying Commerce CSUs requires an organization to have 20 Commerce backend licenses. Standard ERP (Finance/Supply Chain) licenses can often be swapped for 20 Commerce licenses against no additional cost.
Headless licensing and headless use. Commerce CSU was originally developed for D365 e-commerce and D365 Store Commerce App. So, license-wise you either pay for deploying x number of devices running Store Commerce App or D365 e-commerce. If you want to use the D365 headless commerce engine (CSU) for headless frontends, the licensing does not map neatly onto either model, so it becomes a commercial conversation rather than a list price. Treat it as negotiable and get it costed early: it is an architectural assumption with a material price attached, and it should be tested before it becomes a commitment. Note that this licence cost grants access to your ERP and Dataverse data for hundreds or thousands of customers.
Non-headless use. Integrating D365 ERP and Dataverse with more traditional monolith platforms is a totally different ball game than headless architectures. The platforms often come with significant investment due to the proclaimed “all-in-one” nature and integrations are also relatively costly as they involve asynchronous data flows and often complex data mappings and custom business logic (for example for pricing and inventory calculations). Due to this high investment level for platform and integrations, there is often no budget left for d365 headless commerce engine (CSU). Therefore, this article only focuses on the cost for headless e-commerce architectures, which many companies in B2C and B2B commerce transition to at the moment.
Affordable cost per Order (CPO): Total cost of an order including operational and IT related OPEX is often measured as % of Average Order Value (AOV). A portion of the CPO/AOV % will be contributed to OPEX for maintaining the headless commerce solution (frontend and backend). It’s always arbitrary, but from what I’ve seen in my projects over the last 10 years, an affordable CPO/AOV % for a B2C front- and backend is about 0.5-1% for B2C (as AOV and margins are lower) and 1-2% for B2B. If we split the cost for frontend and backend functions in two halfs, then an affordable CPO for backend integration would be about 0.2-0.5% for B2C and 0.5-1% for B2B.
AOV ranges: B2C businesses usually operate in lower Average Order Value (AOV) ranges than B2B organizations. B2C businesses mostly stay within USD 50-250 range where B2B AOVs are often between USD 500 and USD 2000.

Now, with this in mind, I’ve used AI tools to calculate different price points based on the licensing model for D365 headless commerce engine (CSU) - See licensing guide March 2025.

I calculated the price points by the following assumptions:

AOV for B2B in USD: 49 - 100 - 250 - 750 - 1000 - 1500 - 2500 - 4000 - 7500
AOV for B2C in USD: 25 - 50 - 100 - 150 - 250 - 750 - 1000 - 1500 - 2500
Transactional volume for B2B per year: 2500 - 5000 - 10000 - 25000 - 50000 - 75000 - 100000 - 150000 - 250000
Transactional volume for B2C per year: 10000 - 25000 - 50000 - 100000 - 200000 - 500000 - 750000 - 1000000 - 2500000
Color coding B2B in CPO/AOV % for headless backend: red: 1.5 - 100 | amber 1-1.5 | light green 0.5-1 | green 0-0.5
Color coding B2C in CPO/AOV % for headless backend: red: 1 - 100 | amber 0.5-1 | light green 0.2-0.5 | green 0-0.2
Applied discount against standard list price for D365 headless commerce: 55%

Outcome for B2C:

Outcome for B2B:

Conclusions

Although assumptions about affordable CPO/AOV % for headless backend licensing are always arbitrary, I think above matrix at least gives a good overview of percentages of license cost vs Average Order Value (AOV) per order.

What becomes clear from the overviews is that D365 headless commerce engine becomes more and more affordable with either rising volume, rising AOV or both.

In B2C context, a total annual transactional volume of ~500.000 orders (~1370 per day) against a 50-100 AOV already gives you very affordable license cost.

In B2B context, an AOV of 250-1000 already comes with very affordable license cost at low volumes (5000-10000 orders per year).

if your Business does not meet these thresholds, you may try to convince Microsoft to give you a higher discount for headless use, especially when your organization has a hybrid strategy or other strategy which keeps API requests against the CSU lower than average.

About the Author

I’ve been integrating non-Microsoft e-commerce solutions with D365 ERP and CRM since the early days of AX for Retail in 2009. Already back in 2015, I connected an E-commerce platform to D365 ERP by a predecessor of the current D365 Commerce CSU for the first time.

Get in touch via patrickmouwen.com/contact if you need help in implementing:

D365 Commerce on top of ERP including D365 Store Commerce App and D365 e-commerce
Customizing/Extending D365 Commerce, CSU, Store Commerce App and e-commerce
B2C and B2B Headless Commerce/D365 ERP integrations via Commerce CSU
B2C and B2B Commerce Platform/D365 ERP integrations via Commerce CSU
Customer Service operation based on D365 ERP and D365 CE data utilizing Commerce CSU
Social Commerce/D365 ERP integrations via Commerce CSU
Professional App (React.JS)/D365 ERP integrations utilizing Commerce CSU
POS/ERP integration