The path to Marketplace functionality

Interesting. Marketplace functionality is commonly needed in Ubercart, having the basic support in Drupal Commerce might be a good idea.
If not, this is still a good place to discuss how it can be done in contrib.

Interested to see what Ryan thinks of the added complexity (how bad would it be).

Edit:
This also has GoodRelations implications.
The quick start guide recommends having a main store page, and on it the rdfa attributes for store location, opening&closing hours, etc.
If the store was an entity, we could get that whole part for free (entity url, all information in fields) by just providing the RDF mapping through the hook.
Otherwise, we'd have to implement our own settings form with our own form fields, etc.

Per the quick start guide, there also needs to be a part with info about the company. Since in a marketplace setting we can't guarantee that all stores belong to the same company, it would probably be wise to connect this to the store entity (or maybe have a company entity and a reference field on stores? That way there's no duplication, but I wonder if it's a bit too much to add)

Here's my initial response: we actually didn't have a solution for where / how to store the store information. So in that regard, we haven't really made a decision and can go any direction. I always wanted to use Address Field to collect the store's address and figured I'd have to contrive a way to store the data in the variables table. Establishing a basic store information entity makes all kinds of sense, especially since you can add additional fields as necessary.

Marketplace functionality hasn't been targeted for core (at least for 1.0, and it might be best solved in contrib regardless in the future), so I would say I would leave it up to a contrib module to add a UI for users to add and associate store data with their profiles. This would probably involve some sort of a store reference field that could then itself be added to products, orders, etc. Our access control for these various entities is extensible anyways, so I could really see a Marketplace being developed solely using the additional field and some alter hooks.

At the core level now, then, we'd at least need a store entity that comes with a default address field. I like Bojan's idea of from IRC of having a single default store entity whose edit form we just embed on the general store settings form. Even in a Marketplace scenario, the site itself would still have business information, so this would be useful even if you needed multiple stores.

Of course, after talking with Damien about this, he asks the question - why do we even need a default store entity? : D

Ryan and I agreed on IRC that in most use cases one site == one store. This is enough reason to move this functionality to contrib.
As for having a default entity, my idea at the time was to make it easier for myself to use it for GoodRelations. After today's conference call, I see that it doesn't change anything, I have no use of it.

So in any case, this is 100% contrib.
A store entity, a store reference field, some awesome sauce, and it's good to go.

I think having "stores" are critical for a marketplace application.

Would it be possible to have subdomains assigned to each store similar to Etsy stores so that they can be easily navigated to (marketplace.yourstore.com)?

Would it be possible to have multiple members linked/operating under one "store"?

Thanks

For Marketplace/Multi-Store functionality (in contrib), could it really be as simple as a Store Entity, a Store Reference Field, a few Views and some sauce? What do you foresee in that sauce?

Subscribe.

There is a discussion here (http://drupal.org/node/827558) that discusses the possible use of Organic Groups as a means for creating a store.

sub

subcribing

subcribing

subscribing

subscribing - I'm using uc marketplace in d6 - great that this is being thought through regardless of whether it is in core or contrib

rgs, Don't give up on UberCart just yet, there is still an effort to get enhanced store functionality for UC Marketplace (http://drupal.org/node/827558)

A marketplace with one store is the limit case. I'm not sure that a limit case should be the default, though.

It sounds to me like one store/one site is a matter for the installation profile?

shunting, I am little confused on what you are trying to say. Please clarify.

@17 stomper:

Sorry, I was cryptic (character flaw!). I'm responding to this:

... most use cases one site == one store...

Now, I'm strictly from the peanut gallery, here, but--

If the module is architected for one site, one store, then the multistore/"mall" concept of a marketplace, with many standalone stores, each with their own address and billing arrangements, has to be added on afterwards, with all that being contributed and not core entails.

But if the module is architected for one site, many stores in core, then the "one store" use case just falls out -- set the installation defaults for one store, one site, and the main use case is handled without making the architecture less powerful. (1:1 is a limit case of 1:M.)

It may also be that this is already the plan, and I'm not understanding it.

Again, from the peanut gallery, but I'm not sure that the coding part is harder one way or the other; it may be that the D7 data structures make either approach equally easy.

I'd like to second the motion/notion of keeping the architecture open to multiple stores via store entities and if someone can give me a push (or two) in the right architectural direction I'll attempt to code it up. I'd love to hear maintainers thoughts on making the architecture friendly to multiple stores/sellers/storefronts, even if it needs to wait to a point/2.x release, it would be useful to talk it out here...if only to get some solid ideas for building this in contrib

@jpstrikesback, we are looking for stores for the UberCart Marketplace module, and has been discussed heavily here (http://drupal.org/node/827558). We have discussed the use of Organic Groups as the foundation. Additionally, we'd like to be able to handle user feedback, either per seller or per store.

Perhaps it may be more readily usable to develop for UberCart first as there are more users currently.

@shunting, thanks for clarifying. I think I know what you're getting at. So it is just as easy to develop a 1:1 version as a 1:M version, correct?

@21 Stomper, yes, that's my point. Seems reasonable to me, but I'm not doing the heavy lifting!

@bumathan

I understand your position, I am looking for a D7 option too but am not ready to give up on UberCart yet. Currently, the UC Marketplace module is stuck in D6 version. Is it likely your Drupal Commerce marketplace/store module will be able to backported/ported to UberCart 2.0/3.0?

As for the thread you suggested, I have read and contributed to it too. Thanks for the suggestion though.

@22 bumathon:

Again, here one definite thread of how a multistore site ("mall") could work is that payments need not be routed through a central location. Not everybody has the business model that a site takes a commission on every transaction; there might be a separate business relationship between site owner and store owner entirely.

I think the more that we think of the site as a mall, rather than as a store (even if it turns out that the mall has only one store!) the better off we will be. Concerns get more properly separated. For example, a mall doesn't take a cut on every transaction from a peanut cart; the peanut cart pays might pay the mall rent: a flat fee per month.

+1

subscribe

subscribe

+1 for commerce core being a mall that defaults to a single store
(though being English I want to say shopping centre ;)

I much prefer the idea of designing for the general case rather than trying to expand the one site - one store model.

I have had a quick look at D7 OG. Does Amitaibu's store code integrate with OG? Could a new store be added to a group, simply, in the same way as group level permissions are added to a group entity in D7? Could then look at using Rules to add/enable/disable stores.

+1

+1 for commerce core being a mall that defaults to a single store

The patch needs work (it needs to be rerolled and is currently severely broken).

Raising to major, because I feel this is a very important extensibility point.

I'll give this a shot today.

We can't add this into 1.0, but the good news is nothing will prevent this from working in contrib. Rather than assuming 1 site = 1 store or 1 site = X stores w/ 1 as the default, the Commerce modules don't assume any particular orientation toward "stores". The only global "store" type setting is the default currency for the whole thing. From contrib, though, a "Store", "Vendor", or "What have you" module can provide the entity and reference field to define X stores and relate products, orders, etc. to them.

When thinking about single vs. multi store scenarios, the more important core problem to address is entity access control. Whether we support 1 or X stores in core, we need to ensure product, order, customer profiles, etc. entity access control is pluggable so it can support scenarios where users have access to administer individual items in the store that they don't "own" (via uid) based on reference field data. In contrib we would also need to focus on improving modules like Commerce PayPal such that the payment details can be drawn from the store owner's profile (i.e. use a data selector to choose a PayPal e-mail address), finishing up Commerce Affiliate to track commission for store owners, write additional plugins that prevent / accommodate mixed orders, etc.

It's more a matter of timing than usefulness - I don't think adding an entity and field to core this late in the game would be wise. It's the same reason I postponed including http://drupal.org/project/commerce_shipping. Even if it's not in core, it can still be the de facto "multi-store" module, no?

And yeah, my comment about PayPal was just that multi-store support involves much more than just a core store entity, but everything should still be possible through contrib modules.

hah, I'm afraid you wouldn't want to hear me attempt even some basic Hebrew pronunciation. My study never progressed past a single year of elementary study... I'm sure it would hurt your ears. : P

What you're describing with payment is essentially what's happening through payment method rules. There's an action to enable a payment method where you specify the API credentials / transaction settings, and you can have any number of these. We should additionally be able to update our Rules integration in payment method modules to support Rules data selectors for supplying some of the settings, such as a PayPal e-mail address. So, I think it's functionally equivalent, it just uses a Rules action per payment method instance instead of an entity.

+1

I've created a sandbox for a Commerce Offer module, here: http://drupal.org/sandbox/bojanz/1123256
It provides the store entity (+reference field) and a way to have offers per product.
Could be used as a basis for a real marketplace module.
There will be some more work done in the following weeks, not sure how much and in what direction.

If you are an end-user, stay away. It is absolutely useless for non-developers.

+1

Glad to see this is under discussion. We implemented a solution for this in UberPOS (6.x) a few months ago (since a brick and mortar store frequently has multiple locations), and it was harder than we thought. The problem was that all of Ubercart's reporting assumes a single store, so it was more trouble than it was worth to alter the existing reports. We ended up writing new ones geared toward multiple locations. Hopefully the integration of Views and fields will make this a non-issue for commerce.

So I just wanted to throw it out there that there are several use cases that could benefit from this functionality. bojanz, the sandbox module is looking good so far. Let me know if there is anything I can help out with.

subscribe

subscribing

Subscribe

"Store" entity may be the best solution, but alternatively what about using Domain Access (drupal.org/project/domain) or Aegir (community.aegirproject.org), so that each seller has their own (more or less) Drupal site and Commerce installation? The main 'Marketplace' site could then aggregate content from these subdomain/multi-site sites. Both can be set up to automatically create the sub-sites (e.g. on seller signup) I believe (so not necessarily more admin).

Not sure how scalable Domain Access would be, or how difficult either would be to set up.

+1, subscribing, greetings, Martijn

Here is a patch that allows a market place, but one important exception using one payment method 'gateway' http://drupal.org/node/1162046 might help a few people out here.

Could this provide some integration with Paypal Adaptive Payments API?

So that one can charge a transaction fee for store owners.

More info
https://www.x.com/thread/48515
http://drupal.org/project/adaptive_payments

Sub

I've worked recently on a multistore project using Organic Groups.
A group for each store, a group audience field on the product (to associate it with a store), a balance field on the store that gets decreased by a rule each time one of the products gets bought, a bunch of custom Views...
Almost no custom coding required (other then some hook_entity_property_info_alter() magic to make custom added fields show up in the tokens).

Definitely a viable approach at this moment.

@bojanz

Please detail more about your project using organic groups. I am using organic groups as a pseudo-store entity with ubercart marketplace. The idea is that organic groups will allow multiple users to work together under one store (group), the group itself should be paid and then the revenue shared out amongst members upon an agreed upon rate. Does your project use this functionality, how did you achieve it?

@bojanz
can you tell us a bit more about your OG approach?
does this mean, the store entity concept is off?

It's not off, but there obviously won't be a store entity until Commerce 2.0
Which means we can either build a custom module (which I don't see anyone doing), or see what we can do with existing solutions.
I was pleased to find Organic Groups working perfectly for what I needed to build. Your usecase may vary.

@Stomper
No, we didn't have that. In our case, the store was charged for each product sold. So a price field + rules to modify it. Also used Commentfield to display a log of changes (added X$, substracted Y$).

I haven't tried this out yet, but the OG route sounds great, and the abundance of contrib modules around it make it a very attractive option. I guess the question is what would a store entity give you that OG won't? Is it even worth pursuing a store entity module in contrib or commerce 2.0?

@rbayliss
A store entity could be created for every user and referenced to him.
This would create an ebay-type of marketplace, with EVERY user being able to buy AND sell.

I am new to drupal... I've been using drupal for sometime... I have started work on a website which requires this module and so desperate for a solution... :) this would be awesome if we could get this feature in Drupal Commerce itself.

@bojanz

So you are not using UberCart Marketplace module? Only UberCart and Organic Groups?

I'm using Drupal Commerce (the queue we're in). So no Ubercart, no Ubercart Marketplace.

@bojanz

Very interesting. I'd be very interested in getting a run down on how you were able to achieve marketplace functionality using Drupal Commerce and Organic Groups. Would you mind sharing what you did?

What functionality were you able to achieve, how difficult is it to set up and manage? This may be an option for me should I not be able to find a D7 UC Marketplace module.

See my #55.

@bojanz

Indeed, an interesting and simple approach. And like you set, definitely a viable approach. Are you worried about having to "convert" to DC Marketplace should it happen later down the line?

A question about your application, you say each group is a store, does that mean each group is composed of more than one user? Additionally, does you set up allow payment/receiving payment to be divided up amongst each group member?

#52

jucallme, are you using this in production? I love the OG idea in principle, but each store needs to be able to accept its own payments.

I think there is a UberCart store called Ladybug Markets or something which is a marketplace powered by Organic Groups.

http://www.ubercart.org/forum/live_sites/11781/ladybug_markets

+1

+1

@Stomper hey no we are doing the following.

- using profile 2 with some custom fields to hold each store identity and deets
- customized views of orders and products with some custom rules to allow 'stores' to add products
- either overridden default views or custom ones relationships and arguments are put to heavy use as we now need to relate products to the user who created them and then to their profile 2 entities.... easy if you know views well.
- we are working on custom shipping module something like etsy's as this needs to be split out per 'store'
- we are acting as a clearing house where we pay out 'stores' on a set time table. so a standard payment option works out the box for us.

- we are still a little off launch but everything less the shipping is working right now.

@jucallme

Interesting, are you using anything from UberCart Martetplace module as inspiration for your project ie. in the code?

Subscribing as well....

We are currently using D6 UC2 and MP. With a few minor issues we see occasionally, it is working, and I will most likely keep it this way.

Unless there is something really cool in a D7/UC3/MP? that I just gotta have :D

Still work keeping an eye on this topic.

@ taps

What are your plans for D7? Are you waiting for a UCMP D7 port before upgrading to D7?

Could you elaborate on the "few minor issues" you talk of, please?

Is your site live? I'd like to check it out.

Subscribe

@Stomper

No have not even looked at that as we have specific requirements over and above those explained above, that we can achieve 90% of the marketplace model we have. With through configuration and very little by way of code.

+ there are some really fancy things you can do with views if you add the custom PHP views field module to views, we can now traverse all the objects / arrays with in orders.. like we have running totals and statistics of orders rather amazing!

@jucall

Interesting. Is your site live?

No we still aways off.

It does seem that the entity approach to the many stores one mall idea is the "drupal way" to attack this problem (and not patch existing systems). Has this already been started? If not, starting it might be one good and useful way for me to learn about D7 entities....

Same, does UberCart Martetplace allow individual sellers/stores to use their own PayPal account?

Yes. Each seller inputs their paypal address in their seller settings.
Then, payments are sent to this paypal address once the store pays its sellers with the mass payment function.

I'm actually working on a project (with antiques) using marketplace. I've hired a developer to modify some functionality.
When it's finished, the system will take the payment from the buyer, keep the commission for the shop, send the seller their sale amount minus the commission and send the delivery cost direct to a specialist courier we're partnering with. The idea is to make the experience as seamless as possible for everyone concerned.

Marketplace is a great module, but is likely to need some modifications on a per project basis.
Once the site is live, i'll post a link.

Nick

Nick, do keep us up to date on your marketplace project. I agree, from what I've read about other people's marketplace projects, each had to do some custom work to fit their needs. What are the biggest issues you see with UC marketplace as it comes "factory"?

updated explanation as to why initial assumption might be wrong

#81 @a1tsal are payment methods not rules? simply use a rule to determine which payment option to use... you can simply clone a payment rule and check what in the basket if it has an association to say a field under the person who created that item "aka store owner" then make the payment option rule true and allow the payment method associated with that "store"... you will need to understand rules how to do that but that functionality exists ;)

that example above is assuming the 'store' idea sits with an associated user... easy as we can associate roles to users. You could dream up some other association but it the most logical.. all you need it the two end points who dose this product belong to and what payment rule evaluates to true to allow payment...

this get a little tricky as people will need to make payments to X stores.... but commerce is not the issue here the payment gateway or provider is..... who allows multiple payments to X stores under one payment button.. not sure even if paypal allows this. If they do then go knock on that door the paypal commerce module as commerce dose provide this market place functionality you simply need to understand rules/views and associations.

I have edited the original post please read that.

sub

Subscribing

Escrow support would be nice where the website is the escrow third-party.

Sub and +1!

sub!

+1

subscribe

Subscribe

DrupalCon London is a great time to try and make this happen.

I've scheduled a BoF on wednesday: http://london2011.drupal.org/bofsession/commerce-discussion-approaching-...
Let's go over all of the use cases, see what can be done with existing code, and see what needs to be written.
The goal is to have a ready description and battle plan instead of several dozen scattered comments describing similar and sometimes very different things.
Once an actionable list of items has been created, the implementation will come much sooner.

I really hope so. I need an UberCart Marketplace option for D7 ASAP.

subscribe

bojanz can you put here some feedback about the results of that BoF?

Thanks.

The BoF was supposed to be a short half an hour discussion that actually ended up spanning several hours, mostly do to a very strong team (rszrama, DamZ, Amitaibu, smokinggoat, as well as developers interested in providing marketplaces to clients, whose names I probably mixed up completely :P) discussing all the possible use cases, possibilities and problems.

The end result is that we managed to figure out what needs to be done, and to essentially unblock the effort.
Here are the basic thoughts:

There are basically two very different use cases for Marketplaces:
1) "Amazon Marketplace" - One product catalog, where the exact same product is sold by different stores.
Essentially what we tried to tackle with the commerce_offer module / sandbox.
This is a use case for an improved Stock module, relying on commerce_store module.
So this would require quite a bit of work on Commerce Stock. It is also not the focus of our efforts right now.
DamZ could provide more info here.

2) "Etsy" - each store has its own catalogue, and its own cart, payment, shipping.
You can "add to cart" products from different stores, but they will go into different carts (one per store), and will need to be checkout separately.
Payment goes directly to the store owner, and the mother website charges the store owners a fee (percentage or flat) that is payed monthly.
This is the use case that we want to pursue right now.

