: 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

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 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:

Most Powerful but Hardest to Learn - Magento
(www.magentocommerce.com/) - probably the most powerful platform on
the block, but it's on another level as far as learning curve. It is
probably the toughest one to learn, but also is one of the most
capable e-commerce solutions available anywhere.
New Kid (shows promise): Prestashop www.prestashop.com/ - I just found this
after some googling, and I might give this one consideration over
opencart for my next e-commerce project. It's the first e-commerce
solution to win the open source award [PACKT] (from their site).
A simpler option: OpenCart (http://www.opencart.com/)- after the
headaches I had with the way Commerce works (it's powerful but still
a work in progress), opencart looks like it might become my next
e-commerce platform of choice.

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:

Hosted solutions are going to be simpler, but more expensive. I have been hearing quite a bit about shopify for this. You can customize the look and feel, etc but you are paying a monthly fee and potentially even a percentage of your income depending on your service or subscription level.

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 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.