Skip to main content
Every store has a status that decides whether it can trade. The status lives in the status field of Seller, typed by the SellerStatus enum, and only dedicated workflows move it. Each transition validates the current status, records a reason or a timestamp, emits an event, and exposes a hook you can extend.

​
The four statuses

A store is in exactly one status at a time. New stores start in pending_approval unless you pass another status to createSellersWorkflow. The Store API seller and offer listings return only open stores that aren’t inside a closure window. A store in any other status disappears from those listings, but its records stay intact.

​
Transitions

Each transition is its own workflow, and each one checks the starting status before it writes. A Status transitions table for the Seller module listing each lifecycle workflow with the status it starts from, the status it sets, and the event it emits, with the terminate row highlighted because only a suspended or pending store can be terminated. A Status transitions table for the Seller module listing each lifecycle workflow with the status it starts from, the status it sets, and the event it emits, with the terminate row highlighted because only a suspended or pending store can be terminated. The workflows accept these starting statuses: Any other starting status fails with a NOT_ALLOWED error and changes nothing.
You can’t terminate an open store. Suspend it first, then terminate it.
Termination isn’t final: unterminateSellerWorkflow brings a store back as suspended, and you then unsuspend it to reopen. Use suspension to reject a pending application: it stamps rejected_at and keeps the reason in status_reason.

​
Scheduled closures

A scheduled closure takes a store offline for a window without changing its status. Set closed_from and closed_to, and optionally a closure_note for the reason. Both the operator and the store’s own members can set these fields. The Store API filter shows a store only when both bounds allow it:
  • closed_from: null, or later than now
  • closed_to: null, or earlier than now
The store comes back once closed_to passes, with no job or workflow involved. Set the fields as the closure starts, for example from a scheduled job, because a future closed_to hides the store right away even when closed_from is also in the future.
This closes the store from now until December 27. A closed_from in the past with a null closed_to hides the store until you clear the fields.
Closures filter the Store API seller and offer listings. They don’t block cart or checkout workflows, so add your own check there if a closed store must refuse orders.

​
Premium

is_premium is a boolean that defaults to false. The Admin API accepts it on create and update, and the Vendor API doesn’t, so only the operator can set it. Mercur stores the flag and returns it, and your storefront decides what premium means, such as featured placement or a badge.