We examined allowing products from different stores in the same cart. Not good, because different stores have different taxes, shipping, payment.
A solution here might be to have a way to split the order into multiple ones (one per store) after the checkout is complete, but we didn't entertain that idea for long.

We also examined having the site itself take payment for all stores, and then distributing it to them at the end of the month (with a fee subtracted), which resembles an Affiliating system, but DamZ pointed out that that has legal consequences (because you are essentially tunneling money) as well as making the website liable for everything that the stores do, which is a nightmare, and the main reason why Etsy works the way it does (stores payed directly, charged a fee by the website).

We first examined whether there is anything that needs to be done in Commerce itself to facilitate the development of the Marketplace solution, and found one problem, which Ryan fixed and committed before the conversation was over: http://drupalcode.org/project/commerce.git/commit/84d8020
Yay, Ryan!
The basic outline of the problem is that each store needs to have its own cart. Commerce supports multiple carts, but always fetches the latest one. So there needs to be a way to hook into that logic and determine the correct cart for a page. And Ryan gave us that.

So, here's the plan:
1) Create a commerce_store module. This module creates the store entity (no UI for now), and creates the default store after it is installed.
We need this module for all use cases, and it is something that will eventually make its way into Commerce 2.0.
We already have code in the commerce_offer sandbox, so I just need to take the relevant parts, clean it up, and put it up.

2) Create a commerce_marketplace module.
a) Depends on entityreference, Commerce, Organic Groups.
b) Makes the store entity an organic group. This allows stores to have their own content, and gives us a lot of needed things for free (permissions, context...)
c) Create a store reference field (provided by entityreference) on all Product bundles. Make it required.
d) Add code that hooks into Commerce and determines the correct cart based on the current Organic Group (allowed by the fix that Ryan committed).
e) Figure out how to create a "my cart" page that lists all carts (a view of views?)
f) Create a way to charge the shops at the end of each month. This could be done maybe through Recur.ly (Ryan already wrote a module that does basic integration), or just creating an order at the beginning of the month, and after each shop sale adding a line item with the new fee owed by the store, and having the store pay/buy that at the end of the month.
g) Create a way to have Rules per Group. This allows each store to have its own payment, shipping, etc, configured the way the want. This is probably the trickiest part. There's also a problem of UI, you can't allow a store admin to go into Rules (they would go insane), so a simple UI needs to be made.
Eventually Commerce will have custom UIs for things it does via Rules (shipping, discounts, payments), so those UIs could be embedded into the store administration pages.

Not counting the various misc UI tasks, that's the basic outline. Prone to change when work starts (I'm a bit unsure about the Store VS Group duality, since they are separate entities, we need to figure out who references what).

So now we first create the commerce_store module, and the commerce_marketplace project, then move the tasks I listed to issues there.
DamZ said that he plans to work on this in the near future, and I should have some time as well. It's all only a question of timeframes.
I have no idea when you'll be able to install a module and have something resembling Etsy. It will probably be months (depending on our internal workload, whether there will be other contributors, tricky problems...).

Here is the Commerce Marketplace sandbox: http://drupal.org/sandbox/damz/1232160

What about the usecase of a store selling products with many sellers/distributors, so there is 1 unified cart to purchase them all, with flat rate shipping methods, and then the orders are downloadable by the sellers/distributors so they can fulfill them via their own software? sellers/distributers paid through case-by-case business arrangements. i.e. "Drop Shipping Multiple Vendor Support" for commerce?

Although, your idea for #2 sounds interesting, multiple carts. Perhaps that is the way to go.

You have in my #98 everything that we are ready to work on, and everything that we won't work on, including the reasons why. That includes the single cart solution.
Since your specific use case is relatively simple, you can realize it yourself with not much effort.

Sounds awesome guys. We're kind of working on a project were we have a need for something like this right now. We've coded up parts of what you're talking about. How can we best get together to merge code and discuss future tasks?

@cosmicdreams
Feel free to open an issue in the sandbox that Damien linked (should be promoted soon to commerce_marketplace, once I get a commit in there).
You can also come to #drupal-commerce. Email is an option as well.

I may have a upcoming market place project coming up, but I think I'm going with Ubercart for this one as I don't think the end users will "get" how to create products with Drupal Commerce.

With way, consider this a subscribe.

Makes sense. I consider http://drupal.org/sandbox/rszrama/1181848 an absolute requirement for a good Marketplace solution.

Worked on it on the plane home! Back on it tomorrow. ; )

subscribe

@cosmicdreams @bojanz We'll have to clear it with the client first as to whether or not we can share our code, but we were able to accomplish a decent amount of this with a few custom ctools & rules plugins. Our implementation is tied directly to OG, where each group is a store, and it can have its own products, payment handling, taxes, etc. Each store has its own cart, and we are able to display all open carts for a customer on the /cart page.

The current implementation feels a little bit hacky since it has to work around a lot of the default commerce expectations and assumptions, but it seems to be working pretty well, though I'm sure there are still some bugs to address, primarily with checkout. It also depends on the views_form patch that I posted a while back (http://drupal.org/node/769322#comment-4634312) to include the passed arguments in the form ID, so that multiple instances of the cart form have unique IDs.

I've got a meeting with the client in a few minutes, and I'll bring this topic up to start that discussion at that time. It would be great if there was an easier solution to this. :)

I'd like to say that the many-carts idea now sounds positively cool, especially if they can each have a different payment method.

@willvincent @cosmicdreams
Would be great to try and learn from existing implementations, rather than repeating their mistakes.
I'm perfectly happy to go and fix whatever is needed in Commerce and Views in order to make the implementation clean.

Especially interested in the way you handled payment & taxes per group.

@willvincent @cosmicdreams
Would be great to try and learn from existing implementations, rather than repeating their mistakes.
I'm perfectly happy to go and fix whatever is needed in Commerce and Views in order to make the implementation clean.

Especially interested in the way you handled payment & taxes per group.

@bojanz I started that discussion with our client this morning, he says it probably won't be an issue, but has to get it approved to share the code.

All of our work thus far has been exported as features and a few custom modules, so sharing it shouldn't be too difficult, once we're given the go ahead to do so.

Basically the way it works is that each product has an OG reference field on it, and there's a custom add to cart handler (implemented with a custom product reference field formatter) that checks for existing carts, and if there are any, checks for the GID on products in that cart. If there's no match for the product being added to the cart, a new cart is created, if there is a match, it adds the product to that existing cart.

Payments are handled in a similar fashion, the GID is determined by looking at the products, and the appropriate payment methods are enabled for that cart. The tricky bit there is that on this project groups are able to specify that another group will handle its payment processing. So configuration of payment handling is a multi-step process. You first specify that you're providing your own payment handling, or specify the group that will handle your payments (only groups that have been configured for payment are available for selection, but that list is inclusive of groups that specify another group to handle their payments). If you select that you are going to provide your own payment handling, another menu item becomes available that allows you to configure the enabled payment methods, which then generates rules config for that payment method for that group.

I don't believe we've finished configuring taxes yet, but as those are also rules based they would work the same as the payment config

