Checkout

What It Models

A checkout holds a purchase in progress on the server. It brings together the purchasing subject, billing party, item recipients and governing policy, then saves the calculation that the buyer reviews before placement. Staff use the composer to build it; the API also supports buyers acting for their own contact.

Identity and Attributes

Order numbers are allocated only after placement. The cart keeps CRM references for its parties and application-specific purchase intents for its items. Its preview preserves the detailed calculation so placement can compare line prices and quantities, audiences, discounts and fees.

Relationships

Placement links the cart and sale without making the cart a permanent financial record. Each item's registered application supplies its meaning and preparation results. Commerce reads party information from CRM without owning those records.

Invariants

Database constraints protect the placed-order link, policy and currency pairing, complete shipping-party references and quantity bounds. Service transitions protect completed carts, while mutation persistence records versions and attributed events. The invariant rows identify the enforcement evidence.

How It Is Stored and Shared

Checkout owns the cart, item selections and event trail. Orders locks and reads the cart during placement; reservation expiry can also update its items. Application calls exchange envelopes rather than granting sellers table access. Export is available, custom fields and Quick Search are absent, and the intended thirty-day cleanup has no running sweep.

Open Design Questions

No current caller enters cancelled status. Preparing exists only within placement's transaction, and completed carts remain stored. Supporting more than one governing policy would require a product decision about splitting purchases.