Data sources

UBM holds only the basket. Everything else it needs, it reads at request time from other services. This page lists every ingress and egress, so you can tell which system to look at when a value looks wrong.

   ┌──────────────────────┐
   │  your channel        │  REST, synchronous
   │  (webshop, app)      │────────────────┐
   └──────────────────────┘                │
                                           ▼
   ┌──────────────────────┐        ┌─────────────────┐        ┌────────────────────────┐
   │  product master data │───────▶│                 │───────▶│  Checkout Engine  or   │
   │  (PnP)               │  read  │  Unified        │  price │  Promotion Engine      │
   └──────────────────────┘        │  Basket Manager │        └────────────────────────┘
   ┌──────────────────────┐        │                 │
   │  business-unit       │───────▶│                 │───────▶┌────────────────────────┐
   │  events               │ country│                 │checkout│  Customer Order        │
   └──────────────────────┘        └─────────────────┘        └────────────────────────┘

Product master data

UBM reads item data per request from the product-and-price (PnP) query APIs. Nothing is imported in advance, so a catalogue change is visible to the next recalculation.

Source	What UBM takes from it
Complete item query	Item name, sales unit of measurement, price specifications, and item identifiers — the enrichment described in How pricing works
Item identifier query	Identifiers for a single item. Needed only on the CHECKOUT path — see below
Price specification query	Price specifications for an item, on the PROMOTION path

⚠ The item identifier is a Checkout Engine concern. The Checkout Engine matches items the way a till does — on the identifier that would be scanned, a GTIN or PLU — so a basket priced by it needs one per line. The Promotion Engine matches on the item id instead and does not need an identifier at all. So a business unit on PROMOTION need not supply GTIN/PLU, and the identifier lookup above is not consulted for it.

⚠ A product-master failure fails the request. UBM does not price a basket from partial catalogue data — if item data cannot be fetched, the call returns an error rather than falling back to whatever you supplied. This is deliberate: a silently mispriced basket is worse than a failed request.

Business-unit country codes

UBM subscribes to the business-unit event stream published by Business Unit Management and keeps the country code of each business unit. This is the only event stream UBM consumes, and it exists for one purpose: resolving which per-country Checkout Engine instance to call.

Consequences worth knowing:

• A newly created business unit on CHECKOUT is usable once its business-unit event has been processed. Until then, baskets for it fail with 404 Not Found. Business units on PROMOTION do not depend on this.
• A country change on an existing business unit takes effect when the corresponding event arrives.

The calculation engines

Covered in How pricing works. Whichever applies is called synchronously, inside the request:

• Checkout Engine — HTTP, one instance per tenant and country, stateful, returns price and tax
• Promotion Engine — gRPC, a single shared multi-tenant instance, stateless, returns 🛑 price only, no tax

Customer Order

At checkout UBM calls the Customer Order service to create the order, then marks the basket completed. UBM does not own the order afterwards, and does not track its fulfillment or payment lifecycle — see Checkout.

Identity and access

UBM calls the IAM service to resolve permissions, and the business-unit service for business unit details. Callers authenticate as they do elsewhere on the platform; every endpoint is business-unit-addressed, so the caller's access to that business unit governs the call.

What UBM stores itself

Only basket state: the input basket and its sub-resources, the calculated result, tender configurations and tender authorization data, and the per-business-unit engine selection. Baskets are working state, not a system of record — once a basket is checked out, the durable record is the customer order.