Selling Application

What It Models

A selling application supplies the rules and delivery behavior for its product types. Commerce coordinates purchases across these sellers, including its local plain-product participant, using advice, preparation, resource claims and delivery requests.

Identity and Attributes

The registry is shared across workspaces and contains integration declarations rather than customer records. Types describe payload versions, availability protection, cancellation and change fences, delivery grain, acknowledgment deadlines and reporting classification. Optional same-order audience defaults are a Commerce extension to the manifest.

Relationships

Checkout asks for advice and optional holds. Placement requests authoritative preparation and commits resources through application database functions. Fulfilment later dispatches delivery or reversal. Entitlement specifications in the frozen purchase are interpreted by Commerce's grant handler.

Invariants

Registration validates declarations and claim-function execution grants before reconciling the registry. A partial unique index limits active product-type ownership, and retired declarations remain available for historical references. Calls enforce the shared envelope, response schemas and timeouts.

How It Is Stored and Shared

Participants owns registration, registry reads and the invocation client. Remote sellers expose their own functions and claim boundaries; Commerce's local participants run in process. The common contract package defines the shared wire shapes, while Commerce separately validates its manifest extension.

Open Design Questions

Long cart process references cannot pass through the narrower participant envelope. Donation ownership remains a product question. The type-level audience defaults still need alignment with the shared manifest contract.