--- id: CON-COM-CAT-001 name: Checkout Policy feature: FEAT-COM-CAT-01 product_area: commerce module: catalog revision: 1 status: draft product_intent: confirmed implementation_evidence: observed source_sha: services-commerce: c8b66a98e2490617aec38ba5c8165dd9bd0a8f9b react-console: baf6dae382d6f41dce976c7f848667ccc37e076f definition: >- A checkout policy collects the processing choices a sale follows, including its Accounting unit, currency, payment and invoicing arrangements. owned_by: MOD-COM-CAT synonyms: - Ordering profile - Order type (Rhythm 1.0 and the earliest 2.0 build) not_to_be_confused_with: - The selling context that references the processing policy - 'A business unit, which Accounting owns and a policy exclusively names' - 'A payment method, which Accounting lists and a policy exclusively offers' facets: - name: Business unit and currency meaning: The business unit and currency determine the sale’s financial frame. used_for: 'Each price, invoice and payment of the order.' - name: Payment settings meaning: >- Tender timing, offered methods and default accounts describe how payment is collected. used_for: Selecting checkout payment arrangements. - name: Card acceptance and card fee meaning: >- Acceptance settings and fee policy describe the card options available during tender. used_for: Presenting supported payment choices. - name: Invoicing and fee products meaning: Invoice choices and fee products connect processing with Accounting. used_for: Supplying Accounting’s invoice context. - name: Workspace default and application defaults meaning: Workspace and application defaults provide reusable fallback selections. used_for: Deciding which policy a purchase follows. - name: Used By meaning: Commerce-held references explain dependencies staff can inspect. used_for: Explaining why a policy is prevented from being removed. - name: Tax zone meaning: >- Commerce’s interim zones and rates support address-based calculation, although their relationship to Accounting configuration remains unresolved. used_for: >- Taxing a checkout by the purchaser’s address while tax determination is settled. relationships: - to: CON-COM-CAT-002 statement: >- Multiple stores can share a policy, while each store references one policy. provenance: test source: >- services-commerce:modules/configuration/tests/e2e/stores.e2e.spec.js#answers 400 to a store without an ordering profile - to: CON-COM-CAT-004 statement: >- The policy’s currency is the currency each price of the order is calculated in. provenance: observed source: >- services-commerce:modules/checkout/services/checkout/ordering-profile-resolution.ts:1 lifecycle: - state: Active meaning: The policy is available for new sale processing. how_it_changes: >- Created active; customer staff can switch it off except when it is a default. - state: Inactive meaning: >- The inactive policy cannot support a new checkout; retained order settings remain independent. how_it_changes: Customer customer staff switch it back on. acted_on_by: - CAP-COM-CAT-001 - CAP-COM-CAT-002 - CAP-COM-CAT-004 visible_to: - ACT-COM-001 - ACT-COM-004 evidence: - >- Pinned service inputs: modules/configuration (ordering profiles, defaults, tax zones), docs/decisions/ordering-profiles.md, the COMM-M1 record (D9) and plan (A1 to A3) - 'Pinned console inputs: components/commerce/ordering-profiles/**' supersedes: [] --- # Checkout Policy ## What It Is Staff use a checkout policy to describe a way the organization sells. A bookstore sale, a conference purchase and an invoiced corporate purchase may need different processing choices even when they contain the same product. The policy gives those choices a name so staff can recognize and reuse them when configuring selling contexts. The record brings money, payment and billing choices together. Staff identify it by a stable configuration reference and a readable name. The name helps people choose the appropriate arrangement; the reference lets stores and applications continue using the same record after descriptive information changes. A policy can be active or inactive, and existing orders retain the processing settings captured for them. The term ordering profile describes this same configuration in service contracts. Staff encounter Checkout Policies in the console. Rhythm’s earlier order-type and checkout-setting ideas provide useful background, but the current policy is the place where these reusable choices are collected. ## What It Is Not A policy differs from the store that offers products and from Accounting’s business unit that receives their money. It refers to payment methods and merchant accounts owned elsewhere. Product price rows remain part of product pricing. The policy supplies processing context rather than a list of items or a promise to retain a previewed price. ## How It Is Used Administrators create and inspect policies before attaching selling contexts to them. They review the payment summary and the records shown in Used By when deciding whether a policy still serves the organization. A replacement can fail because the record changed while open, a selected money reference is unsuitable or another configuration depends on the policy. These failures preserve the saved configuration for staff to revisit. ## Its Facets **Money context.** The business unit and currency determine the sale’s financial frame. **Payment arrangements.** Tender timing, offered methods and default accounts describe how payment is collected. **Card choices.** Acceptance settings and fee policy describe the card options available during tender. **Billing references.** Invoice choices and fee products connect processing with Accounting. **Defaults.** Workspace and application defaults provide reusable fallback selections. **Usage.** Commerce-held references explain dependencies staff can inspect. **Tax geography.** Commerce’s interim zones and rates support address-based calculation, although their relationship to Accounting configuration remains unresolved. ## How It Relates Stores reference policies, while checkout applies the selected policy to a sale. Pricing uses the sale’s currency. Accounting supplies the financial records and later handles invoices and payments. This module owns the configuration without taking ownership of those downstream transactions. ## What It Could Become The product should reconcile the narrower resolution read with checkout selection and settle tax ownership before relying on one staff-visible configuration. It should also decide how to handle unavailable account validation and complete the delivery of currently ineffective billing settings.