From legacy pricing to unified pricing

Dynamics 365 Commerce provides a common pricing engine for all Commerce channels. Microsoft describes Commerce and non-Commerce pricing differences in Retail sales price management. Recent releases expand unified pricing management, including custom attribute-based rules and migration support from classic trade agreements.

The objective is a deterministic, performant and explainable price — not a direct migration of every historical exception and workaround.

Execution architecture

Commerce HQ Price groups, agreements Discounts, attributes scheduler Commerce Scale Unit Pricing engine Channel database Retail Server APIs POS (MPOS/CPOS) E-commerce Call centre Partner / external API Retail API All channels call the same engine — pricing logic lives in CSU, not in channel code
All channels request pricing through the Commerce Scale Unit engine. External partners must call the Commerce pricing API rather than reimplement the pricing logic independently.
  • Commerce headquarters stores price groups, trade agreements, promotions, attributes and priorities.
  • Commerce scheduler (CDX) distributes channel data on a scheduled basis to each channel database.
  • Commerce Scale Unit hosts the headless pricing engine and the Retail Server API.
  • POS, e-commerce and call centre request calculations for the transaction context via Retail Server API calls.
  • Partner applications must call Commerce pricing APIs — not reimplement the engine.

See Dynamics 365 Commerce architecture overview and Commerce pricing APIs.

Define price context

{
  "channel": "FR-ONLINE",
  "customer": "C-004281",
  "priceGroups": ["PG-WEB-FR", "PG-LOYALTY-GOLD"],
  "currency": "EUR",
  "dateTime": "2026-07-21T20:00:00+02:00",
  "items": [
    { "product": "100245", "quantity": 2, "unit": "ea", "variant": "SIZE-L" },
    { "product": "200017", "quantity": 1, "unit": "ea" }
  ],
  "couponCodes": ["SUMMER26"],
  "affiliations": ["LOYALTY-GOLD"],
  "fulfillment": "ship",
  "catalogId": 0
}

A price has no meaning without channel, customer, price groups, currency, date, quantity, unit, fulfilment method, catalogue, affiliation and coupon context. Omitting any of these fields produces a result that differs from what the customer sees at checkout.

Govern competing rules

FamilyExampleExpected decision
Base price (trade agreement)Channel or price-group agreementSingle starting point per product per channel
Customer price agreementB2B negotiated pricePriority over standard; document the override policy
Simple discount10% category discountExclusive or explicitly compoundable — document the choice
Mix and matchBuy 3 pay 2 (lowest priced)Basket-level evaluation; define eligible product selection
Threshold discount20 EUR off above 150 EUR basketDefine basis (subtotal before/after other discounts) and sequence
CouponSUMMER26Usage limit, stacking rules and valid period — enforced at engine level

Custom attributes

Recent unified pricing capabilities support customer and product attributes for POS and e-commerce scenarios; see Commerce 10.0.45.

  • Controlled naming convention and data type (string, integer, boolean, date).
  • Explicit default value and fallback behaviour when attribute is absent.
  • Managed synchronisation schedule and effective date enforcement.
  • Audit log of rules consuming each attribute.
  • Deprecation plan: a rule referencing a deprecated attribute silently fails — test and retire cleanly.

Prefer stable, governed attributes. A real-time dependency on an external system (loyalty platform, ERP credit status) can make pricing slow or unavailable if the dependency is unreachable during checkout.

Channel data distribution and freshness

The Commerce Data Exchange (CDX) scheduler controls when pricing data reaches the channel database. Understanding the distribution cycle is essential to setting business expectations around price change activation and debugging discrepancies:

CDX Data Distribution (simplified):
HQ Price change created → validated → published
  → CDX job 1070 (Product and prices)
    → Channel database refreshed
      → CSU cache invalidated (may require scheduled job)
        → Pricing engine uses new data

