Can you please provide a pointer to the documentation for this new functionality? I.e. what market it was developed for, what the “use cases” are, what need does it try to address and any details about usage.

What are the usage scenarios? What problem is this trying to solve?

[quote name=‘tbirnseth’]

What are the usage scenarios? What problem is this trying to solve?[/QUOTE]

I could see this being useful for anyone selling products that are drop-shipped from multiple vendors.

If, for example, I have 3 manufacturers all drop shipping products for me - I would set them up with different vendor accounts that allowed them to create and manage their own content, orders, and inventory.

If a customer orders Widget A and Widget B from me - but Widget A is shipped by manufacturer X and Widget B is shipped by manufacturer Y then the multivendor edition makes it easier to send separate purchase orders to each vendor - making the order fulfillment, accounting, and operations in general much easier for companies like mine that distribute products shipped from multiple locations/businesses.

I hope that helps. :smiley:

Finding a drop-shipper who wants to manage the product data for their customer’s sites would be rare in my experience.

I was hopeful that cs-cart might be able to identify the problem they were trying to solve, what they went through to understand the use-case scenarios, etc. before they implemented a solution.

Knowing the problem to be solved would be helpful. I’ve not seen a high demand for ‘mall’ type stores whereby different vendors all come together under one payment system to advertise and ship their products… Seems like a huge amount of work for a very small market.

I reluctantly agree. Having worked with a wide variety of drop-shipment and dedicated warehouse setups, drop-shipment is really a temporary phase for any serious business.

  1. The accounting and paperwork for drop-shipping arrangements is pretty ridiculous as you add multiple vendors. If a person throws consigned inventory in the mix it is a freakout - especially once returns inevitably occur and need to be properly accounted for.

  2. There is next to no incentive for drop-shippers to access or update your store with their information, unless you are getting the equivalent of an affiliate discount or perhaps you have an exclusive distribution arrangement with multiple vendors.

    My hopes for this edition was that it would be more like the Magento multi-shop format…

  3. Shops could be established with multiple insecure domains, but tied together via a single secure domains for processing.

  4. Catalogs and products could be enabled per domain/store url.

    If I can give a brief example of how this scenario becomes useful… Say I have a warehousing operation that has products from a number of different departments, but each department would like to be able to advertise their own product line in an independent store front that has, as an SEO convenience, it’s own domain.

    This is a real scenario for myself. I run a store for a company with multiple sub-departments that each have their own printed catalog. They’ve asked to be able to have a branded subdomain that will just have their products and their own sortof color-coded version of the main store banners, etc.

    However, we have one payment gateway for each of these departments - it would be great to have separate domain/subdomain entities possible for each department rather than simulate this with categories, etc. It works, but it is kindof convoluted.

    Magento allows the catalog to be broken out into multiple storefronts with the ability to limit subsets of the catalog for a given store, but with a united payment backend. That’s my understanding - someone correct me if I don’t understand their feature.

    Again, I don’t think there is a huge market for this type of set up - either way this feels like a niche that makes me wonder if the folks who voted for it are actually planning to use it, or if they are just trying to keep up with the joneses. If these folks all think that drop-shipping is the wave of the future or real e-commerce, they are mistaken.

    Nothing beats having centralized inventory.

    NOW if you were using the various vendors to farm out orders to different distribution centers - THAT is another ball of wax entirely - I could see that working well with the setup being suggested by CS-Cart. But again, this is a niche. Without direct integration with ICM on the warehouse side updating web inventory figures via cron - I mean this is not for the faint of heart.

    I think there are much higher functional priorities. Shipping granularity is one. Being able to show products by tag in blocks, etc. is another. Having a straightforward, simple checkout is another… Maybe I’m off on this though…

Documentation will be available in the Cs-Cart Manual and in the Knowledge Base, after the final release.

so 2tl will there be an option to upgrade from cs-cart 2.0.15 to multivendor edition?

agreed … all the vendors i have worked with .simply would not login to manage there own products … it would be nice to know the problem that they are creating this solution for .?


Just wanted to dispel some of your doubts regarding the CS-Cart Multivendor edition.

We decided to develop and release the CS-Cart Multivendor edition because of the great and repetitive demand from our existent and potential clients. Usecases are different, but they are surely real.

And actually, as it was said earlier, CS-Cart Multivendor branch is a good platform for the Multishop edition which is scheduled to be released next, probably later this year.


Okay, so publish the use cases so we can understand what it’s intended for and how it might apply to our business models.

That was what was asked for.

We can only assume that reluctance to publish use cases implies that they don’t really exist or were not really used to “drive” development (I.e. resulting product doesn’t meet the use-case definitions).

The use case is quite obvious - you can allow anyone who wants to sell something online to use your online shop as an existent and proven marketplace with the centralized administration.

Benefits are obvious for both parties - vendor gets a working and ready to use channel to sell his goods with minimal efforts and the marketplace owner gets his commission for the provided place at the marketplace.

For those vendors, who would like to run a separate store at their own domains with their own checkouts etc. we will evolve the Multivendor edition of CS-Cart into the Multistore version later, hopefully, this year.


The use case is quite obvious


Obviously it isn’t since there are questions about what drove this functionality to come forward. No one has identified any “vendor type” that would be willing or able to manage a product line in a foreign store. I certainly know of no drop-ship supplier who is hungry enough to try and manage a set of products in a foreign environment. This isn’t Ebay.

