Prepare a WooCommerce multivendor store by defining who owns products, which actions vendors may perform and how each order reaches fulfilment. Test permissions and records using separate vendor accounts. Keep customer payment, vendor commission and delivery evidence distinguishable so the operator can investigate an incomplete order without guessing who should act.
Start with the operating arrangement. Decide who approves a vendor, who checks product information and who responds when an order needs attention. Translate those decisions into a permissions and handover sheet before configuring an extension. The resulting records should help the operator follow an item from listing through fulfilment.
What does Product Vendors provide in this example?
WooCommerce’s Product Vendors documentation describes a specific extension rather than a feature assumed for every WooCommerce store. Product Vendors allows existing products to be assigned to vendors. Sales still pass through the store’s normal payment gateways. Identify the installed extension and its documentation before applying the setup guidance.
The store owner controls the commission assigned to each vendor. Record the agreed arrangement separately from the software setting used to implement it. The operator needs to understand what has been configured and which approved business decision it represents, without the configuration screen silently becoming the commercial agreement.
Its Publish Products setting determines whether a vendor can publish without approval. Choose the intended approval route for each relevant account. Then test both a new listing and an edit using that account, recording what becomes public and what waits for the store owner’s decision.
A Vendor Admin can trash products, while a Vendor Manager cannot. Use that distinction when defining who should manage a catalogue and who should have destructive permissions. A role label alone is not enough for acceptance: the reviewer should attempt representative allowed and disallowed actions in the test arrangement.
How should vendor access be checked?
The publisher’s Vendor Guide describes the vendor-facing workflow. The Vendor Guide describes a pending role until the store owner approves registration. Write down the approval evidence the business requires and identify who can make that decision. Software registration and the operator’s acceptance process should remain understandable to the people administering them.
Vendor reports cover the vendor’s own sales. Prepare separate fictional vendors and products so the reviewer can check which records each user can see. Include a direct-link attempt to another vendor’s sample record as well as normal dashboard navigation, within the authorised testing scope.
A user who supports several vendors may need a different arrangement from someone who manages only one catalogue. Keep the account-to-vendor assignment visible in the permissions sheet. Ask the reviewer to identify the active vendor context before editing a product or interpreting an order record.
Record the actual results and configuration versions. If an account sees more than intended, investigate the role and vendor assignments before treating the extension’s documented behaviour as proof of the store’s current access boundaries. Retain the observations so the maintainer can reproduce the same test.
Which records connect payment and fulfilment?
The commissions page includes commission, shipping and fulfilment status information. Use those records alongside the underlying order when investigating a vendor query. Identify which item belongs to which vendor and which configured commission arrangement applies before deciding that a record needs correction.
The guide assigns fulfilment and shipping responsibility to vendors after a purchase. The documented vendor order email notifies a vendor of a new order. Agree how the business will recognise an unacknowledged notification and who follows up when the relevant vendor has not acted.
The original worksheet below is designed for an operator reviewing an order across several responsibilities. Complete it with the store’s actual process and approved sample records.
| Handover | Record to inspect | Question to answer |
|---|---|---|
| Listing approval | Product and publishing permission | Who can make this item public? |
| Vendor assignment | Product’s vendor and account mapping | Who owns the next fulfilment action? |
| Customer payment | Order and selected gateway record | What state has the transaction reached? |
| Vendor notification | Intended recipient and sample email | Did the responsible party receive the instruction? |
| Fulfilment | Item-level action and related status | Which item remains outstanding? |
| Commission review | Applicable setting and commission record | Does the record reflect the approved arrangement? |
Keep payout-provider eligibility and operational requirements as separate implementation questions. Confirm them against the current documentation for the actual extension version and chosen method. An order record or commission calculation should not be treated as evidence that money has reached a vendor.
Original split-order handover exercise
Create a hypothetical store with two vendors, each owning a different sample product. Give one sample user the intended manager role for the first vendor and another the intended role for the second. Use a controlled checkout and notification arrangement approved by the operator.
Begin with catalogue permissions. Ask each user to edit their own sample item and attempt to reach the other vendor’s item. Inspect the publishing and product-removal actions relevant to the intended role. Record the results against the permissions sheet, including any action that was unavailable or unexpectedly allowed.
Next, prepare an approved sample order containing an item from each vendor. Follow the order into its vendor-related records and inspect the intended notifications. Ask each vendor user to identify the item they are responsible for and the evidence expected when they complete their part of fulfilment.
Introduce a fictional unresolved delivery question for only one item. Have the operator locate its vendor assignment, order state and relevant status without marking the other item’s work incorrectly. The useful outcome of the exercise is a reviewable record of where responsibilities and evidence are clear or incomplete.
Finally, ask the operator to explain the difference between the customer order, the commission record and any separately verified payout. Keep the agreed follow-up owner with an unresolved sample. Revise the handover instructions where the reviewer had to rely on undocumented knowledge.
Before adoption, have another authorised colleague read the worksheet and explain how a new vendor would enter the process. Ask them to identify who approves access, checks a listing and investigates an unfulfilled item. This review helps turn configuration choices into instructions the operating team can actually use.
Retain a sample exception with the handover, such as a notification addressed to the wrong vendor contact. State how the operator should recognise it, where the contact assignment is reviewed and who confirms the correction. Repeat the affected sample after the change. This gives the team an actionable troubleshooting example and keeps a permission correction separate from a decision about who should fulfil the order.
For related work, see online payments and website development. Get started with your vendor model, product responsibilities and order-handling requirements.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.