So will there be a means for multiple sellers to sell under the same "store"?

Also, will there be any consideration into creating a module to help users of UberCart Marketplace module migrate to Drupal Commerce Marketplace?

Also, will there be any consideration into creating a module to help users of UberCart Marketplace module migrate to Drupal Commerce Marketplace?

I'd be happy to commit such a migration into commerce_migrate after someone writes it :)
It's something easy enough to be left to the community.
But let's not get ahead of ourselves here, we still need to create Commerce Marketplace itself first.

Very good point - don't put the carriage in front of the horse. Once commerce_marketplace is ready, only then should be start working on commerce_migrate. But keep in mind we should keep this migration in mind when commerce_marketplace is being built.

I really want to help but can't offer much code.. I am immensely interested in seeing Drupal Commerce succeed. Losing clients to Shopify, Magento , etc. because of limitations of Ubercart...

It appears that DamZ has started a marketplace sandbox(http://drupal.org/sandbox/damz/1232160). I think we should move future discussions to the issue queue there.

I'm marking this as a duplicate of the features issue[#1232250] in that queue.

Well, let's leave this one visible until this information is moved there... doesn't necessarily need to be this issue moved to that queue, but we should at least have roadmap info on that project / in issues somewhere as discussed above. When it's done, mark this fixed so it still shows in the queue so people find the new project.

@slavojzizek I still get a tonne of offers for work on MarketPlace options with Drupal.

The fact is that Magento Marketplace (multiple sellers, single store) requires a enterprise licence, which is $9000. Magento may have other free Marketplace options I'm un-aware of.

Shopify is a hosted system, so is not in the same boat. Those types of solutions serve a different market.

An additional difference between those two solutions is they have money behind them. It's going to be hard for Drupal Commerce or Ubercart to compete with projects which have the resources to hire many full time developers.

There's enough people who want this done in their own hosted solution and are willing to pay for it. $9000 for a Magento enterprise licence isn't that expensive if you consider the amount of resources you'd need to allocate to create something similar with Drupal.

With that said, Drupal can be used to create a very successful and flexible multiple seller store if you're willing to put in the time. I made one back in Drupal 5 + Ubercart Marketplace and it recently received funding. Unfortunately, I'm not sure if any of that money will come back to Drupal eCommerce solutions. I certainly haven't seen any of it :)

---

@willvincent The multiple cart way is probably the best way to abstract the logic for a multiple seller store on the backend, but I think some creative solutions need to get done to abstract this from the end user (at least by default).

Having multiple carts should allow each to have their own payment, taxes and shipping configurations. Although I think this needs to be abstracted from the end user on checkout by default. Otherwise it will be too confusing for them and you'll lose customers.

By default a checkout should probably work like Google's "I'm feeling lucky" and generate appropriate defaults for shipping from each seller and just provide a single input for payment.

If a more advanced (or cheap) customer comes through the checkout, they should be provided with the appropriate "Im feeling lucky" checkout prices, but have the ability to choose different shipping options per seller.

---

As for multiple payments, I'm not sure if this is a good idea or even an appropriate complexity needed to contemplate. Say the main store has both Paypal and Authorize.net . Paypal has "Mass Payment" option which is great for a multi-seller solution. Unfortunately if one were to use Authorize.net, each seller on your site would need to have their own merchant account. As far as the person who's running the store, and creates a much larger barrier of entry for the seller. If they were going to get their own merchant account, most likely they would just be setting up their own eCommerce store. Additionally the person running to store would rarely want the amount the final destination of payment to go to the end seller, as most likely they are skimming a percent off the top, or charging a couple bucks per transaction.

With that said, I think you should focus on a single payment with moving the money around to various account via paypal mass payments or a another processor which supports a similar method. From there you can get more creative with payment options.

---

I'd also fully support a solution for this which uses the features module.

@ #119, there is fear around the company running the site being liable for money/tax stuff they might not want to be liable for...i think instead of being in fear the system should be designed to be secure and have an audit trail so you could do paypal mass pay, etc.

Subscribing

subscribe

Subscribing

Subscribing

Subscribing

subscribing

Subscribing.

f) Create a way to charge the shops at the end of each month. This could be done maybe through Recur.ly (Ryan already wrote a module that does basic integration), or just creating an order at the beginning of the month, and after each shop sale adding a line item with the new fee owed by the store, and having the store pay/buy that at the end of the month.

What if the shop doesn't pay ? How the website owner could be sure to be paid ?

Maybe the shop must have to buy credits to sell products on the main website ? Like this main website will receive money before shoppers will start to sell.

In my case shopers will have to sell few used products maybe only one, so recurring payement is not an option. For example on ebay I don't sell product each month.

-----

Regarding the payement, does the shopper could provide a simple paypal account like on ebay to be payed ?

Good point, I think there should be option that can be configured by the admin specifying whether payment is required BEFORE listing. On a somewhat related point, requiring payment for listing may help weed out dishonest/unprofessional users beforehand.

subscribing

Um, with micro|contrib we could attach an entity to the site or other entities. Looks abandoned in favor of field_collection|contrib. Maybe it can be salvaged as an entity attach API or something.

Er, the UI is different from field_collection|contrib.

Let's work on some marketplace-specific themes too!. A must have I'd say.

I wonder if Commerce is inherently complicated for marketplace functionality. Don't get me wrong, I like Commerce and all, but comparing the product creation to other, common marketplace sites makes it seem like Commerce has more than what user's are used to.

For example, if you want to put a book on Amazon, you register, then find the link to add the book (create a product) and then you go through the images, description, etc. After that, the book is available.

In Commerce, they have to register, find the link to create a product, then when they get through, you have to explain how to create a digital product display, associate their product with that display, etc.

I think j0rd in #104 briefly mentioned this. I didn't read all the comments here so I really don't have any idea if someone else mentioned it as well. I do think a lot of this discussion has leaned towards payments but user experience is a primary factor that needs to be considered as well. If it's too hard for non-technical users to get, i.e. more than one click of a button, it might be wise to start considering that as well.

Also, I haven't explored all the permissions but is linking the product to a display via productref limited to just those products that user has created? If not, this is consideration as well because naturally I'd expect merchants to only be able to link a product they created to a display.

Just my initial thoughts. I have some more but I will write those up later.

@RKS It's not necessary to use Product Display nodes....
I've setup a store where the user adds products (entity, not node) and that's all.
That's the magic of Drupal Commerce... It's views all over the place so if you think a little bit what you can do, you 'll realize that you can achieve your goal without the product display nodes, simply using lots of views.

@aristeides

Have you managed to build a marketplace with Commerce without a formal "marketplace" module? Would you say its possible to put together a marketplace experience using the modules available on Commerce as is?

@aristeides

Makes sense. A lot of times i forget bout adding fields to things in D7. I guess I'm not 100% used to doing that yet. But i guess you could add everything you need and then collect it all in a view. That's probably the way I'd go with multiple merchants.

@Stomper

If you needed immediate marketplace you could probably worked something custom real quick using the Views method aristeides mentioned and the Paypal mass payment API.

For payment options, I was interested in hearing where the direction is going as a framework for plugin options or a specific payment structure. For example, PayPal has the mass payment option with an API for developers. I think the UC marketplace module was using this method and a role for merchants. If you look at that module you might be able to pull the payment portion of the module out and use it. If it's working with Drupal instead of UC itself, I think you might have a chance to get it working with Commerce as well.

There still won't be everything a marketplace has but it's a start and most marketplace sites start out basic and build upon the functionality anyway.

@RKS exactly. I've put all my fields on the product entity and after that it's all views and theming.

@Stomper actually I'm building something like a marketplace BUT each merchant has his own separate site and the "main" site gets their products using services. The main site is built using Aegir and each merchant's site is build using an installation profile (inside aegir) that sets the site up to a point where the only thing left for the merchant to do is add a logo and some products. I know it's a completely different (and a lot more complicated) approach than the "marketplace" discussed here, but I guess each method has its pros and cons.

Sorry if misspoken, but I think there is also somewhere on drupal a view on which comparison products is done..don't know where anymore...
Edit, maybe this tutorial can help: http://jan.tomka.name/blog/product-comparison-drupal
May be views related to this can be shared somewhere on Drupal?
greetings, Martijn

@ariesteides, #137

I like your approach, do share more details. It's almost like an Ebay store? Does you sub-site approach allow each site to have multiple users associated to them (not one sub-site per user)?

I tried to incorporate something similar but instead used organic groups as the base. Unfortunately, I don't think UCMP supports OG groups as store entities.

@Stomper each sub-site is not at all "sub" as it's a completely new Drupal Installation! URL-wise they can be subdomains of the "main" site and/or have their own domain.
As a completely new Drupal installation it can have it's own user-base etc.

I wouldn't say it's like eBay... On eBay there's 1 site where merchants just post their products.
I'd say it's more like Amazon. Each merchant has his own site and Amazon aggregates content from them.

@ariesteides would you be willing to make an instance profile of your solution?
Thanks a lot in advance for considering this!
greetings,
Martijn

I'm still ironing out some of the details and the project will go live on Christmas.
I've already agreed with my client that everything is going to be open-sourced so there won't be any problems on that department but unfortunately I can't share till Christmas... I hope you understand.
When the project goes live I will be able to share the installation profile, a project study and a complete walkthrough.

@aristeides How are you planning to handle the payment gateway? One gateway for the entire marketplace or each merchant can specify their own payment, one of the scenario discussed above on #98 - Etsy model?

@Bojan #98

It's great everyone sat down and discussed the issues and concerns for the functionality of this module. I did want to ask if there was actually any kind of polling or consensus taken of people using other marketplace modules (like UC Marketplace.) I wanted to ask this because it appears you have focused solely on Business to Business (B2B)marketplaces. I say that because you make heavy mention of taxes.

I think this is but only a single use case for the marketplace and such an assumption shouldn't be hardcoded into the module. I.e. different carts etc. A large number of people run Consumer to Consumer (C2C) marketplaces and none of these concern themselves with taxes at all such as Amazon you mentioned.

I'm not trying to criticize at all but I really think hardcoding the module to a specific use case might not be the best idea, especially if no one is even sure that this use case is the most popular and/or most needed.

I know when a store sets up shop on Amazon and they are interested in taxation, they have to work it into their sale price. A multiple cart system would be a catastrophe in an Amazon setting. Imagine going to Amazon, adding 10 books to your cart only to discover you need to checkout 10 different times.

Another thing, you mention the marketplace collecting all the money for stores but then having a legal responsibility for all the member stores. This too is also a specific use case and not even a concern for every country. All of the marketplace sites I know have adequately protected themselves from the member stores. If I order something from Amazon and don't get it, Amazon isn't responsible. If I order something off eBay, and I don't get it, eBay isn't responsible. If you mean the marketplace is responsible for member stores selling illegal goods or services, that will be the case whether or not they are collecting money for the member store or not. Hence, why Craigslist was getting into trouble for prostitution. They weren't collecting money, but they are responsible for policing their own site.

All in all it really looks like you expect most sites to be a collection of actual businesses operating from the central site and I'm not certain this is the best way to approach the site. In a C2C marketplace, you HAVE to collect all the money and subtract fees from the payment or else you will get scammed every single day. Hardcoding the marketplace module to prevent a central site from collecting the money would hurt anyone who wants a C2C site instead of a B2B site where they deal with reputable businesses as opposed to faceless users.

@gkap each store will have its own gateway and will be completely independent.

There won't be any fees for the main site when a client purchases an item and the merchant will pay a subscription to the main site for it's services.
The payment methods will be the same for all stores (paypal and COD) and the shipping costs will also be the same for all stores since we're currently working on a deal with a courier service that will simplify things for store owners. This way merchants won't have to worry about how to send their products to their clients and once an order is made a courier will go to the merchant and pick up the items to be delivered.

Consider the main site a "search engine" for products and merchants.
We haven't dealt with the "global" cart but we'll probably implement it.
The main problems mentioned on #98 for a global cart (different taxes, shipping, payment for each merchant) have been resolved so I don't see why we shouldn't have a global cart.

This of course means that while all stores are completely independent drupal installations and have different databases on the server, some tables of the db will have to be on a different "global" db. Such as the users table and the tables holding the addressfield of the client so that we can achieve a single sign-on for clients.

I guess it lies somewhere between Amazon and Etsy

@RKs #144

Very well put. I did not see things that way until you explained so clearly. You're making a very good point, and I think the development approach you suggest makes a lot of sense. In my usecase, it would be a C2C application - a fusion of eBay/Amazon/Etsy.

I'm not hardcoding anything, just focusing on a specific use case that makes sense to me.
Anyone is free to pitch in and code additional use cases that they would like to see happen.

