Multi-vendor Marketplaces

So the first thing to do is to implement a way to create a new Channel and Seller.

In the multi-vendor plugin, we have defined a new mutation in the Shop API which allows a new seller to register on our marketplace:

Executing the registerNewSeller mutation does the following:

• Create a new Seller representing the shop "Bob's Parts"
• Create a new Channel and associate it with the new Seller
• Create a Role & Administrator for Bob to access his shop admin account
• Create a ShippingMethod for Bob's shop
• Create a StockLocation for Bob's shop

Bob can now log in to the Dashboard using the provided credentials and begin creating products to sell!

Keeping prices synchronized

In some marketplaces, the same product may be sold by multiple sellers. When this is the case, the product and its variants will be assigned not only to the default channel, but to multiple other channels as well - see the Channels, Currencies & Prices section for a visual explanation of how this works.

This means that there will be multiple ProductVariantPrice entities per variant, one for each channel.

In order to keep prices synchronized across all channels, the example multi-vendor plugin sets the syncPricesAcrossChannels property of the DefaultProductVariantPriceUpdateStrategy to true. Your own multi-vendor implementation may require more sophisticated price synchronization logic, in which case you can implement your own custom ProductVariantPriceUpdateStrategy.

Assigning OrderLines to the correct Seller

In order to correctly split the Order later, we need to assign each added OrderLine to the correct Seller. This is done with the OrderSellerStrategy API, and specifically the setOrderLineSellerChannel() method.

The following logic will run any time the addItemToOrder mutation is executed from our storefront:

The end result is that each OrderLine in the Order will have its sellerChannelId property set to the correct Channel for the Seller.

Shipping

When it comes time to choose a ShippingMethod for the Order, we need to ensure that the customer can only choose from the ShippingMethods which are supported by the Seller. To do this, we need to implement a ShippingEligibilityChecker which will filter the available ShippingMethods based on the sellerChannelId properties of the OrderLines.

Here's how we do it in the example plugin:

In the storefront, when it comes time to assign ShippingMethods to the Order, we need to ensure that every OrderLine is covered by a valid ShippingMethod. We pass the ids of the eligible ShippingMethods to the setOrderShippingMethod mutation:

Now we need a way to assign the correct method to each line in an Order. This is done with the ShippingLineAssignmentStrategy API.

We will again be relying on the sellerChannelId property of the OrderLines to determine which ShippingMethod to assign to each line. Here's how we do it in the example plugin:

Splitting orders & payment

When it comes to payments, there are many different ways that a multi-vendor marketplace might want to handle this. For example, the marketplace may collect all payments and then later disburse the funds to the Sellers. Or the marketplace may allow each Seller to connect their own payment gateway and collect payments directly.

In the example plugin, we have implemented a simplified version of a service like Stripe Connect, whereby each Seller has a connectedAccountId (we auto-generate a random string for the example when registering the Seller). When configuring the plugin we also specify a "platform fee" percentage, which is the percentage of the total Order value which the marketplace will collect as a fee. The remaining amount is then split between the Sellers.

The OrderSellerStrategy API contains two methods which are used to first split the Order from a single order into one Aggregate Order and multiple Seller Orders, and then to calculate the platform fee for each of the Seller Orders:

• OrderSellerStrategy.splitOrder: Splits the OrderLines and ShippingLines of the Order into multiple groups, one for each Seller.
• OrderSellerStrategy.afterSellerOrdersCreated: This method is run on every Seller Order created after the split, and we can use this to assign the platform fees to the Seller Order.

Custom OrderProcess

Finally, we need a custom OrderProcess which will help keep the state of the resulting Aggregate Order and its Seller Orders in sync. For example, we want to make sure that the Aggregate Order cannot be transitioned to the Shipped state unless all of its Seller Orders are also in the Shipped state.

Conversely, we can automatically set the state of the Aggregate Order to Shipped once all of its Seller Orders are in the Shipped state.