Create Drupal Commerce stores as a Service

Question

I'd like to leverage the power of Drupal Commerce to sell completely unrelated products and thus would like to create 2 different stores and brands. I could of course create a Drupal multisite but this is overkill and I really want to have only one site and one Drupal Commerce setup. If tomorrow I want to create new stores, I'd be able to do so with this layout without having to go through the headache of managing different installs.

My idea is thus to try and set up Drupal Commerce as a service with the following in mind:

• Each store would be completely isolated from the others (products, clients...)
• Provisioning a new store would only be a matter of assigning a role to a new user
• Say the root domain is mysite.com, I'd like to have one store at mysite.com/store1 and the other at mysite.com/store2 (using subdomain would be pretty much the same)

I've been thinking about using Organic groups but it's not obvious to me if a) it is the right tool and b) how to achieve that with the module.

Any pointer or feedback would be very much appreciated.

Thanks!

Answer 1

This is known as the "marketplace" use case.

There is a 250-comment discussion on this in the Drupal Commerce issue queue: http://drupal.org/node/990204 See http://drupal.org/node/990204#comment-5880498 for a fairly simple implementation plan. Of course, it goes into details that your project might not need, but you can just ignore those.

Quoting the relevant part about the basics needed:

1) An entity that represents the store. That can either be the user, a store entity clicked together through the ECK module, or a store entity provided by a module.

2) Entityreference. Then a bunch of entityreference fields that point to the "store" entity (or user). One on products, one on product displays, one on orders.

3) Form alters that hide the entityreference fields on product displays and products (or just use a "hidden" widget) and fill it in with the known value (you always know which store the user has. If not, give him a dropdown...).

4) A custom submit handler for the add to cart form (replacing the existing submit handler) that adds a product to an appropriate order (since there's an order per store for each customer), and if the order doesn't exist yet, creates it and sets the value of the entityreference field.

5) Custom view for cart/ that shows all active carts to a customer.

6) Custom views filtered by the entityreference field that show the merchant the products and orders for his store.

Organic Groups fits neatly on top. You then need to figure out how you're handling payments, see the linked issue for various approaches.

Answer 2

I have implemented a marketplace feature in my site. I used the below path.

1. 2 type of order type/bundle main_order , vendor_order.
2. On checkout (main_order) a list of vendor_orders gets created for each store through rules and little bit of coding.
3. Each vendor will have permissions for vendor_orders only. so this limits their of useage.
4. on front-end it user doesn't see different stores, just like amazon or ebay