So I think most questions related to who the expected “vendors” are that would utilize this functionality? I know of no merchants who want to provide a “flea market” approach to selling products and then them being responsible for the payment side of the equation (which seems to be the common denominator).

Since cs-cart is geared toward smaller merchants (it doesn’t scale well for meidum or large), what vendors want to “channel” their sales through an existing small merchant and are willing to invest in the ongoing management that it takes?

I’ll get off my horse… My personal opinion is that this was a waste of development effort when more pressing issues have been ignored.

Thank you for your opinion, I understand that you do not see any use cases for Multivendor in your surroundings and among your customers. That’s quite possible and quite reasonable - we do not insist that everyone will need the Multivendor editionor that there will be a certain use case for all existent CS-Cart users when it’s out.

But, as I have mentioned above, it was not our whim to develop Multivendor. This is our response for the clients’ demand that we see here in CS-Cart for years (yea, really).

And you could probably notice from my previous posts in this thread that per our development plan the Multivendor edition is a solid base for the Multishop edition of CS-Cart which is the top voted request from CS-Cart users at the Ideas forum. Multishop version will extend and supplement the Multivendor edtion with the set of unique features and all of the Multivendor features and functions will be used there as well.

I hope you will agree that our efforts to bring the Multishop version of CS-Cart basing on the Multivendor edition do deserve a better appreciation than “waste of time”, I would propose something like “good job, keep working hard to get it faster”


I don’t mean to criticize the efforts put into the development of a complex system such as this. As a developer I recognize the impact of many of these changes to the base system as well as the functionality available to your current (and future) customers.

As a customer I find it frustrating that many of the issues, bugs and problems in the base version of the product are not being addressed while we sit and watch valuable development resources being applied to a limited market (both multivendor and multishop). There are issues that have been “open” for over a year in the 2.0 product (some of which were reported during Beta) with commitments made to resolve them but those commitments have long since passed. So I believe you can understand the frustration when core features are left buggy and/or incomplete and efforts are applied to new features which seem to have limited value to the existing customer base. Again, I will cite the Configurable Product issues as a classic example of an incomplete implementation which prevents this valuable feature from being used in other than the simplest stores.

Please take a look at my open tickets in your support system for detailed information about 2.0 problems that have yet to be resolved…

Given other comments in the forums and even comments related to the Roadmap 2.1 thread, I think it’s fair to say that your customers are asking you to complete and stabilize existing functionality before launching into new endeavors.

I could be completely off base here. If so, I would certainly like to hear from merchants who are using the multivendor extension and a little about the business models where it is being applied.

The use case scenario is very obvious for me… I’m in the Travel business.

We need to think about products not just as physical, but also as services sometimes, from there, here are 2 great uses:

1 - Have Hotel & Leisures providers manage their inventory, their reservations and get a commission out of each sale. It I would have been impossible for me to do that unless I hire a bunch of people. I’d have to call the hotel or the Leisure provider and update regularly the inventory, product information, changing prices, reservation follow up, availibities, etc… a Multivendor edition with a calendar reservation MOD can make this happen.

2 - You can apply exactly the same concept for the real estate rental business: Have Property owners manage their rental inventory, prices, reservation calendar, etc… and get paid via recurring billing or based on a commission for the service you offer.

There are many many use case scenarios…

I can tell you that I’ve checked dozens of Online Rental scripts, none of them comes close to what cs-cart offers.

I’m sorry you have a lot of pending issues with bugs for the regular version, I do want many things to be resolved too but that doesn’t mean that if multivendor doesn’t fit your needs, it is not a useful version. This has nothing to do with that. No offense. Look at it like this: Business Models (and functionalities) change depending on the products we sell.

I believe in the serviced model case. As for vendors willing and able to login I cant image that as always practical and realistically why would they really want to. Same as in bricks and mortar, I know wholesalers are not going to stand in someones physical shop, present and sell their stuff then give the store owner a cut for working the location and till. With multivendor, the separation of owner/vendors means someone is better able to manage all parties offerings to any level of service agreement whilst making the vendor more targeted.

I don’t see multivendor as a niche market at all and there is nothing wrong with a flea market. In fact there is a huge amount of “under the radar” businesses out there that could use the serviced vendor offering, not the cart. If I ask folk about managed capability I always get the same answer… when.

I am really looking forward to multivendor, to me its a great initiative. Only thing is the lowered ceiling due to tickets like shipping charges that don’t include package sizing variables. That’s a major lack of required functionality.

There is definitely some cart before the horse work going on for whatever reason and it’s frustrating for sure, but at least I get to continue to develop my offering with multivendor while the CS crew are dealing with some of the outstanding tickets. The least I can do is have faith that they will.

If we could have a period for early seats to become grandfathered like the old CS-Cart licenses, now that would be good!

Good to know there are practical applications for the effort applied into this…

[quote name=‘admin’]Hi,

Just wanted to dispel some of your doubts regarding the CS-Cart Multivendor edition.

We decided to develop and release the CS-Cart Multivendor edition because of the great and repetitive demand from our existent and potential clients. Usecases are different, but they are surely real.

And actually, as it was said earlier, CS-Cart Multivendor branch is a good platform for the Multishop edition which is scheduled to be released next, probably later this year.


Please can you clarify the information about the schedule and Multishop edition a little bit more? There is a special about multishop and cs-cart now here: [URL=“”][/URL]