If you work with D365 Commerce — as an architect, developer, ISV, or integration specialist — you know the feeling. A new version drops, the official docs give you the feature headlines, and then you’re left figuring out the rest: what actually changed in the code and APIs? Which schemas gained new fields? What are those new flight keys doing? Where is the product really heading?
That’s exactly why I started publishing these unofficial Commerce CSU release notes.
Every release, I pull apart the Commerce Scale Unit: decompile the assemblies, diff the OpenAPI specs, trace the new code paths, and map it all to what Microsoft shared about the Release. The goal is simple — give the community the technical depth that doesn’t exist anywhere else.
I’ve been building on Commerce CSU since around 2015. Over 650 APIs, B2C and B2B, headless and POS — this platform is deep, and it deserves documentation that matches.
This edition — V9.57 / 10.0.47 — is the most architecturally significant release I’ve analyzed. Here’s what’s inside.
𝘛𝘩𝘪𝘴 𝘢𝘳𝘵𝘪𝘤𝘭𝘦 𝘳𝘦𝘧𝘭𝘦𝘤𝘵𝘴 𝘮𝘺 𝘪𝘯𝘥𝘦𝘱𝘦𝘯𝘥𝘦𝘯𝘵 𝘵𝘦𝘤𝘩𝘯𝘪𝘤𝘢𝘭 𝘢𝘯𝘢𝘭𝘺𝘴𝘪𝘴 𝘰𝘧 𝘴𝘰𝘧𝘵𝘸𝘢𝘳𝘦 𝘢𝘳𝘵𝘪𝘧𝘢𝘤𝘵𝘴. 𝘐𝘵 𝘪𝘴 𝘯𝘰𝘵 𝘦𝘯𝘥𝘰𝘳𝘴𝘦𝘥 𝘣𝘺 𝘰𝘳 𝘢𝘧𝘧𝘪𝘭𝘪𝘢𝘵𝘦𝘥 𝘸𝘪𝘵𝘩 𝘔𝘪𝘤𝘳𝘰𝘴𝘰𝘧𝘵. 𝘍𝘶𝘭𝘭 𝘥𝘪𝘴𝘤𝘭𝘢𝘪𝘮𝘦𝘳 𝘢𝘵 𝘵𝘩𝘦 𝘦𝘯𝘥 𝘰𝘧 𝘵𝘩𝘪𝘴 𝘢𝘳𝘵𝘪𝘤𝘭𝘦.
A-Overview of this Release
The 9.57 / 10.0.47 Release is defined by 3 architectural shifts: the arrival of MCP (Model Context Protocol) as a first-class CSU endpoint, a fundamental identity model change for B2B Commerce, and the continued maturation of the headless payment and POS modernization story.
The headline is the MCP server embedded directly into the CSU. Microsoft has shipped an MCP endpoint (still in private preview!) with API key authentication, structured tool definitions, and logging. It exposes Commerce capabilities (product search, cart management, payment link creation) to AI agents and agentic platforms. This is not a bolt-on: the CSU now ships with ModelContextProtocol assemblies, AI Abstractions, and Server-Sent Events transport. If you are building agentic commerce experiences — conversational shopping, AI-assisted ordering, or any scenario where an LLM needs to interact with Commerce business logic — the infrastructure is now in the box and ready to be enabled.
The second major shift is the B2B multi-outlet model. Commerce is moving from Customer (Person) type to Contact type for B2B buyers. This is a deep, pervasive change: ContactPersonId now flows through Cart, SalesOrder, security checks, and the entire cart-to-order lifecycle. New APIs support contact retrieval, identity linking, and organization-level catalog access. A feature flag (RetailB2BContactMultiOutletOrderingFeature) gates the rollout, and migration scripts are being provided — but this is a one-way street once enabled. If you are in B2B Commerce, this is the most impactful change to your data model in years.
Third, the POS modernization journey reaches the product listing page, product detail page, and transaction page — all now migrated to React and Fluent UI. What makes this release different from a typical UI refresh is the API surface behind it: eight new VisualProfile flags give you register-level control over which insights (inventory, discounts, product suggestions) are surfaced, and a new promotion evaluation endpoint (GetAvailablePromotionsByTransactionJson) lets the React front-end evaluate discount eligibility without a full server-side cart round-trip.
Alongside these three themes, the Unified Pricing engine (GUP) receives its heaviest investment yet (10 new flight keys), the cross-legal entity inventory story lands with a dedicated API for multi-company store search, and the telemetry stack gets a complete overhaul — moving from the older infrastructure to Azure Data Explorer / Kusto-based observability.
B-Resources
- V9.57 Commerce CSU API explorer (React control with filter/search): https://patrickmouwen.com/wp-content/uploads/2026/04/csu-api-explorer-v57.html
- V9.57 full Swagger/openapi spec (direct download): https://patrickmouwen.com/wp-content/uploads/2026/04/9.57.26071.1.json
C — API and Schema Changes
C.1 New APIs
C.2 Removed APIs
None.
C.3 Data Model Changes
C.3.1 B2B Multi-Outlet/Contact model
- Cart and SalesOrder gained ContactPersonId — this is the primary identifier linking a transaction to the specific B2B contact who placed it, distinct from the organization customer account.
- BusinessPartner gained OrganizationCustomerAccountNumber, Addresses[], and SpendingLimit — enriching the organization-level entity with account resolution and spending governance data.
- BusinessPartnerUser gained ContactPersonId, IsEnabled, OrganizationCustomerAccountNumber, and Phone — the user entity now bridges to the Contact model with explicit activation state and org-level tracing.
- New entity: BusinessPartnerContact (PartyRecordId, IsActivated, FirstName, LastName) — a lightweight Contact representation used by the GetContact API.
- New entity: LinkToExistingDirPartyResult (PartyRecordId, ExternalIdentityLinkRecordId, FirstName, LastName, EmailAddress) — the result of identity-to-party linking during migration.
- New security claim: ContactPersonIdClaimType added to the claims system — the Contact identity is now a first-class authentication claim alongside CustomerId and StaffId.
- New role: “BusinessPartnerContact” added as a recognized principal role.
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: This is the API and data model surface for the fundamental B2B identity shift from Customer (Person) to Contact. A single contact can buy for multiple organizations, orders are created against the organization account (not the individual), and pricing/credit limits/catalogs are driven by the organization. The migration path (CreateLinkToExistingParty) ensures existing B2B users retain their external identity mappings when transitioning.
C.3.2 Cross-Legal Entity Inventory
- OrgUnitLocation gained DataAreaId — stores and warehouses now carry their legal entity identifier in the API surface.
- OrgUnitAvailabilitySearchCriteria gained DataAreaIds[] — the search criteria can now specify which legal entities to include.
- New feature flag: CrossCompanyInventoryLookupFeatureName gates the capability.
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: Enables POS users to see inventory across legal entities in the same fulfillment group. Backed by Inventory Visibility Service (IVS). This may be extended to e-commerce, DOM cross-LE fulfillment with intercompany orders, and decoupled ICO lifecycle in the future.
C.3.3 Asynchronous payments/Pay-by-link
- AsynchronousPaymentParameters gained ReturnUrl and ShopperLocale — supporting proper redirect-based payment flows and locale-aware payment page rendering.
- CreatePaymentLinkParameters gained the same ReturnUrl and ShopperLocale fields.
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: Continuation of the V46 async payment maturation. ReturnUrl enables proper redirect-back after payment completion (critical for QR code / pay-by-link flows where the customer completes payment on a different device or browser). ShopperLocale ensures the payment page renders in the customer’s language — directly supporting the Adyen connector QR code feature announced for 10.0.47
C.3.4 POS Modernization – VisualProfile Feature FLags
VisualProfile gained eight new nullable boolean flags:
- ShowDimensionPickerEnabled
- ShowInlineQtyDiscountMsgEnabled
- ShowNearbyInventoryEnabled
- ShowProductSuggestionsEnabled
- ShowQuantityDiscountCaptionsEnabled
- ShowQuantityDiscountsEnabled
- ShowStockCountAndAvailabilityEnabled
- ShowThresholdDiscountBarEnabled
Where it shows up: All endpoints that return VisualProfile (device configuration, register setup).
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: These are the register-level feature flags for the React/Fluent UI POS modernization. Each flag controls a specific insight or UI element on the modernized search results, PDP, or transaction pages. This gives retailers fine-grained control over rollout — you can enable inventory insights for one register while keeping it off for others, allowing a phased transition and A/B testing of the new experience.
C.3.5 Self-Checkout Language Selection
- DeviceConfiguration gained EnableLanguageSelectionOnSelfCheckoutWelcomePage (boolean), SecondaryLanguages (string[]), and OfflineSQLiteDbExport (boolean).
Where it shows up: Device configuration endpoints.
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: EnableLanguageSelectionOnSelfCheckoutWelcomePage and SecondaryLanguages power the multilingual self-checkout experience. The customer can switch language on the welcome screen, and all UI elements update instantly.
C.3.6 Address Purposes
Address entity gained AddressPurposes (IList of AddressPurpose) — enriching addresses with their associated purpose values (Business, Delivery, Home, etc.).
Where it shows up: This is the single most widespread change in the diff by surface area — virtually every endpoint that returns an Address object now includes AddressPurposes. The change is controlled by the UseLogisticsLocationMultiRoleTypesFlight.
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: Addresses can serve multiple purposes simultaneously. Previously, purpose was inferred or required separate lookups. Now it’s inline — improving address selection logic for delivery, invoicing, and B2B scenarios where a single address may serve both business and delivery purposes.
C.3.7 Unified Pricing – PricingComponentCodeConcurrencyMode
New enum PricingComponentCodeConcurrencyMode with values: None, Compounded, BestPrice, NeverCompound.
Where it shows up: In the pricing engine’s price adjustment evaluation pipeline, controlling how pricing components interact across priorities.
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: Extends the GUP concurrency model with a NeverCompound mode — allowing pricing rules to explicitly prevent compounding with other adjustments. This is part of the broader Unified Pricing maturation that includes fixed price adjustment support, tender discounts, multi-currency conversion, and enhanced concurrency modeling.
C.3.8 MCP Infrastructure
New schema McpException (extends CommerceException) — the first appearance of MCP error handling in the CSU’s public schema.
Where it shows up: Not exposed as an endpoint in the OData Swagger — the MCP server runs on a separate /mcp endpoint using Server-Sent Events (SSE) transport.
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: While the MCP endpoint itself is not part of the OData API surface, the exception type landing in the public schema signals that MCP is now a supported, (soon) production-grade component of the CSU. See Section D for the full MCP code analysis.
C.3.9 Telemetry
EnvironmentConfiguration gained ClientKustoTelemetryKey, HardwareStationKustoTelemetryKey, and KustoTelemetryEndpoint.
Where it shows up: Environment configuration endpoints.
𝐋𝐢𝐤𝐞𝐥𝐲 𝐢𝐧𝐭𝐞𝐧𝐭: The CSU is moving to Azure Data Explorer (Kusto) based telemetry. A new Microsoft.Dynamics.Retail.Diagnostics.Kusto assembly ships with V47, alongside Microsoft Unified Telemetry libraries. This replaces the older telemetry infrastructure with direct Kusto ingestion — enabling richer, queryable observability for Commerce operations.
D —Code Changes
This section goes beyond the API surface and examines changes in the decompiled CSU assemblies (the actual Commerce Scale Unit runtime code). 287 assemblies in V47 vs 265 in V46.
D.1 MCP Server – Full implementation in the box
The most significant code-level finding. The CSU now ships with a complete MCP (Model Context Protocol) server implementation embedded directly in Microsoft.Dynamics.Retail.RetailServerLibrary.AspNetCore.
New namespaces:
- Microsoft.Dynamics.Retail.RetailServerLibrary.Mcp
- .Mcp.Configuration
- .Mcp.Contracts
- .Mcp.Converter / .Converters
- .Mcp.Exceptions
- .Mcp.Middlewares
- .Mcp.Tools
Three tool classes ship out of the box (may be extended):
Configuration via app settings:
𝐒𝐞𝐜𝐮𝐫𝐢𝐭𝐲: Full API key authentication middleware (McpApiKeyAuthenticationMiddleware) with named client support. Comprehensive structured logging via McpEvents enum covering authentication, tool call lifecycle, and errors.
𝐄𝐫𝐫𝐨𝐫 𝐡𝐚𝐧𝐝𝐥𝐢𝐧𝐠: Custom McpException with domain-specific error codes: InvalidChannelId, InvalidCartId, InvalidProductId, InvalidQuantity, CartLineNotFound, CustomerNameRequired, EmailRequired, StreetRequired, CityRequired, StateRequired, ZipCodeRequired, CountryOrRegionCodeRequired, CartHasNoLines, CartMissingShippingAddress, DeliveryModeRequired, DeliveryModeDescriptionNotFound, CartOperationRetryFailed.
𝐍𝐞𝐰 𝐚𝐬𝐬𝐞𝐦𝐛𝐥𝐢𝐞𝐬 𝐬𝐮𝐩𝐩𝐨𝐫𝐭𝐢𝐧𝐠 𝐌𝐂𝐏: ModelContextProtocol, ModelContextProtocol.Core, ModelContextProtocol.AspNetCore, Microsoft.Extensions.AI.Abstractions , System.Net.ServerSentEvents.
D.2 B2B Contact Model – Deep Pervasive Implementation
10+ new data request types span the full data access layer:
- GetBusinessPartnerContactByContactPartyDataRequest
- GetBusinessPartnerContactByContactPersonIdDataRequest
- GetBusinessPartnerContactByEmailDataRequest
- GetBusinessPartnerContactByExternalIdentityDataRequest
- GetBusinessPartnersByContactPartyDataRequest
- GetBusinessPartnerUserByContactPersonIdDataRequest
- GetBusinessPartnerUserByOrganizationCustomerAndContactPartyDataRequest
- GetBusinessPartnerCatalogsByContactPersonIdDataRequest
- GetBusinessPartnerByOrganizationCustomerAccountNumberDataRequest
- CreateLinkToExistingPartyDataRequest
The feature flag 𝐑𝐞𝐭𝐚𝐢𝐥𝐁2𝐁𝐂𝐨𝐧𝐭𝐚𝐜𝐭𝐌𝐮𝐥𝐭𝐢𝐎𝐮𝐭𝐥𝐞𝐭𝐎𝐫𝐝𝐞𝐫𝐢𝐧𝐠𝐅𝐞𝐚𝐭𝐮𝐫𝐞𝐍𝐚𝐦𝐞 is checked throughout the codebase — customer service, security, workflow, and catalog resolution all branch between the old Person path and the new Contact path. Cart access security now validates ContactPersonId as a third dimension alongside CustomerId and StaffId.
D.3 Bing Search Removed
Microsoft.Dynamics.Commerce.Runtime.SearchServices.Bing assembly has been removed from V47. Product search is now exclusively handled by Azure Search / Azure AI Search.
D.4 Telemetry Stack Overhaul
New assembly: Microsoft.Dynamics.Retail.Diagnostics.Kusto — a Kusto logger implementation for Retail components. Accompanied by 6 Microsoft Unified Telemetry assemblies (Microsoft.Unified.Telemetry, .OpenTelemetrySink, .ContractsAndContextProviders, Microsoft.Office.Telemetry.EventFlags, Microsoft.Office.PrivacyGuard). This is a platform-level shift to structured, Kusto-queryable telemetry.
D.5 Unified Pricing Engine – Significant Evolution
Key code-level changes in the pricing engine:
- New PricingComponentCodeConcurrencyMode with NeverCompound support
- GetAttributeTenderDiscounts method added — GUP now supports tender-type (payment-method) discounts via ReadGlobalUnifiedPricingTenderDiscounts
- New GetBasePriceTypeDataRequest/Response — base price type resolution by price tree name
- Generic currency support with exchange rate type conversion — multi-currency pricing across legal entities
- Fixed price adjustment support (OfferPrice method) gated by GUPSupportFixedPriceAdjustmentFlight
- Unit of measure conversion caching for price adjustments
- Enhanced discount header amount currency conversion
- V2 sproc for non-coupon discount category lookups (performance)
E-New Flight Keys
Microsoft implements new CSU flight keys with every new CSU version. These undocumented flight keys steer specific CSU behavior. V9.57/10.0.47 adds 29 new flight keys (picking up from the last V46 key at index 151).
F – Disclaimer
The content of this article represents my independent technical analysis and personal interpretation of publicly available software artifacts. It is not endorsed by, affiliated with, or authorized by Microsoft Corporation. Nothing in this article constitutes official Microsoft documentation, guidance, or product commitments.
All findings are derived from analysis of the software and public documentation. Feature descriptions, presumable use cases, and “likely intent” assessments reflect my professional opinion based on observable code and API changes — they may not reflect Microsoft’s actual design intent, planned behavior, or final implementation.
Information regarding features described as preview, private preview, or roadmap items is subject to change at Microsoft’s sole discretion and should not be relied upon for planning, purchasing, or architectural decisions.
This article is provided for informational and educational purposes only, on an “as-is” basis without warranties of any kind, express or implied. The author assumes no liability for any direct, indirect, incidental, or consequential damages arising from the use of or reliance on the information contained herein, including but not limited to damages resulting from technical decisions, implementation choices, or system behavior based on this content.
For authoritative product information, consult Microsoft’s official documentation at learn.microsoft.com.