In any case, since work hasn't even started yet (and might not before December), there's no point in even discussing unwritten code.

I don't understand why there isn't any point to discussing this before December. We're discussing the direction of the module and putting in our own use case. I think the problem might even be lost in translation as no one has even defined what they interpret "marketplace" to actually be. This might be interpreted differently even from different countries. What users in America understand as marketplace might be different than what a user from England might understand what marketplace means.

If we can't define what marketplace we're shooting for, then perhaps a frame module is more important to focus on instead of building the entire thing to work with a single use case. Of course, if this is a bojanz module you're free to do whatever you need to make it work. However, if this is going to be a Commerce Guys module, I think it is important to consider all applications and work towards a frame.

I don't think it's crazy to involve or poll the future users of this module on input. Again, if this is for a client, you have to go with what the client needs and wants but if this is truly for the community then community involvement isn't unnecessary.

I agree with RKS about the importance of defining what people mean by marketplace and that if this going to be contributed module people should get some imput (poll?) into what can help the most people. I understand that technically a marketplace is supposed to be a place where vendors can set up shop and pay a fee to their host or location where they are parking and selling from, but (again I agree with RKS on this) that its honestly best to have all the sales go through the main store and distributed from there, I don't know of any successful legal case that sets a president for such a business model to not be viable. But the feature should be allowed for those that want that feature. My biggest issue so far is allowing users as soon as they enter their product for a product display to go directly to their profile (which is where I want the product to be displayed at). I did make some headway using rules with some help from the commerce forums: http://www.drupalcommerce.org/node/990

I also cant seem to be able to get users to only see their own products instead of all products. Hopefully this is added to the marketplace module as well.

I think you guys misunderstood bojanz; feel free to discuss ideas and / or code alternative solutions. I just don't believe he wants to speculate on what he's coding based on our London plans until he actually starts coding. : P

I've just made a first read through the issue queue, but being an "outsider" on this discussion and obviously others, I'm not quite sure where to put my coding efforts into bringing a marketplace solution to Drupal. I've made sites with Ubercart and Drupal Commerce and even though there is UC Marketplace, Views integration with Drupal Commerce seems to me to be a better solution for building out a general marketplace.

Here's my summary of what I understood / opinion / work situation:
1.) Single Cart. Tweaked Checkout cart: I agree that money processing and a single cart should basically be done centrally. At the time of purchase, the cart/view can then be changed to display purchases by seller and seller's shipping location.
=Situation: Core Commerce Basically Fine, Tweaked Checkout Cart / View for Marketplace situation (low hanging fruit)

2.) Simple Product Creation: I agree that the product creation workflow for end users needs simplification in a marketplace so creating products does not require multiple steps.
=Situation: Tweaks / Option for removing product display to create product display (relatively low hanging fruit)

3.) Single User, Single Store: For now, I think the single user, single store approach is best and easiest. OG might be interesting but likely more complication than most use cases.
=Situation: from the discussion it seems like need to create a commerce_store module that adds 1.) a store reference field for products 2.) a seller role that includes some additional fields for storage, include seller's shipping address, seller's bank account/paypal account and 3.) a store view / context for each seller role. (THE FRUIT!)

Am I missing anything? I've got a client that's going to be investing some serious time to build a 3-party marketplace (sharing it back!) so I can definitely code something for this commerce_store thingie, but I think the easiest is a field on the product entity (agreed?)

@maldo Why not create a view with a contextual filter possibly UID? When a user views the view, they will be returned results unique to their UID.

For the user profile issue why not just embed your view I mentioned? If you set the view not to display if there are no results, all user's that have no products will not display the view.

@Ryan You're right. In all the threads where I've had any contact with Bojan I've never seen any indication he was a dismissive person. I actually wanted to try to handle my comment with a little tact so as not to seemingly invite a lot of "I want this, I want that" or else his job would never get finished.

@mark I agree with your assessment. For one, views has been discussed for a few of the use cases above and I completely believe it is the most accessible and viable solution for a marketplace. So i think you're right on there.

I also agree with the single cart as I've never seen a multiple cart setup and don't really understand how it can work, however, I'm not completely dismissive of the idea since I really don't understand the thinking behind it. Maybe an example of a multiple cart system at work would make me see what is going on there.

For the simple product creation aristeides in #137 stated he's using views and adding fields to his product entities. I think this will be the easiest thing on the list.

Single user and store fields I think is a good idea. I actually think expanding it will be easier for people once everything is built. When you asked what you were missing my first thought was payment to sellers. You mentioned having a field for paypal/bank account but I was wondering what Commerce was going to do with that data. Is that something left up to the admin, i.e. go through and manually pay the sellers or something progmatically? If you sell 10 products, not a problem. If you sell 1000 products, that's a problem.

The payment situation I think is the biggest obstacle at the moment. I can think of using Views, Role Field, Role Apply, and setting permissions to allow multiple sellers. With views, you have all your products displayed, with Role Field you have specific fields for specific roles (i.e. the PayPal account field) and Role Apply where users can apply to be a seller. That handles everything except expendable/time lapsed products, which might easily be handled with Commerce Stock (although I don't think it will delete a product with 0 stock.) Or the payment solution of efficiently paying out to the sellers. You could do it manually, however, like I said, that could be troublesome and time consuming. I think that covers the functionality of a marketplace(?)

[Sorry for such a long winded post]

@RKS: Thanks for your "wind." I think I'll focus on the field / UID-View approach to begin.

I also had a 4.) that I removed for some reason:
4.) Payment back to seller-store / site % percentage / store fee management: I agree that this need to be automated in a way and setup as a separate submodule.

I'm not entirely clear what my client's use case is going to be, but I think the general Drupal Commerce approach with Rules is a good one. With the current setup, we could, for example, implement a Rule to X% for final sales price.

Beyond that, I think the commerce_store / commerce_seller module will need to handle some how seller fees to the site are dealt with.

Keep on spinning it...

I like your rules idea.

If you mean Commerce store and Commerce seller can handle fees like a monthly fee, can that be handled by Recurly? A user buys a "subscription" to the seller role, for example.

You're on your own about automating the payment to sellers. I can think of some pretty complex rules that might trigger a mass payment module.

I have to admit that I have skimmed several areas of this post but I thought I would lay out here in some quick bullet points how we have a marketplace up and running using Drupal Commerce at OpenSesame.com (see case study at http://drupal.org/node/1323922)

1. 1. First let me say we do not address any of the multiple catalog issues yet, there is only one catalog on OpenSesame containing every product which our sellers have chosen to place up for sale.
2. 2. We use the Rules engine to, at creation time for a product create a reference node which is used largly as thr public face of the product throughout it's lifecycle allowing us to use it as a shim for apachesolr indexing (last I checked lacking pure entity indexing), fivestar, comments, multiple viewmodes, meta-tags, and of course the built in add to cart form.
3. 3. We implemented our own arbitrary state workflow for Products which allowed us to offer the originally bought version of a product while only allowing purchase of the latest version of the product. Essentially there are multiple products all sharing a unique Id, in our case a "courseId" but only one of these products has the reference node pointing to it. This has proven very useful to keep much of the metadata associated with the "product line" (conceptually) attached throughout the versions of the "product line".
4. 4. Our payout System (commerce_payout) uses rules to create and calculate payouts for every completed order made through commerce. These payouts are themselves Orders, batched by pay date which contain all of the line items (which contain reference to the original purchased line items) for payment to a given payee (in OpenSesame's case Sellers). Clearly this module is only of limited use until a few payment methods are developed to pay out to the order "owner" rather than accept payments from said owner but it is a start... right now a very rough start.
5. 5. We use basic menu alters to provide the add\edit product form to the end user and naturally a host of other tweeks and hooks to make everything look nice and work great.

Please feel free to give me a yell with any questions, I know not everything here will be helpful to everyone but I thought this might give a bit more grounding to this discussion in that here you have at least one working example.

@ASupinski thanks for sharing this. I'll be interested in working with / studying / contributing to the commerce_payout module. Thanks for sharing this back.

Currently I'm most interested in #2 about product create and this referenced node. Can you explain this some? What's exactly the workflow?

The details of #2 are pretty simple

1. 1.We have a rule that on product creation creates a new reference node for that product.
2. 2. We set apachesolr up to index the reference node type and implement a custom hook_apachesolr_update_index which actually pulls most of the data for the indexing from the commerce product with the exception of the data that must be attached to the node due to other module restrictions.
3. 3. The view of the product is always in fact a view of the reference node allowing us to have comments, fivestar, pagetitle, metatags_quick and pretty much every other module we need to use that wants to reference a node rather than an entity in a very vanilla way.

Hope that answers your question @markwk.

@ASupinski

You know, I've thought about how to get Rules to perform a lot of the workload and I'm sure most everyone has. However, I have never once thought of making the payouts an actual order and that is an ingenious idea. I think that is something to look into. Thanks for sharing.

A couple of thoughts I had:

1) I have changed my opinion on adding fields to the product entity and using views to display just the product entities. Why: ASupinski has demonstrated that it is possible to use rules instead to auto create product displays so we really don't need to think about it any other way. I think this is more in line with Drupal Commerce's vision and reasoning to separate the display and the entity. Secondly, for marketplaces where products are limited stock, time lapse, or any other reason for having to disable the product, it makes sense to me to delete the product display node, and maintain the product safely. So by using views, you display all the product displays and when an item is no longer available for whatever reason, you can disable it by deleting the display instead of having to delete the actual product. Of course, someone else can decide that deleting all products instead is a good thing as they don't have a reason to maintain the product after it has sold. (More reasoning in #2 below.)

2) I also started thinking about multiple sellers, one product. Best example is probably a book. If we stop at just allowing users to create products, we can't easily associate one product to all users. Instead, we will have multiple products that are all the same thing. When a customer searchs for a book, they get twn listings of the same book. So if I'm selling Drupal Commerce 101 and someone else is selling the same book, it will actually be two products instead of just one listing, two sellers. This is another benefit for being able to maintain the product. If we maintain the product, a future seller can start selling that product and just get added to the list with their price etc. Of course, for something to work like this, there would also need to be a way for the marketplace to recognize a seller is creating a product that already exists so matching on product title, or serial, or some piece of information would be needed. Books are an easy way because of ISBN but not every industry has that luxury so there needs to be multiple checks and balances. It would be easy to pass a match simply on title as Someone can create a product titled Kodak Camera, and someone else creates a product titled Kodak PX1012M and they are actually the same product. A possible solution is to set it up that all fields are matched to existing products, so that site owners can add their own specific fields to products that will be required for product creation and these fields will be matched during creation and if they exist, the product is not created, but the seller is added to the existing product instead.

Make sense?

So discussing this with Prince Manfred he enlightened me that previous sold products won't delete anyway since they are referenced already. Mostly I'm working on theory and I haven't tried deleting anything so sorry for even mentioning that in the first place.

But I did think unpublishing the display node would make since instead of deleting and I actually found this discussion about unpublishing a node based on user role and I think it might be something tweakable to fit any need here. The discussion: http://groups.drupal.org/node/94379#comment-631158

Everything else so far still seems sound, no?

Very interesting point, RKS, especially your second point. I think what you're suggesting is very similar to Amazon. eBay/Half is almost like that but typically only dealing with books. When it comes to selling other items, it is very common to see duplicate of identical items that happened to be titled/described differently.

Is it possible to design a marketplace module that can support these various approaches we're discussing or are we shooting for a one-size-fits-all approach?

There are a few electronics stores I see with multiple sellers, one product. I just think the trick is to force enough information from the sellers to determine a match between existing products and new products. Just leaving it up to title would mean a lot of false positives or a lot of missed same products because people just don't title things the same. So if you know you're going to have an electronics marketplace, then you can force a model, manufacturer, name etc. If you have a bookstore, you can force ISBN.Now you have multiple fields to match. If you have an open site where sellers can sell anything from books, electronics, clothes, etc you could make several product types and force a seller to select a category prior to creating a product. Based on the category, the create form for their exact type of content is given to them.

After all that, getting it to match is another story. Prince Manfred has suggested the Relation module so I'm looking at it right now. We have also been discussing the best way to generate the product display nodes based on new content and relating future products to that same display instead of creating a new displays for all. Now you get one display, multiple sellers. More to follow once we are able to finalize our direction.

For time lapse products (like eBay, I guess, where you list a product for 15 or 30 days whatever) there is a node expiration product working http://drupal.org/node/1343740. Problem is it is for D6 (and not even ready for D6) but on the issue queue the maintainer has stated interest in porting to D7.

