Prepare a multivendor Shopify store by defining seller identity, order responsibility and settlement records before selecting an app or programme. Check eligibility separately for every proposed payment arrangement. Use the worksheet below to examine a documented retailer-and-supplier model, then specify the seller access, fulfilment and accounting behaviour your own marketplace design still needs to demonstrate.
Which kind of seller relationship are you building?
Start by describing the commercial arrangement in plain language. Identify who presents the offer, who receives the customer’s order, who prepares the goods and who owes payment to whom. Decide which party handles a customer question when an order spans several sellers. Keep the answer with the project brief before comparing software labels.
Shopify Collective provides one specific documented model to examine through those questions. It should be evaluated within its own requirements rather than assumed to be a general marketplace implementation. Zambia is absent from Shopify Collective’s published supported-country list checked on 24 October 2026, so a Zambia-based store does not meet its documented store-location requirement. Documentation. The Collective example below concerns eligible stores in supported countries. Use the seller-to-settlement worksheet to assess other marketplace arrangements against their own documented availability and terms; choose any provider only after that evidence is established.
Shopify Collective requires an active Shopify plan. Documentation. A Collective connection requires the stores to share a country and currency. Documentation. Shopify Collective requires completed Shopify Payments setup and active payouts. Documentation. Collective requires Shopify Network Intelligence to be active. Documentation. Collective requires a supported currency as the store’s default currency. Documentation. The Shopify Payments payout-account currency must match the Collective store’s currency. Documentation. Put those requirements on a separate eligibility record for the proposed arrangement, alongside the publisher’s remaining programme, verification and policy requirements. The useful first decision is whether that particular model is available to the actual participants, not whether a demonstration account can show attractive products.
What should a seller record establish?
Create a proposed seller record with a stable identity, responsible contact, permitted catalogue scope and operational handover route. Record the actual agreement and settlement reference through the business’s approved process. Ask the selected platform or app to demonstrate how that record relates to products and orders.
Specify seller access separately. A seller may need to update their own catalogue or fulfilment information without seeing another seller’s customer records. Give the evaluator a permitted task and a cross-seller task using synthetic data. Keep the expected decisions explicit before the demonstration.
A newly ineligible Collective retailer cannot connect or sell until requirements are met. Documentation. Include a participant whose eligibility or operating status changes in the proposed evaluation. Ask which new sales should stop, which existing work remains and who informs the customer. Use the actual chosen system’s documentation to establish its behaviour rather than assuming all multivendor arrangements share the same rules.
An original seller-to-settlement worksheet
Use this practical checklist for a representative order involving more than one seller. It is an original requirements aid, with fields to populate from the actual commercial and technical arrangement. For participants meeting Collective’s supported-country and other requirements, its documents supply a bounded example. For a Zambia-based arrangement, populate this worksheet from the actual chosen system and commercial agreement.
| Relationship boundary | Information to specify | Question before acceptance |
|---|---|---|
| Seller identity | Party reference, responsible contact and applicable eligibility | Who is responsible, and is the chosen arrangement available to each party? |
| Catalogue ownership | Products and permitted edit scope | Can the seller affect only the intended records? |
| Order allocation | Items, quantities and assigned seller | Which party prepares each part? |
| Customer contact | Service owner and update responsibilities | Who explains a split or delayed order? |
| Settlement basis | Actual agreement, charges and adjustment records | What is owed and which evidence supports it? |
| Payment state | Provider reference and observed status | Is the payment complete or still outstanding? |
| Exception | Ineligible party, missing goods or disputed adjustment | Who decides the next action? |
Keep the customer order reference connected to the seller-specific work and settlement references. Ask the reviewer to trace each part without relying on a shared product name. Include a change to one seller’s item so the evaluation tests whether the other seller’s records remain understandable.
Have the responsible business owner define actual commercial terms and accounting treatment. The software brief should capture those decisions accurately, while the operational worksheet makes the associated record and approval route visible. Do not fill an undefined settlement rule with an estimated commission or invented payment commitment.
What does the documented Collective payment model show?
In Collective, the retailer receives customer payment and owes the connected supplier for the product and shipping. Documentation. Collective automatic payments debit the retailer Shopify Payments balance. Documentation. The documented Collective automatic transfer occurs when the supplier marks the order fulfilled. Documentation. Follow those steps as the specific Collective model described by the publisher. For another marketplace app or payment arrangement, request its own documentation for the corresponding money movement and the conditions governing it.
Collective payment records use a separate row for each supplier on a multi-supplier order. Documentation. Use that record separation as a concrete demonstration question: can the operator identify the status and underlying items for each party in the representative order? Keep the customer-facing progress update tied to the relevant fulfilment evidence rather than to a combined payment label alone.
An unsuccessful Collective balance debit leaves the supplier order payment pending. Documentation. Ask how the chosen implementation distinguishes an order awaiting payment from one ready for its next operational step. Identify the support owner and the evidence needed to investigate. Keep any decision to proceed before settlement with the authorised party under the actual agreement.
Hypothetical example: one seller is ready and another has an exception
Imagine a customer order contains items from two sellers. One can prepare its part, while the other has an unresolved payment or eligibility issue. This hypothetical case tests allocation, customer communication and settlement records together.
First record the actual arrangement and the evidence that each participant can use it. For a Zambia-based proposal, evaluate its documented route rather than treating the Collective example as locally available. Then put the order and seller references on the worksheet. Identify the items belonging to each party, the current operational state and the relevant payment evidence. Ask the customer-service owner to explain what can be said confidently from those records and what still needs confirmation.
Then introduce a refund or cancellation request concerning only one part. Have the business owner define the intended decision under the actual terms, and ask the implementer to show the corresponding supported record changes. Keep the unaffected seller’s work and settlement evidence separate in the evaluation.
Retain the observations against the tested configuration and participant model. If a different app or payment route is selected, revisit the relevant boundaries rather than carrying an earlier result forward as though the implementation were unchanged.
What should the selection brief leave explicit?
Identify the proposed seller model, programme eligibility, account access, order allocation and settlement evidence. Request demonstrations for the difficult cross-seller and partial-order cases, with named owners for unresolved decisions. This makes the system choice reviewable on the work the business actually needs.
Keep broader sourcing and fulfilment issues with dropshipping validation. Use Shopify payment eligibility for that separate boundary. Discuss the proposed marketplace brief through online stores and get started with the seller relationships and settlement questions you need to resolve.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.