Typical lag: 5–30 minutes depending on schedule and data volume
Flash sale activation: schedule CDX job trigger in pipeline or manually
  • Flash sale prices must be scheduled for CDX distribution before the activation time, not at activation time.
  • Monitor CDX job duration and error rate in the Commerce Operations workspace.
  • Price changes to large product assortments (thousands of items) require distribution load testing before the first campaign.
  • Document the maximum acceptable lag between HQ change and channel availability for each business scenario.

Calculation performance

  • Avoid rules that unnecessarily cover all products, all channels and all customers simultaneously.
  • Limit volatile attributes and real-time external dependencies in pricing rules.
  • Benchmark with small (1 item), medium (10 items) and large (50+ items, mix-and-match) baskets.
  • Measure CSU response latency at peak load (concurrent POS sessions and e-commerce checkout spike).
  • Use only supported caching and invalidation mechanisms — custom caching can produce stale prices.
  • Monitor channel database size growth and index health after large assortment changes.

Make the price explainable

Price breakdown response (example):
Product 100245 × 2
  Base price (trade agreement PG-WEB-FR):     120.00 EUR/unit
  Customer price group adjustment (PG-42):     -10.00 EUR/unit
  Summer category discount 10% (DISC-188):     -11.00 EUR/unit  [compoundable]
  Coupon SUMMER26 (COUP-26):                    -5.00 EUR/unit  [exclusive to coupon family]
  Final unit price:                              94.00 EUR
  Line total (×2):                             188.00 EUR
  Applied rule IDs: PG-42, DISC-188, COUP-26
  Evaluation timestamp: 2026-07-21T20:00:12Z

Support teams and business users need rule identifiers, intermediate amounts, applied price groups and evaluation timestamp. This context must be available in the transaction record, not only reconstructible from logs.

API contract testing strategy

Define a reference basket library: a set of documented input scenarios with expected outcomes. Run these scenarios against every channel (POS, web, call centre, partner API) to detect engine inconsistency early.

Reference basket library (examples):
ID   Channel   Customer     Items                  Coupon    Expected total
B001 FR-ONLINE C-004281     100245×2, 200017×1    SUMMER26  282.00 EUR
B002 FR-POS    anonymous    100245×1               -         114.00 EUR
B003 FR-ONLINE C-004281     300010×5               -         mix-and-match 3P2 applies
B004 FR-CALL   B2B-099      100245×100             -         B2B agreement price

Run the reference basket library as part of the CI pipeline for the Commerce extension project. Any price regression — even a rounding difference — is flagged before it reaches production.

Integration and channel consistency

External applications must call Commerce APIs rather than reimplement pricing. When a channel shows an estimated price (e.g., product page before cart), clearly distinguish it from the final checkout calculation. Inform users when the final price may differ due to promotions applied at basket level.

Contract tests running the reference basket library across all channels are the primary tool for detecting channel inconsistency and regressions introduced by Commerce updates.

Migration strategy

  1. Inventory all existing price groups, trade agreements, discount rules, coupon types and exceptions.
  2. Remove duplicates, expired rules, redundant workarounds and manually overridden prices.
  3. Define the target priority and stacking policy per discount family.
  4. Create the reference basket library with agreed expected outcomes (business sign-off).
  5. Run old and new models in parallel on an isolated environment.
  6. Review every variance between models with the pricing business owner.
  7. Roll out by channel or customer population with enhanced monitoring and a one-week comparison period.

Microsoft introduced streamlined migration support in Commerce 10.0.46; validate applicability to the target version.

Governance checklist

  1. Does every rule have a named owner, an activation date and an end date?
  2. Are priorities, exclusivity and stacking documented and tested?
  3. Does the same reference basket produce a consistent result across all channels?
  4. Are attributes governed, synchronised and audited?
  5. Can the final price be fully explained through rule IDs and intermediate amounts?
  6. Is calculation performance measured at realistic basket and concurrent-user volume?
  7. Do campaign activations include a CDX distribution schedule and a rollback plan?
  8. Do all partner channels call the Commerce pricing API — not a local reimplementation?

Microsoft Learn references

No section matches this search.