@#163, the expiry-node seems very intriguing, like eBay. I'm assuming you can assign different fees for different expiration periods?

@ASupinski: thanks for the painting the steps.

Maybe this is a stupid question from a guy just starting to dig into the new Drupal 7 land of "all things entity": Should the user reference to the product be in the entity or in the node/product display?

I'm specifically wondering where the seller should be pinned.

Err... I think I'm definitely overthinking this one... :)

@markwk, The seller reference should be in the product itself, not the display.

@markwk in my case I don't know that is makes too much of a difference, I ended up having the seller own both the product and the reference node only because I largely treated the two as one unit.

I think it depends on the use case. One product, one seller, one display then everything can be referenced as the same seller. If there are multiple sellers, one product, and the display is an aggregate of all the sellers' products, then the product only will have the reference.

Regardless, we aren't selling the display so I can't imagine any negative consequences to not having the display reference the seller.

@ASupinski: I'm still a bit confused how this works work for a user's perspective. I assume they are only editing either the product or the display, not both, so how do you set to edit just one?

@markwk, The display node isn't a critical component. Since views can access the field formatter, you can alternatively display the "add to cart form" as desired. Anywho, the user (in my experience) only really should be editing the product. Rules can serve as an excellent tool for handling the display node, if and where you need it. Hope this helps.

@markwk, @wjaspers pretty much hit the nail on the head, I don't give the end user even the rights to edit the node and just allow them to edit the product (and present appropriate links to facilitate that editing). Then I use rules to keep the few pieces of metadata (title, description, etc) synced between the two for the use of other modules.

@wjaspers + @ASupinski: Thanks a lot. Attacking the marketplace setup in a day or two.

@markwk, The last few months I've been on a project dealing with something similar to marketplace functionality. To be totally honest, I don't clearly see a way/solid reasoning for building a pre-constructed "marketplace" version. Each market approach will require tuning to meet its specific needs. There are certainly parts of the commerce core that can be expanded on, and feature sets that make sense for each use case -- but IME everyone wants something just a little different from the last [version].

@wjaspers: I agree that lots of projects will require customization, like everything else in Drupal. But I'm not quite sure what's so specific about the over-arching marketplace use case: a multi-seller framework?

Anyways, first full day on this, besides talk, planning, testing and fart thoughts previously. I'm currently using Profile2 to setup the user with a store profile, then using a user reference on products.

Plenty of tweaks will be needed, of course, but leaning on the user is a seller/store approach.

@markwk: Have you tried OG as a store? There were examples up in this thread.
I am in need of marketplace but currently there are at least a couple of approaches: user/store, og/store. Don't want to get stuck if development of marketplace functionality takes a different - from mine - approach.

@mefisto75: No plans to pursue the OG approach. I see this more as an edge case.

Just a thought, but what about combining commerce with OG? In D7 a group can be anything from a "store" to a "product" entity.

Edit: ... I guess I missed the comments above about OG.

I also think OG would be an exception rather than a rule. After all, I don't really see too many marketplace sites where multiple users are using the same store unless there's a store login and everyone who needs it has it. Again, just my experience and this could be the norm for some marketplace sites.

As expected, early fun, fun, lead to later headaches. Wondering what previous marketplace folks did about the orders to multiple sellers situation? Imagine X buyer buys 3 products from 3 sellers, how are orders handled?

I'm currently going with an initial order like normal, then a rule on checkout that spans several additional orders to each seller. Running into cross referencing problems between orders because DISCOVERY #1: Only 1 Order Entity Type in Drupal Commerce. Seems like I'll need to create some kind of additional order. That's assuming I'm not crazy on the wrong road here...

Looking for helpful thinking...

@markwk, you can specify more than one order BUNDLE, but not more than one order ENTITY.
Currently, this needs to be in-code to work.

My thought on this is focused on reporting and invoicing. If said buyer made a purchase of 3 products from 3 different sellers, how is this information relayed to sellers? For example, each seller maintains their own fulfillment so when the order is created, are they relayed the order including everything? Then they locate their product and quantity off the list and then follow through with the fulfillment? This might not be too great a problem but in the off chance a buyer purchases 1,000 products from 1,000 sellers now each seller has to go through the list and find their product. In a situation we've discussed here before, what if each product is the same but multiple sellers? now each seller can't determine the quantity ordered just from them and the quantities the other sellers have to fulfill.

So here are the two situations, a store order is created that is then split into different invoices for each seller.

That was my thought was that it needs to be split up for invoicing and order tracking. Basically the buyer needs a single payment order/invoice. But you really need a separate order/invoice for each seller. That way they can individually control that store order's status.

My scenario may get more complicated by the fact that there will also be multiple distributors involved too.

I'm working on creating a new order type (in code, since no order UI yet!) and linking it via entityreference or relation module somehow. Still not feeling confident in the approach yet...

@markwk how about order having several fields representing sellers (or purchases that relate to sellers) so buyer when checking out confirms (it can be made a required step) his purchases by clicking on each field/seller thus triggering separate invoice flow?
Sorry if incomprehensible yet another sleepless night with beloved Drupal)
Upd: Shouldn't be this thread separated somehow? Going to need a full pager at the end.

#159 RKS,
regarding your second point (one product, multiple sellers) - it is good idea from user point of view but it means that the stock should be managed on product->seller level and not on product level as it done by Commerce stock module.

Possible structure scenario (I 'm a bit in a hurry right now so I hope this will make sense the way I write it):

Product entities are site-wide, product displays are seller-related.
Sellers create product displays that have taxonomy fields like brand, model, serial etc.
The same fields exist on the product entity, plus a few extra like photo, description etc.
If the taxonomy fields are identical on a product entity already present on the system, it will be shown to the seller so that he can choose "yes, that's the product I want to sell" and product photos - product description will automatically be presented to him, making the process easier.
If the taxonomy fields do not correspond to an existing product entity, it is created (via rules) and the seller fills in the photo-description.
This way we can have the same product sold by many sellers.
The stock I guess with a little bit of tweaking we can make it related to the product display instead of the product entity, so each seller can have different stock.

@mefisto75 I think you are right about leaving a single order setup (since to be honest, only one person is actually paying :-) then triggering separate invoices for the different parties... not sure about the invoice module's flexibility but can build from those rules and views.

I think I'm confused on your planned solution. To me, each product already is related to the seller because it is content with a creator. So each relationship is made by UID right? Accessing the "author" isn't out of the box for order or invoice fields but rendering a field with this information shouldn't be too hard in theory, correct? Spliting the invoices off one order still isn't corrected but that might be doable with rules and at least you already have a reference to use between products and sellers.

@aristeides
This is similar to what I'm doing, I'm trying to make an multi-seller store, where users are able to sell fixed price products and create auctions. At first I wanted to do exactly what you said above, but It's not possible as the images and prices of the same products provided by different sellers might be different (specially on used products and auctions where it's necessary to update products price and each product needs its own image).
It think creating a new copy of the identified (similar) product and then letting the user to set the price and picture of the newly created product would be a better approach!

@RKS#182, I think it's possible to create a table of a user's products from orders using views... (although this is just a short-term trick to make it work! IMHO a proper way of separating and orders into per-seller orders is needed) this approach could work (not tested):
clone orders view,
set it's path to user/%/orders
add relations "Commerce Order: Line items" and "(Line Item) Commerce Line item: Product",
add contextual filter "(Product) Commerce Product: Owner"
remove unused fields and add fields like "Commerce Line Item: Quantity" , "Commerce Line item: Product", "Commerce Product: Price", "Commerce Line item: Total", etc.

in my implementation, each seller has it's own copy of product even if the same product has been added before by another seller. so the "Product: Owner" filter will give you the products created by the user whose uid is in the url.

PS. Sorry if the things are said are irrelevant/not applicable! This is my first project in this field!

Admittedly it is not what I was intending it for but you might use the payouts system I referenced earlier to produce the seller specific orders. I had intended to use them only as billing invoices for the sellers but really with the addition of some more order statuses they could be used for tracking of the sellers involvement in the order.

One of the aspects of a marketplace is product moderation. For example, you don't want people posting "certain services" into your marketplace. Any ideas how a "product moderation" workflow like this might be added?

Workbench is nice but "out of the box" it only can handle the moderation of product displays since it's a content type. I suppose this could be done via an options field ...

Thoughts?

Without looking, can you use a rule with publishing content? When content is saved, publish in 24 hours? Then you can look at all the unpublished content every day? I'm assuming you want to manually check and that might work but I'm not sure there is a rule that can do that out of the box.

I can't think of another way really to make sure you're seeing all products first.

Any ideas how a "product moderation" workflow like this might be added?

http://drupal.org/project/workflow seems like the best solution although you've got several options:
a) Sellers only create unpublished content
b) http://drupal.org/project/content_access -- limit access per node until approved
c) http://drupal.org/project/flag -- Let your community do the policing for ya

@#192

I suppose if you organize the listings by content types it will help control what exactly is allowed, but then again users can still post questionable things. Is there a means to blacklist certain terms that are checked on "submit"?

Another means would be to have a "flag item" as well as a "watch this item" option so that user's can flag questionable listings. I'm surprised there is not "watch this item" or "add to favorites" option. I'm guessing you can just create a custom flag or use the default bookmark functionality, but that depends on how the data is handled - a node or something else.

There's also the Scheduler module http://drupal.org/project/scheduler
that let's you set dates to publish content. So you can select 24 hours for all content and basically do what I was saying above.

Thanks for the tips! I'm a big fan of using the flag module in general, but when it comes to products there is a bit of an issue since flag can only be used on nodes and not entities. I ran into some issues trying out the flag entity module that's in dev.

I think the most likely scenario is with workflow and rules and some sort of content access controls. Workbench has a lot of cool ideas but doesn't quite fit in this scenario.

Anyone succeded in having marketplace functionality?
Just found this excellent contrib http://drupal.org/project/commerce_file but it's no use for me until there is a marketplace. Want to make a photobank with different sellers.
It is an only blocker for me to switch to Commerce. Marketplace.

@mefisto75：If you read carefully the discussion, several folks have gotten a marketplace working with Drupal Commerce (myself included). Unfortunately, there is no magic "commerce_marketplace" module yet to make it happen. But I can assure you that the system itself is flexible enough to create a multi-seller marketplace, using views and rules and some custom permissions and perhaps a custom order setup.

I found ASupinski's payout code (http://drupal.org/sandbox/ASupinski/1342892) quite helpful in conceptualizing a workflow back to individual sellers, instead of simply to the site alone.

Unfortunately, my situation on a client's project is not particularly helpful because 1.) he won't "open source anything until after launch" and 2.) our marketplace is not at all standard (it's a three party setup, including middle distributors).

Good luck!

@markwk, thank you. I needed some confidence before diving in) Drupal "is like a box of chocolates"
Will report back

@ #199,

It'd be nice if those were able to create a marketplace using Drupal Commerce sans a "marketplace module" could share, step-by-step their process perhaps in a book (here, not in paper). Who ever is willing to contribute their approach is more than welcome to explain it in terms of their own application and not in a one-shoe-fits-all approach so that more people can get a better idea of the available approaches.

