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.