Selling Application

What It Is

A selling application contributes the knowledge Commerce needs about a particular kind of product. Commerce coordinates the purchase, but another application may know whether its item is complete, which scarce resource it needs and what delivery means. This division allows a shared cart to contain different product types while preserving responsibility for each purchased line.

The registered declaration describes the product types the application sells and the contract it supports. It connects the item details to the checks and work that can be performed for them. The declaration also tells Commerce how limited units are secured and how delivery work is planned. Registration makes these responsibilities discoverable without making the application itself a product.

What It Is Not

A product is what the customer selects. A product type identifies the kind of item whose behavior an application owns. A store provides a place to present items for purchase. The selling application is the participant responsible for its side of the purchasing contract; its declaration should not be read as a staff role or a storefront configuration.

How It Is Used

During checkout, Commerce asks the application to advise on its items. At placement, preparation provides the accepted purchase details and the resources needed to complete the sale. After acceptance, delivery work follows the resulting plan. Cancellation and amendment can call back to that same owner because changing a purchase may require changing something outside the order record.

This responsibility includes built-in Commerce applications as well as applications owned elsewhere. Merchandise and plain products use the shared structure, even though their delivery needs differ. When an application supplies an entitlement specification, Commerce performs the grant work described by that specification. The participant therefore declares the purchased promise while the appropriate product area carries out each part of it.

Its Facets

Registered declaration. The deploy-time declaration of product types, resource and delivery behavior, item details and supported contract versions. Integrate an application with the common sale workflow.

Owned product types. The active application owner of each declared type and the retirement of omitted types. Route item work to its responsible application.

Required item details. The versioned schema for the details required by a product type. Reject incomplete purchase inputs.

Resource claim strategy. Early holds, placement claims, leases or no resource claim, including the associated database functions. Secure limited availability.

Declared delivery work. The planned work units and delivery kinds for a purchased item. Build the fulfilment work register.

Pricing effects and classification. Pricing benefits contributed by the line and the order kind it implies. Support same-purchase member pricing and order classification.

Commerce-owned participants. The Merchandise participant and the plain-product participant for products requiring no additional delivery work. Use the same contract for built-in sales.

How It Relates

During checkout the application evaluates its items and can reserve their limited units. Placement asks the application to prepare its items, and acceptance enables their delivery. Commerce creates a grant when the application’s item details declare an entitlement specification. 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 maintain a clear contract for application owners, including recovery when advice, preparation or delivery cannot complete. The product should distinguish currently registered types from future integrations in planning material. A future application should demonstrate its purchase, delivery and reversal behavior through the contract before its customer journey is treated as ready for design.