I'm starting to think there is no one-off set of addons that would simply facilitate a "Marketplace" approach. Instead, two separate flavors of Drupal Commerce might be more appropriate. So, in reply to @stomper and #199, if "Marketplace" were simply an addon on top of commerce, we'd have significant amounts of duplicated code (doesn't follow DRY), code that simply takes over other code (in which case both get loaded (adding to module weight), and structural complications -- ie. instances where entities in Commerce need to relate to a "store", but some are locked.

I think if people would be willing to release case studies, code, views exports, pictures, etc. of how they achieved their own marketplace then we'd be able to understand the forms essence, and build our own. The barrier to doing this right now is fairly high. Please, Marketplace Drupal Sages, bless us with your wisdom :)

@slavojzizek: the barrier for building a marketplace IS high. Drupal 7 Commerce can be used to build a marketplace but it isn't really for non-developers to make this happen.

When I started on this client's project, I was surprised while researching that there really isn't much open source e-commerce marketplace code out there. Research it yourself and see. There is a different kind of situation about sharing code for a single shop, which has a collective interest/incentive for coding and support, and about protecting code for a marketplace, which is a technical entity requiring expertise to build (we are at over 200 billable hours so far) (and would take an even bigger time investment if you wanted to support it).

Markwk; I completely understand what it feels like to have developed something for a shop with many hours involved in figuring something out. My request was not meant to be a whiny -give us the code! kind of post.

Perhaps if you finished the project, proved that it worked, then released an install profile / code/method we could all install it and try it out. I'm sure people would be willing to pay for support (I would).

I really appreciate the Barracuda Octopus Aegir project in this regard. They release a badass hosting system full of best practices and leading edge tools, for free on Github. But, there's omega8.cc hosting where you can pay to have it. One time my server crashed, and omega8.cc offered to fix it for free, just to learn more about how to make the code work well. See, there's something to that! I wish we could have something like that for marketplace.

I feel like a lot of the sites I built with UC are outdated now, compared to the standard issue shops you can rent online. It would be nice to not have to re-invent the wheel everytime. Anyhow, these are just my thoughts alone. Anything that is shared - great. Anything that's not - I understand!

In reply to #204:
I believe some reasons that little open source code exists for marketplace functionality includes the fact that many approaches require EDI (electronic data interchage) between the seller, the supplier, and the Market host/manager. Few open solutions actually provide any of it, or for that matter, handle it well. Any efforts created to suit this business need for a strong marketplace approach requires signficant development and planning around the services to be implemented and with whom data will be exchanged.

Other thoughts?

@slavojzizek: sorry if I came off wrong (sweet philosopher reference with your username by the way :) but I think beyond a basic shop (which Drupal Commerce does well), Commerce has avoided as much as possible hardcoded situation. So basically it is possible to override lots of steps in the process via view or rules or other configuration. I think the one exception is product creation and order and payment management, which are a bit biased towards 1 site = 1 shop.

omega8cc has a slight advantage with what they do since it also involves infrastructure as opposed to just software. I agree with what you said about what they are doing as something really great. I do my production hosting them because I don't have worry about much once a site is up.

I think there is an interesting business opportunity for a shop to invest in putting out a marketplace solution with Drupal 7. Magento's approach is noteworthy though too, since they offer a marketplace option but with a hefty paid license (which shows both how valuable a marketplace is in terms of a well-coded solution and how much work it takes to get there and maintain and suppor it).

Moneyscript Membership code is an interesting approach too, since it solves several problems well, that even I have used it on a project or two instead or rolling my own solution.

any updates?

How would I go about this model as of today;

1 store, selling products from main organization and many third parties all around the same theme. So, 1 store front.

User adds products to cart, from the main org and some of the third parties. Third parties don't sign up their stores, we don't offer "make your own store, add your own product" functionality, we do it for them.

User checks out, pays us directly. We sync our orders to Quickbooks, do old-school accounting to pay people.

BIG unknown - how do we send the orders that aren't fulfilled by us to third parties to ship? We want to do this instantaneously-

Thanks!

@slavojzizek
In a nutshell: I would setup a custom entity that represents your third party vendors, ensure your products reference the vendor, attach some rules integration to it, and let rules split the orders that come in (looping over the line items) to break them down by vendor. Then just trip an event that syncs the vendor to quickbooks and sends them an email with the appropriate details.

Alternatively, you could use something like Taxonomy to represent the vendor for a product, in which case you won't need a custom entity. But, if you wanted to do additional processing or store additional metadata about the vendor you need to use, it might get trickier.

Thanks for your very awesome response. I wonder if this: http://drupal.org/project/eck would help one with the ambition of creating such an entity. I already know about Taxonomy - that might be simpler for me.

Also, the issue is I potentially need a flexible system for sending order details (i.e. sending an email / pdf is not going to cut it). I was thinking that I could use some Views export-esque module to provide exports per-vendor, so they could download the orders in bulk and do whatever they want. Maybe an email would be nice as well, to tell them to get the new orders. I was wondering what the norm is in this field - do I, as the marketplace creator, try to integrate with every other system to send them orders the way they want to receive them, or do I just do something simple - such as, email the order contents, and provide some kind of general export, and say "make it work with your own system!". Anyones experience on this topic would be greatly appreciated.

Well, the Services module will give you some flexibility, but would likely require a significant amount of work to code up something that will serve your EDI needs (I'm just assuming). You could provide a (common) service URL and API key (specific to each) to each vendor that can access something like...say, a View which exports data (maybe using views_data_export). Lots of possibilities out there.

I actually tried to task myself with helping get ECK 2.x with Features, but have been lagging recently due to a high workload.

suscribe

subbie

+1

Find this : OpenSesame eLearning Marketplace
http://drupal.org/node/1323922

Follow

Is Commerce Marketplace coming? :) http://denver2012.drupal.org/program/sessions/creating-marketplaces-drup...

That session wasn't accepted, so my focus turned to other more critical things (addressbook rewrite, inline product form, etc.).
A CommerceGuys effort might happen this year, but certainly not anytime soon.

Is it possible for you to share session notes?
I am keen to develop a website with marketplace functionality. A similar module for magento already exists (Unirgy>udropship).
But I am looking to have the same thing on my website built on drupal commerce.

better explanation

I took a first cut at producing an issue summary. Needs reviewing and updating.

It would be a great shame for this project to stall following so much enthusiasm.

What are the main pinch points - summarized?

@Paul - that's what nedjo just resummarized at the top of the issue, no need to restate them in comments.

An initial run through the issue to try to produce a summary. Needs review and updating.

Ah. Thank you Ryan

So a Store Entity approach eventually.
From my experience of building a 'user is a store' marketplace on Commerce, other things for consideration will be:

• New permissions layer for shop owners - see http://drupal.org/node/1434610. Same thing goes for line items. Both (orders and line items) have to be assigned to store enitites somehow (not only the products) and permissions would have to be based on this assignment.
  I now use a reference field on an order and fill it with UID of the shop on checkout. Access to orders and line items is then based on this "ownership" of the order. Similarly order could be assigned to the store group at checkout.
• Some form of UI to allow admins to set product owners like you can do for nodes. We could actually use the ''#autocomplete_path' => 'user/autocomplete', from the node module. In many scenarios it is the admin that will add products for a user (store) and he has to be able to set him as the owner. Currently ownership is assigned from global $user and cannot be overwritten.
• Views integration for a 2 step reference. To make a view of display nodes from one store, we'd have to move up 2 references. display->product->store. Can you do that in views out of th box?

This is of the top of my head. I am really excited about the marketplace functionality. Once a more granular decisions are made, I can help with coding.

@nedjo: i really appreciate that wonderful writeup!

mostly agree 100%
a small point to add:
> There's also a problem of UI, you can't allow a store admin to go into Rules (they would go insane), so a simple UI needs to be made.

here we should use rules access rights or extend them accordingly.
don't know how much of this is covered by #1217128: limiting Rules components to specific permissions.

@MagicMcj The idea of a store entity has come up several times, and not just in this thread. I've added it to the discussion / resolution points for the 2.x issue here: #1467180: Open 2.x Drupal Commerce branch

@rszarma
I absolutely favour the store entity approach. It allows more felxibility (like the obvious multiple users managing one store).

I was just watching this thread for a long time and people seemed to move towards 1 store = 1 user approach (all implementations I know about went this way). It is easier to do and that is also why I did it this way. Store enitites are way more difficult.

Anyway, I am happy to see that this is moving and will try to help if I can.

Hi people, I don't know if it's possible, but i was thinking about the possibilities of making some subdomains (one for each seller) and use the Domain Access Module to create a sort of Home Page that connect everything. I've never tried something like this and i didn't know much about it... Does somebody know if it's possible to do that and what are the limit of this architecture?

This is not really related to the MP issues; please check this issue in Domain Access.

Sorry, I thought that the purpose here was to find a way to have a multiseller site.

@#299

I see what you're saying, similar to Etsy. I think it would a be a powerful feature for a marketplace application.

I'm using domain access and commerce and it can be done (even with multilingual sites). U can even set subdomain for every customer if you want to. With views you can simply display all product you need from all sellers you want to, and still have great commerce and domain access configuration possibilities. However performance can be a pain in the ass here but common nobody said that marketplace will be target small sites with shared hosting environment (however it would be nice to run it on smaller sites too).

@#233
That sounds good! What are the problem for the performance? I was wandering if it's possible that a buyer have one single shopping cart (in the main site) for all the shops (subdomain)...could you do that in your site?
Thanks!

subscribe

@LucaDeLuchis it can be done but the payment goes to you and then it is divided for all sellers. In my example every seller has it's own view so it's a little load for the server.

I was reading this improtent post as one that very interesting in a marketplace develope.
I created another issue relate to the add product flow which is I think need to be part of this develop.
Right now, the way of adding product might be nice to developer/editor, surly not to end user.
http://drupal.org/node/1506202

subscribe

Okay, since people have been emailing me and pinging me on Twitter, here's my update / summary on what happened since London.

The main problem of course is that Marketplace is not a single module with a few pages that solves the problem, it needs several supporting modules, as well as glue code. Since my session got rejected pretty early on, I moved on to other things, but those things included the supporting modules.

The main module that I worked on since then is the Inline Entity Form, and it's in a usable state right now.
This is an absolute requirement for marketplaces because it solves the product -> product display separation problem and allows you to just point shop admins to the node add / edit page where they manage all product variations.

What happened independently, but is important:
1) Organic Groups 7.x-2.x -> Removes the duplication between group id and the id of the entity that is the group (so if a node is a group, you no longer have both a nid and a group_id, you just have a nid). This really matters, because it makes implementation much simpler, without having the confusion of "Which entity do I reference through this field?".
2) Shipping 2.x -> much easier to use in a Marketplace context. Has a UI for rates, instead of embedding that into Rules, which was a big problem we mentioned in London.

So, what do you need for a marketplace?
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.

This is commerce_marketplace, the fairly simple glue code that anyone can write (Please do!).
In addition to that, you can easily add Organic Groups into the mix, and make the user/ store entity into a group, so that it can contain content and have the powerful permissions that Og provides, etc.

The tricky part is in the payment. Ubercart Marketplace use to have the model where the site takes all money from customers, then sends the money to the merchants. This was wildly disliked. You can implement that pretty easily through custom code (you just need to calculate how much you owe the merchant at the end of each purchase, then use something like Mass Pay to pay them. People usually use VBO to get a nice screen that produces an export file for Mass Pay).
The Commerce Payout sandbox implements that model, but I don't know how mature it is.

A right way to do payments would be to implement the three-way transactions that some payment gateways support (where the Site takes money from Customer A and sends it to Merchant B). No current Commerce payment getaway module supports this, so pick the one you want, patch it, and contribute back.
There's then the question of how the site gets payed. Either the getaway allows you to take a percentage in the transaction (not sure if possible), or you calculate your percentage after purchase, and then have recurring billing for each merchant. For that you need Commerce Card on File (which lets you charge the user without him entering the credit card information each time), and you need a bit of code on top that handles the actual recurring part. We are working internally on such a module, and it might be shared on drupal.org soon.

So, someone needs to write code for the commerce payment modules (PayPal, perhaps Authorize.net? Not sure who exactly supports what I described).
And then someone needs to write the glue code.

This conversation has been going on for ages, and people have built and launched marketplaces, but nobody has shared code yet.
Let's change that :)

Update summary with model of using Profile2 as a store, plus other links.

Based on past experiences with different modules that (indirectly) want to process payments, I'd like to share these thoughts:

1) We're reinventing the wheel or causing other projects to do the same. Ideally, we'll end up with a general payment API that can be reused by all sorts of other modules that require money to change hands. The only two I know of (both under development) are http://drupal.org/project/payment and http://drupal.org/project/pay. As the maintainer of the first one I of course want Commerce 2 to depend on it, but objectively speaking Commerce can use either one (or write a whole new general payment API).

2) Commerce shouldn't care about how payment methods deal with payments. There should be enough abstraction for a payment to be executed by any available payment method. This means that whether a site owner wants all money to pass his account before transferring it to his merchants, or that all money is transferred from client to merchant directly, this should not be hardcoded, but a piece of configuration. If money goes to the site owner's account first, before moving on to the merchant, this means there are two transactions rather than one. It's the client's money the site needs to care about in the first place. Not how it ends up with n payees (yes, what if there are more than two people who need to receive the money...?)

My motivation for these thoughts is that in the past we've developed too many custom payment systems, of which the payment methods are not (always) instantiable or exchangeable with other payment systems, or that were so restrictive that some payment methods could not even be written for those systems

sub

