Canonical · reviewed 2026-09-01

Seller system

How a reusable seller identity becomes eligible to operate inside a Zinorel product instance.

The seller system lets a person or organization reuse an identity across products while keeping every product's commerce data isolated.

The short version

  1. A user can operate one or more existing Parties.
  2. The user chooses or creates a compatible Profile, such as DJ Cloths, and picks a globally unique @handle.
  3. Zinorel connects that profile to the product owner's organization through an Account.
  4. Zinorel connects the account to the exact product instance through an Enrollment.
  5. The enrollment owns that instance's Storefronts and Listings.

This selection-and-enrollment flow is shared platform behavior, not a product-local onboarding database. The layer map is in Seller product access. Every product can use the same flow with its own eligibility, approval, capability, commission, and storefront policies.

Selling does not collect NIC, KYC, or payout bank details. Those are Merchant payments / payouts capabilities, activated later through finance when money movement is enabled. Unverified sellers may still catalog and receive orders; payouts stay escrowed until that capability is active.

Example: DJ Cloths

Sudila creates a brand profile named DJ Cloths with handle @djcloths under his personal party. If both Fiton and another product allow personal-party brand profiles, he may select DJ Cloths in both products.

The profile name, logo, and @handle are reusable. Each product creates a separate enrollment, so its storefronts, listings, approvals, commissions, and operational status remain separate.

On Fiton, buyers reach the brand at fiton.zinorel.com/@djcloths. One shop uses that URL alone. Extra shops in the same instance use nested slugs such as /@djcloths/colombo.

What the seller sees

The product groups profiles beneath their legal Party. An already-enrolled profile opens its current selling context, while an eligible profile without an enrollment can start enrollment. Every structurally valid Profile choice stays visible; Product Instance policy-disabled choices are disabled with an explanation. Directly shared Profiles remain visible in a read-only Party group.

Party rename updates only its display name. Profile edit updates its public display name and @handle independently.