---
id: CON-COM-ORD-001
name: Checkout
feature: FEAT-COM-ORD-01
product_area: commerce
module: orders
revision: 1
status: draft
product_intent: confirmed
implementation_evidence: observed
source_sha:
  services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b
  react-console: baf6dae382d6f41dce976c7f848667ccc37e076f
definition: >-
  A checkout records a purchase in preparation: its buyer, intended recipients, selected items, governing
  policy and latest preview.
owned_by: MOD-COM-ORD
synonyms:
  - cart
  - basket
not_to_be_confused_with:
  - Order — the customer sale created by placement
  - Price quote — an unstored pricing answer
facets:
  - name: Purchasing parties
    meaning: 'The buyer, acting contact, billing and shipping parties, and the intended holder of each item.'
    used_for: 'Apply purchasing authority, recipient pricing and delivery addresses.'
  - name: Selected items
    meaning: 'Products and quantities with application-specific details, bundle links and validation progress.'
    used_for: Assemble and validate the proposed purchase.
  - name: Governing checkout policy
    meaning: The selected ordering profile and the recorded reason for its selection.
    used_for: 'Determine currency, business unit, payment options and billing behavior.'
  - name: Entered promotions
    meaning: Requested codes and the result of evaluating each code.
    used_for: Explain discounts at preview and placement.
  - name: Temporary reservations
    meaning: Application-held limited units and their expiry times.
    used_for: Protect availability during purchase preparation.
  - name: Delivery and payment selections
    meaning: The selected shipping option and any installment plan under a deposit policy.
    used_for: Calculate delivery charges and payment timing.
  - name: Latest preview
    meaning: The latest calculated amounts and any placement blockers.
    used_for: Compare placement with the customer’s reviewed price.
  - name: Change history and lifetime
    meaning: Attributed edits and the time at which the cart expires.
    used_for: Explain changes and release unfinished shopping.
relationships:
  - to: CON-COM-ORD-002
    statement: Successful placement links the cart to its single resulting order.
    provenance: test
    source: >-
      services-commerce:modules/checkout/tests/e2e/placement.e2e.spec.js#leaves the checkout placed, naming
      the order, its items frozen with what prepare attested, and its trail telling the story
  - to: CON-COM-ORD-003
    statement: The owner of each product type advises on that item and handles any limited-unit hold.
    provenance: observed
    source: 'services-commerce:modules/checkout/services/checkout/participant-calls.ts'
lifecycle:
  - state: Open
    meaning: The cart remains editable.
    how_it_changes: 'Creating a cart enters this state; placement, abandonment or expiry ends it.'
  - state: Preparing
    meaning: Placement holds the cart against concurrent edits.
    how_it_changes: Placement enters preparation and either writes the order or returns through failure handling.
  - state: Placed
    meaning: The cart records a completed placement and is frozen.
    how_it_changes: Successful placement establishes this terminal result.
  - state: Abandoned
    meaning: Shopping has ended without placement and the holds are released.
    how_it_changes: A person abandons the cart or the expiry sweep closes it after seven days.
  - state: Cancelled
    meaning: The cart is closed through the internal cancellation transition and cannot move to another state.
    how_it_changes: >-
      Persistence permits cancellation from open; this does not establish a separate public cancellation
      screen.
acted_on_by:
  - CAP-COM-ORD-001
  - CAP-COM-ORD-002
  - CAP-COM-ORD-003
  - CAP-COM-ORD-004
  - CAP-COM-ORD-005
  - CAP-COM-ORD-009
  - CAP-COM-ORD-011
visible_to:
  - ACT-COM-014
  - ACT-COM-015
  - ACT-COM-016
  - ACT-COM-017
evidence:
  - 'Examined reference: services-commerce:modules/checkout/services/checkout/participant-calls.ts'
  - >-
    Examined reference: services-commerce:modules/checkout/tests/e2e/placement.e2e.spec.js#leaves the checkout
    placed, naming the order, its items frozen with what prepare attested, and its trail telling the story
supersedes: []
---
# Checkout

## What It Is

Commerce gives a purchase a working record before it becomes a numbered sale. A clerk can assemble that record on behalf of a customer, while the engine also supports the member purchasing model planned for the storefront. The checkout connects the choices made during shopping to the order created at placement. It gives staff somewhere to inspect the proposed purchase and resolve problems before asking the customer to pay.

The record brings together people, products and choices that otherwise belong to different parts of the product. CRM supplies the people and addresses. Product information and pricing inform the item selection. Selling applications check the details needed for their own products. The checkout keeps these inputs together so preview and placement can work on the same purchase rather than reconstructing it from a screen.

## What It Is Not

An order represents the sale after placement; a checkout represents its preparation. An unstored price quote answers a pricing question without creating this working record. The order composer is the staff interface to a checkout, rather than another kind of purchasing record. These distinctions matter when staff explain whether a customer has merely selected something or has actually ordered it.

## How It Is Used

The clerk starts with the purchasing customer, adds items and asks for a preview. The composer presents the returned amounts and any problems that prevent placement. Promotion codes, delivery choices and installment selections belong to this preparation. Placement then uses the assembled record to create the sale. Staff can return to the capability descriptions for the precise validation, price comparison and failure handling at each transition.

A checkout also explains unfinished shopping. Its trail connects edits to the person making them, and its lifecycle separates an editable cart from one being prepared, one successfully placed and one abandoned. Limited availability makes that distinction useful: an unfinished purchase may have temporary holds that need releasing. An abandoned checkout is therefore meaningful operational history, even though it never becomes revenue.

## Its Facets

**Purchasing parties.** The buyer, acting contact, billing and shipping parties, and the intended holder of each item. Apply purchasing authority, recipient pricing and delivery addresses.

**Selected items.** Products and quantities with application-specific details, bundle links and validation progress. Assemble and validate the proposed purchase.

**Governing checkout policy.** The selected ordering profile and the recorded reason for its selection. Determine currency, business unit, payment options and billing behavior.

**Entered promotions.** Requested codes and the result of evaluating each code. Explain discounts at preview and placement.

**Temporary reservations.** Application-held limited units and their expiry times. Protect availability during purchase preparation.

**Delivery and payment selections.** The selected shipping option and any installment plan under a deposit policy. Calculate delivery charges and payment timing.

**Latest preview.** The latest calculated amounts and any placement blockers. Compare placement with the customer’s reviewed price.

**Change history and lifetime.** Attributed edits and the time at which the cart expires. Explain changes and release unfinished shopping.

## How It Relates

Successful placement links the cart to its single resulting order. The owner of each product type advises on that item and handles any limited-unit hold. The capability references identify where the detailed behavior is defined; this concept supplies the vocabulary used across those outcomes.

## What It Could Become

The product should decide which party and address corrections staff need while a cart remains open. The product should also settle the storefront scope and the treatment of future selling applications before designing their purchasing screens. Those decisions should use the existing capability rules and open findings rather than imply that a proposed portal experience is already available.