@bojanz: your comments (http://drupal.org/node/990204#comment-5880498) are great and gave me a lot to think about in relation to the marketplace I've been building. I think your points apply to most general marketplace setups. But after much work and time, I tend to agree with some of the earliest comments that it is hard to generalize the needs of a marketplace setup.

Some comments:

• About #2 entity references, I have avoided this issue by using simply user reference.
• About "Inline Entity Form," I tested it and it works but since marketplace setups like mine might have a unique product creation management including product review, the rules approach seems to work best. Though obviously your contrib is much appreciated
• About #4 submit handler / separate carts, I think this seems like a good idea for general marketplace, though I'm not 100% sure. I ended up doing this differently by essentially keeping the current cart and initial order and then splitting the order into separate seller orders later. There were business specific reasons why this made sense. This might be an alternative approach in some marketplaces like mine where shipping is a compliated issue OR in digital marketplaces where there is no shipping issue at all. Once my client okays it, I hope to share some of this code back, at least as a starter for other people thinking about processing orders.

One other additional feature I think missing from you list is a more robust user's "Orders" page, I'd call it something like "Transactions History." Basically in a marketplace orders take on different meaning and exist more as "transaction" orders than as simply me or a buyer making an order. Semantics aside, the point is that we need a more robust orders page for individual users/stores/sellers/etc in order to show how you can have buyer orders, seller order, payment orders and even refund orders. The accounting needs to be done in a way that you get clean booking for all of the steps. Beyond this basic view listing, we need some additional week by week calculations showing balance, debit, credits, etc. Unless you have a single order, I see the payments processing as depending on the weekly calculation of debits to pay as the step to giving payment orders the correct amount to pay back.

Anyways, that's my 2 cents...

Hi, I get how to allow my users to create there own products and display them in an individual store like way.

But how do I get my site to pay the users once theyve sold a product, I can set up paypal to send money to a merchant, but how does my site/paypal know how much each user should be paid?

I really think we should not worry about that, because only a very limited number of payment methods are able to do that and if we tailor Drupal/Marketplace to that behavior, we will lock out all other payment methods. If we stick to the principle that a payment transfers one sum of money from one payer to one payee, we'll allow as many payment methods as there are out there. If a Paypal module wants to support multiple payees, then it's up to that module.

A lot of websites that do have multiple payees per payment actually don't deal with this behavior themselves, but the money is instead transferred to the second payee somewhere behind the scenes, possibly using automated wire transfers.

thanks for responding.

I didnt neccasarily mean specifically how to do it with paypal and commerce, I just meant in general.

Currently when a customer places an order, regardless of who the product author is, the money gets transfered from the payer (customer) to payee (site owner).

But as a marketplace the payee is another user/(merchant) of my site. So is there a way for either,
1) The payer places an order, the site owner gets paid, but the amount each merchant should be payed gets stored in my database, then at a specified time i.e Once a week, or once a month etc, the merchants will automatically get payed.
2) The payer places an order and a % of the payment goes to the site owner and another % goes to the merchant.

Are either of these available or configurable with seperate modules, rules and other payment modules. Or do these currently have to coded?

Currently when a customer places an order, regardless of who the product author is, the money gets transfered from the payer (customer) to payee (site owner).

Currently the money gets transferred from the payer to whatever the payment method's configuration says, whether that's the site owner or not.

Commerce has no built-in way to link payment methods to users (merchants). Payment methods will have to do this themselves. However, if payment methods *are* linked to a users (like Payment does) and orders are linked to webshops that have a UID as well, when a user checks out an order in a webshop, Rules can easily only enable those payment methods that have the same owner as the webshop.

Like I said, it's the payment methods that transfer money from A to B, not Commerce. There is no C, and A and B are not fixed. They are configurable and can be anyone, although one of them will usually be the customer.

Currently is it possible to just have a multi-vendor site at the back of it.

As in the payment goes only through the website and payment to the vendor and all is handled offline.

So the vendor is only required to upload the product (display being created automatically off course) and when it sells, a notification is sent to the vendor to drop ship. As site admin, you should be able to govern the entire flow.

Is this possible some how?

I am also very curious how this might be done, when this comes around.

Hi everyone.

This is my website **** (I have removed url because a lot of people do orders with a data like sjdhsdghjsd) - marketplace based on drupal 7 + drupal commerce.

Not so easy project... if someone has a questions let me know. I will try answer or help.

payments, how they work?

This website without any payments.

ehm.. that do you mean with "without any payments"???

i see at least 3 payment methods

➜ перечислением денег на карту Приват-Банка;
➜ почтовым переводом;
➜ передачей денег при личной встрече.

my question is: how the money is transfered to account of seller?

As I said the site has no payments.

>➜ перечислением денег на карту Приват-Банка;
>➜ почтовым переводом;
>➜ передачей денег при личной встрече.

This is the text from the shop (payment details). The Seller inform users how he can get money. That's all.

Please tel, how you do differents carts to differents shops?
Скажите, как вы сделали разные карзины для раных магазинов, какие хуки использовали?

I already covered multiple carts in #239. Let us not repeat ourselves every few comments.

Hi guys,
I wrote Commerce Payback module that provides basic marketplace functionality.

Payment method: buyer pays the website, website pays the seller using Simple Paypal Adaptive payment API when the buyer has confirm receiving the product.

Shipping is still a problem and needs per-seller-orders for buyer.
To fix the shipping problem, I created 2 pages that are supposed to replace the default user orders view.
These pages allow the seller to confirm shipping the product (a line item in an order) and provide shipping info for the buyer (a few shipping related fields on the line item) and the buyer to confirm receiving the product.
To do this I had to list line items instead of orders in these pages...

If you use the scheme where buyer pays website owner who then pays seller wouldn't you be losing money due to double charging of paypal's transaction fee? The seller would end up with much less money.

If you use the scheme that involves direct payments to the seller, how can the website owner track payments?

Morning All,

I have a perspective client who may choose to sponsor the development of this feature. It's a private individual, not a corporate, so budget is always a biggie but I wanted to have a chat and see if there is enough common ground to make this happen.

Not sure on best practices to start a discussion on this, so suggestions welcome on how to do this.

Thanks in advance.

Cheers
Brendan

@BrendonP: Can you share some more info on what kind of site your client will be building and which marketplace features they'd be interested in developing. If you read through the discussion more closely, you'll notice some diverging views on how this could/should be done....

@258

Using Paypal is always going to involve some type of concern. On one hand, the house can push that cost onto the seller. I've seen where commissions, percentages, etc reflect the seller paying BOTH transaction fees and the house pays none. This can be a problem with marketplace environments that have trouble selling the service to the sellers. If it isn't worthwhile for the sellers, they won't sign on. Despite the ripoff that is selling on Amazon, the benefit is increased visibility for the sellers. Their margins might be razor thin, but they're selling more than not selling on Amazon at all. So does the house here in question have that kind of interest from sellers? Will they take less of a percentage for the increase in visibility?

Allowing sellers to collect their own money and pay you results in the same double charge. It is easy to track payments since you can just check your orders. Unless you're saying not to use Paypal at all in that case, then I think that would be a bad idea.

Truth is, once any marketplace gets worthwhile for both the house and the seller, the house will probably end up implementing another merchant gateway like their own bank. Anyone serious is going to do this however at first they may not see the benefit of doing so since it's a monthly cost. I've even seen marketplaces charge sellers fees to offset their gateway charges. When the house gets big enough, they start making the rules.

We can use the PayPal Mass Pay for the payments, it takes $1 fee I think... But in my opinion the problem we have here is not really managing the payment.. The only big problem that I've encountered is shipping.. We are talking about it here: http://drupal.org/node/1706030

@markwk: Thanks for the reply. Yes it really is a can of worms this. Not sure I can give a definitive answer as we really in a preliminary discussion stage.

If I had to put a peg in the ground, I'd say the following would be required:

• Multiple stores per site, the “marketplace” model
• Each store administered separately from each other
• Store Admin should be able to administer their own products only, also add new products to their store and modify or store specific information
• Include some default store specific information for public display, e.g. store logo/branding, name and the likes
• Generally a site visitor should see all active products from all active stores but be able to view a specific store’s products only. I.e. visit the “home page” of the store vs the main site home page which would include products from all stores.
• Payments
• Automated payouts to store owners minus fees/commissions and the like
• Ability to set a delay in automated payout, e.g 1 day or 15 days or 30 days etc
• Multiple payout options (e.g. paypal or another provider)
• OR
• Automated reporting detailing payouts / store, fees, commissions etc so that site owner can pay store owners manually

Reading through the comments above, I can see this client has not thought through all the implications of the different methodologies, e.g. tax or liability.

Marked #991054: Drupal Commerce UberCart Marketplace as duplicate of this one.

@BrendanP @bojanz I propose a deal to you and to everyone who is interested in making this issue closed.
Here's my 2 cents: I assigned a bounty of $5. It will go to anyone who will create an implementation making this issue closed.
This sum is not enough, I guess. In that case you can easily put more using www.patchranger.com – the first Drupal patch crowd funding platform.

Conditions of getting the reward : this issue gets “closed” status (ie, having “closed (fixed)” status for full 2 weeks). Technical requirements are the original post of this issue and post #239 of bojanz.

Here is the plan:
1) Everyone who is really interested puts their own 2 cents not into this discussion, but into the common fund, increasing the amount of reward.
2) The amount is accumulated for as long as there is a brave one that accepts the challenge. That means he attaches to this issue a patch with a module that meets the requirements and closes the issue.
3) Community tests and reviews for compliance with technical requirements (the stated functionality). No - the issue gets re-opened with comment telling what is wrong; yes - brave one wins a jackpot.
4) Anyone can join the race at any time, giving his version of the patch. The collected sum will go to only that one whose patch will close the issue.

Hint : to review any patches that will be provided, you could easily apply them with Patch Manager module.

what is the status, now? anybody?

+1

Not sure about patchranger but I will chip in $100 to anyone who produces a functioning implementation of this.

I will chip in US$100 more toward funding development of this feature as stable.
And can help test, validate, pilot.

I'll chip in $0.17. That's USD btw.

I'll chip in $0.17. That's USD btw.

That will surely get people motivated to contribute!

I know, right!

But in case anyone doesn't fully realize my sarcasm, what I would like to say is that this project is not very trivial and likely anyone you want working on it wouldn't do it for a few hundred bucks. I understand if people can't afford to pay all on their own but we should probably organize a chipin better. It would even be better to go find someone willing to do the work, get their quote, and then come back and ask everyone to chip in directly to the programmer providing the quote.

Good idea to as for a quote, please go ahead RKS. In the meanwhile, to become clear for what we should ask a quote, a separate project management site would be very handy. In that, a list with people that actually realized a form of marketplace with D7 and Commerce modules. As said, the experience and knowledge is available but someone needs to pick up the project management in order to evoke commitment and to bring in all the details about already created marketplace solutions with Commerce. The project manager would do a good job personally inviting known people to share their knowledge in more detail, thus forming a growing project team. Think about the Commerce Guys approach. Without that more professional approach, I think quoting or working with patchranger wil become much more effective.

I can chipin $100 or more.. My specific use case would need each store to have seperate payment account that they control. I can also help with testing etc. Lets get this thing started!!

I think the numbers a bit off here and the "pay for a patch" model seems a bit ridiculous for such a huge amount of work needed, especially problematic is this question: a "store" entity type VS. Store = OG group VS Store = a user profile type via Profile2.

While I think certain aspects of a marketplace built with Drupal Commerce could be done for 5,000-10,000 usd, I think some of the expectations about what a marketplace needs to be will make it hard to get a general consensus on what to build for everyone.

Some major changes and restructuring are needed to make a "general" MP work. This a serious challenge, not a weekend project, but a project requiring hundreds or over a thousand dev hours and ideally a serious backer and/or drupal dev house sponsoring this.

I currently use Profile2 entity type and various tweaks to get a MP working but this marketplace isn't generalized to be useful to the vast majority and much activity occurs offline. If sponsored, I'd be willing to willing to work through some of the work necessary to make a MP work with User Entity/Profile2 and a Payback Payments model.

Areas where I'd like to see someone higher up the chain provide responses / advice: multiple chats/orders? how best to override site orders into store specific orders, etc.?

I'd suggest we move this discussion somewhere else like Damien's sandbox http://drupal.org/sandbox/damz/1232160 and open up some specific threads for the various questions opened in this discussion...

@275

I can agree with much of what you say. Just reading through anyone can see there are several conflicting requirements. This thread doesn't contain a solution that will work for everyone. Which is why I think it's best to split into several groups. For example, you mentioned carts, my requirement would be single cart, multiple stores in the same cart. Further up, someone else mentioned they wanted multiple carts.

So why don't we start a split of this thread into groups, like "Those who want a site exactly like Amazon, stand over here. For those who want multiple carts, stand over here." Etc. Then each group can know they're all working towards the same goal and putting money into a pot that will help them in the end.

The only other option is to go through and find all the features that common amongst all the use-cases and only do those things, providing an api for the other needed features to hook into. That way everyone can chip in for the major part of the project that will be needed by all, the API, and then individually can code/sponsor the smaller features they need specific to their use-case in a small contrib module.

