Which Ecommerce Script Should I Use?
Are there ready made PHP scripts which would allow my USERS to create their own stores? I don't want an eBay clones. Just a script which is easy to configure and customize.
Webmasters Stack Exchange is a question and answer site for pro webmasters. It only takes a minute to sign up.Sign up to join this community
Most probably you'll need to set them up manually or hire a developer. Actually, you'd want to hire a developer because someone needs to support that. It's very risky to host eCommerce websites because you need to keep everything working and up-to-date to avoid security issues.
Zeuscart is the best free php ecommerce shopping cart script & it is highly customizable according to your needs.
So, you can do this a couple of ways, but first you should understand that it's going to be either extremely simple, or extraordinarily painful. Evaluating these systems is near impossible until you have actually had to build a few of them out. I have come to hate pre-built, all in one e-commerce solutions a bit. It's not the basics of handling the transaction that get messy - they all do that simple task extremely well - it's all the complexities of different regions, associated taxes, unpredictable business rules, and odd shipping schemes that make these projects tough. Think about doing business in Europe. Now you have to account for all kinds of rules applying to the Value Added Tax, and these kinds of rules are not uniform from country to country. In the US, state and local taxes might apply. Knowing this, and when to charge x or y is what makes e-commerce painful. You should also take into consideration the market / industry of the client - the rules and norms vary from industry to industry.
Option 1: Use a CMS like drupal or wordpress and a shopping cart system:
Drupal is a good option if you need to scale for high traffic, need to be able to manage a lot of different user roles for varying levels of access, etc. Drupal is also the best option for people who don't want to learn programming but still would like to be able to do just about everything a programmer can do.
Drupal Commerce has a learning curve, but it is definitely a very capable system if you are willing to take it on. Just make sure to understand the difference between products and product displays, and why they are treated separately in Commerce. It can be annoying, and is one of my biggest pet peeves about Commerce, but for certain kinds of products (products like a tee-shirt that comes in 5 sizes and 7 colors - you create a product for each, and attach them all to a single product display.
Drupal's biggest downside is the extensive learning curve - ESPECIALLY with Drupal 7 and the Drupal Commerce module system. Depending on your needs, you might want to go with Drupal 6 and Ubercart. Also, to build a custom template may require a little bit of php.
Wordpress: It's super easy and flexible. You need minimal time to train your end-users, but the e-commerce solutions I have seen so far are weak, though it has been a year since I have evaluated it for this landscape. There may be a lot of great tools out there that have developed since then. If you can find a truly robust e-commerce plugin system for wordpress (it may cost $99 or so), you might want to give it a spin. The learning curve for wordpress is significantly lower, but the e-commerce plugins were lacking the last time I tried to use it for e-commerce (it required a lot of custom development).
The second option is to get an open source solution that is designed for e-commerce from the ground up. I think this is a better way to go about things if the site doesn't have complex needs for content publishing, role management, etc. If you do have these needs, Drupal is an outstanding solution (as long as you have a little patience).
If you don't have those needs, here are some good standalone e-commerce solutions:
The next thing to consider is how to process your credit card transactions. I prefer Authorize.net for a number of reasons - the client pays for this, and it serves as the background credit card processor on your site. You're not a bank, and you never ever ever want a solution that stores credit card transactions within the app. You can get into a LOT of trouble doing this if you aren't certified to store private credit card data - and it will cost a fortune to do that. So, use authnet.
Authorize.net is also the only solution that permits you to do recurring payments. More on that in a moment.
Your other option is to use a hosted solution like shopify:
One important final note: - If any of your projects need to allow for recurring payments (ie regular monthly / automatic cc transactions) , you need to understand that this is easier said than done. For reoccurring payments to work, credit card information MUST be stored somewhere. If this is required, you want a system that can interface with authorize.net's automatic / recurring payment API, and NOT one that stores credit card information locally. At the moment (to my knowledge), the ubercart and Drupal Commerce solutions are lacking, but they are trying to get it to work with a service called recurly http://drupal.org/project/recurly
Edit - to this comment:
"Most probably you'll need to set them up manually or hire a developer. Actually, you'd want to hire a developer because someone needs to support that. It's very risky to host eCommerce websites because you need to keep everything working and up-to-date to avoid security issues.
However, you might find this a helpful resource (Magento is a great app). While writing this, the website doesn't work for me but here's a cached link."
(for some reason I couldn't add a comment) I don't necessarily think this is correct. If you are doing e-commerce correctly, the secure transactions are all being handled by the third party payment procesor (this is what Authorize.net does, as well as other services). The script should NEVER store any kind of private data like credit card information. For that to work, you need a DSS PCI certification, and you have a lot of expensive work ahead of you to get to that point. So, instead, you should use a payment gateway that separates the layers requiring secure transactions and the layers used for browsing / shopping / cart / etc.