If you would rather option one, let's define the groups and start from there. For example, we can move one group to the sandbox link you provided. For that area, what specific use-case would you want and want to discuss with the others who need the same thing? We can move other requirements to another thread.

Two items which were more or less pre-conditions for any type of Commerce Marketplace were; the Inline Entity Form and a Store Entity.

The first has already rolled out as part of Commerce KIckstart and Ryan is on record as saying that the Store Entity will be included in the next stage of Commerce development. I guess this would be within the 7.x-2 branch?

Lets not forget also, that Commerce Guys are building a Commerce Marketplace of their own and whilst this isn't quite the same animal as is being talked about here, the general points discussed above can not be too far away from their thinking.

I do agree that it might be helpful to firm up on 2 or 3 general marketplace models going forward.

I actually don't think their thinking with that site is related at all. It appears that's for showcasing Commerce and not a "marketplace" in the same sense as we are here. I really that as being a place where someone can get info on Commerce Guys services, products, etc.

I agree, however, that 2-3 models would be best moving forward. In order not to sound self-serving, I will let someone else start the model suggesting.

Apparently RKS (#272) you are not familiar with crowdfunding. If we all chip in we can come up with a sum much larger than what any of us by ourselves can contribute.

I am not suggesting paying US$100 to develop the feature we want, but that together if enough of us pitch in we can compensate (motivation is assumed in an open source community) a developer or more for their time and efforts.

I would gladly struggle and do whatever is needed to come up with the sum that can get this done as it is one of the features we look forward to include in Markets of Hope. In our case, most of our development is done by myself, volunteers and interns.

If we were to come up with a larger sum to hire a developer, it would probably end up fitting our specific requirements and custom needs.

I am currently working on such a fix myself combining multiple modules (groups, views, access, etc.) to match our specific needs. The results are not likely to be useful to anyone other than as examples and ideas, but I will share the steps, and instructions back to the group in any case.

Again, I can chip in US$100 and I will gladly pitch more if it gets this feature working as a stable feature without patching or forking.
We already have US$300 pledged. I can increase my pledge if that is what is required for a developer or team to work on this.
I am happy to have the feature working and then do the rest on my/our own customizing it to our needs.

I guess it makes no difference to you in any case, no sarcasm involved in my comment.

On the contrary. I fully understand that to efficiently raise funds you need a unified goal. Mind you tell me what that unified goal may be since you obviously take offense to people trying to steer the conversation away from random people throwing words around? Oh yeah, you haven't done that yet.

Have any of you come together on a serious battle plan for the requirements? No. You just say, "I'll give $100," and a mystical developer will appear and write a magical module that satisfies everyone's wants and needs. Why don't you put your money where your fingers are and start a chipin? Commit and show everyone you're serious. Otherwise, sit back, contribute to the whiteboard with your own requirements and stop trying to jump on people who want to iron out a unified goal for everyone to get serious with.

But by all means, contribute blindly to some project without any defined goals or possible solutions and hope to get out of it what you need. The rest of us can do what's suggested and figure out what we want, what other people want, and contribute our money to a project we know will work for us.

Dear RKS,

Your rude attitude is part of the other face of community interactions and collaborative spaces. You criticize and attack those who offer to collaborate, losing the focus on adding value and allowing others to do so as well in different ways.

True collaboration lies in allowing multiple stakeholders to each provide part of what is needed, to enable others to contribute, to identify and acknowledge value in each collaborator and coordinate and articulate all efforts.

I pledge a certain amount to compensate and motivate anyone who works on the pending issues. We all know that it is not enough. Yet we also know that this is not a job offer or a gig someone is being contracted for. Whoever works on this, will work because he or she needs it or because it is relevant to his or her own project. My pledge provides a little compensation, think of it as a thank you note, a way of giving back to those who give so much and make a good deal of the work we do easier.

I do not offer to pay for developing the marketplace I need because: 1) it would be selfish, as I have my very own and specific requirements; and 2) it would be too expensive to have a developer work on it at the moment, given my budget limitations.

I'd rather contribute to the development of a stable marketplace feature and functionality - whatever it ends up being - and then take it from there and work on customizing it to our own project needs, without trying to impose our own needs and much less influence such features and functionality with our compensation offer.

A stable marketplace functionality, extendable and customizable is good enough for me and I'd rather have that than burden others with the specifics of my requirements, which don't match what is being discussed here. Once we would test and develop our own functionalities, we would give back to the community releasing them as additional modules that extend the functionality of marketplace.

That is my contribution to your whiteboard: keep it simple, work toward a basic marketplace functionality that others and other modules can extend and customize. To include functionality of specific types of marketplace or requirements into such a feature would limit the advantage it provides. That is the nature and spirit of most successful open source project today and that is the main current of thought in Drupal. Basic modules with basic functionalities which can be extended by contributed modules to make the feature match specific requirements. That is how Drupal Commerce is built indeed and largely the reason it came to be as the previous solution ended up being too specific for this and that.

It takes a special kind of people to take something good, such as unconditionally compensating the work of others and joining efforts to make that compensation bigger, and turn it into something bad and attack those who offer it.

In any case, good luck with your attitude and contributions, your attempts at control, your threats, offenses and disregard to the value of others. Seen it too many times. That only generates discomfort, drives people away and in the end tends to forking.

I would invite you to acknowledge the value each stakeholder brings and to not try to force everyone into your pre-conceived notion of what a collaborator or contributor should be. Not everyone should be contributing to the whiteboard, or coding, or funding. Such is the nature of collaborative efforts and open source and crowdsourcing. Each individual finds a place and a role is enabled so that everyone can contribute. Even those who only download and use have their role, the most important one, which is the use of the tool, for a tool developed that is used by no one has no value.

I would invite you to review your attitude, which seems arrogant and prepotent, and walk with everyone, as peers, as friends. Avoid pushing away others who can add value and remember that there is no way to lead them your way with harsh words.

Ps: As these last few messages sound like a non-tech, almost personal argument, I would like to apologize in advance if my words offend you or anyone else or if they sound condescending, arrogant or if disregard for others is inferred from them. That is certainly not my goal or interest. My interest is to see a stable marketplace feature developed so that we can extend it and use. I and I'm sure others will be happy to see the discussion and exchange of opinions go back to such a goal.

Yeah, let's tie this angle off; no need to add more posts to the thread, which is about marketplace functionality specifically.

For anyone new coming to this thread, please note that the original post was updated a while ago to indicate the current status of this work.

This is a response to ##263 by BrendanP. I came to this thread because I had been informed by the DP people that, in no uncertain terms, multi-site support was already possible. However, reading over this thread (from a few months ago, admittedly) it appears this is far from the truth. Or maybe not. I'm confused about the whole issue, and perhaps the terminology is leading me away from where I need to be.

Anyway, I want to just point something out for future reference: "Each store administered separately from each other"

I don't believe this is a "must" issue, I see this as very much "optional".

I definitely can see why this would be useful in the marketplace model being fleshed out here. However, that's not the only use-case for all of this functionality.

Consider a company with multiple branch offices. The company has a single catalog, from which the branches pick up certain products for local sale. One might have 80% of the catalog being sold in all of the branches, with the other 20% being sold here or there.

In this case I can imagine sub-admins being used to maintain some of this information. But at the same time, as the catalog is basically universal, a single admin should have editing privs over everything. Perhaps there are no sub-admins at all.

Now you might say this is a different case entirely, but it seems that 90% of the rest of the functionality being mentioned above applies to both of these use-cases. Shipping, for instance, is likely to be handled by the branch offices from their local warehouses - but not always, of course. I'd hate to see a solution that locks-in the concept of sub-admins for each level because that's how the marketplace use-case would want it.

Ideally I think the system should have an optional hierarchy, created simply by entering items at different levels in the stores. If I enter a product at the "super" level it defaults to appearing everywhere, but if I enter it at a sub-store level it appears only there and sub-sub-stores. Likewise, if I have a product in the super level, I can enter a new description at the sub-store, and that description appears at the sub-store and all it's sub-sub-stores.

Does anything in the system being fleshed out support this sort of functionality? Or is this something that DP already does?

Hi, I see this work is being done related to marketplace and DC http://drupal.org/sandbox/maciej.zgadzaj/1950386
greetings, Martijn

I'd like to add a note that Commerce Funds looks pretty interesting for managing payments. I haven't played around with it, but it might be nice piece to this puzzle. http://drupal.org/project/commerce_funds

I've developed a marketplace module, you can see the demo here: http://cmp.bazarayan.com/ - The module has some problems and is not ready yet. I'm working on it on my spare time so it might take a while before it gets completed.

Features:

• Stores: The module provides a new entity type for stores. Each user can have multiple stores and each store can have multiple members. Each product has an Store reference which determines which store owns that product. An entityreference Selection plugin is developed to restrict the store entityreference autocomplete results to the stores that the user is a member of.This feature is completed and working.
• Store access control: There are 3 global store roles (non-member, member and store administrator). You can also create store-specific-roles yourself and assign permissions to each role (just like Drupal core permissions and roles). This feature is completed working.
• Marketplace orders: A new order type which is used as the top-level orders and is used to handle customer carts. Customers only see this type of orders.
• Store orders: A new order type which is used handle orders for each store. Each Store order has a reference to the original Marketplace order. Every time a product is added to a marketplace order, based on its Store reference, If there are no other products from the same store in the Marketplace order a new Store order gets created and the product also gets added to the new Store order, otherwise the product is added to an existing Store order which contains products from the same store. Each Store order is updated whenever something changes in the associated Marketplace order - All orders are synced at all times. Also, store members with sufficient permission, can edit the Store orders. This feature is completed and working.
• Shipping fees: A new shipping method is developed which calculates shipping rates for each store and adds the sum of calculated shipping fees to the marketplace order. Currently, because of commerce_shipping's limitations, there are problems with calculating the shipping rates based on the store preferences using shipping methods like UPS. But the flat rate shipping method works just fine.
• Payment to stores: I was thinking of using commerce_funds for handling the payments. But commerce_funds has some limitations, It uses an specific order and product type for crediting user accounts and it is hardcoded to work with user entities - it doesn't work with any other entity type (e.g. stores). I can either for the commerce_funds module and make some adjustments so that it works in the marketplace system or we'll have to come up with another solution for this problem.

P.S. The code is on github (https://github.com/farhadhf/commerce_marketplace), I wanted to put it on drupal.org, but there's an empty project and a sandbox both named commerce_marketplace and I couldn't come up with another name! I'll move the code to drupal.org later.

Hi @ farhadhf great development. Why not name it Commerce_Stores or somehow get commerce_marketplace removed?
Looking forward to your improvements and hopefully also integration with Domain, Multilanguage and Metatag so all stores can be uniquely domained, languaged and tagged!

Greetings, Martijn

Really excited to even have this starting point. I installed the git module and so far no errors. Will test and tweak where possible.

@VidiChannel, Some of the views do not work properly yet (permission problem) - You'll probably have to disable SQL rewriting in those views to make them work. Let me know how it goes!

@farhadhf - you are doing wonderful work, and like VidiChannel - i'm just stoked to see things THIS far! I would love to help think through strategy for payments. You mentioned using Commerce Funds - but after reading up on it wasn't obvious to me how you may plan to leverage it so payment is broken up and sent to each store individually. Of course- this is assuming you can shop across stores. This would be beyond the scope of what I was after - and perhaps you as well.

I'll toss in 100$ minimum and offer to help whiteboard/architect. Sounds like we may need to aggregate some ideas.

The code is now in a sandbox project: http://drupal.org/sandbox/farhadhf/1979422
Also for handling store payments, please see #1979474: Handling store payments and let me know your ideas.

@stopshinal, Thanks! Please contact me in IRC (farhad_hf in #drupal-commerce on freenode IRC) or my Contact form in Drupal.org :)

just wow! thank you farhadhf! will be using this module for users to create film events / screening and sell tickets.

Thanks for your work! I will test it and give feedback.

Thank a lot! @farhadhf
I'm such a noob but i will try to find the way to contribute this!

What about if an Distribution was created?

What are the pros and cons of using organic group as a store entity rather than something like ECK. I am quite leaning towards using og for creating stores as it will give more flexibility in seperating the stores and their content from other stores.

While using og will there be any difference in how we implement cart and payment. I just want to implement a simple payment system in which site takes all money and then does the accounting and payment to seller every two weeks. It would be nice to have some more detailed steps in how should I implement this simple payment system. The payment types will be Cash on Delivery and credit card.

@farhadhf,
nice, hope you can get some 'awards' for your work.