My wife’s business has the need to make some sales online and so naturally I want to help. I know next to nothing about E-Commerce, so I started to do a little bit of research. It appears there are three options available to people currently in the market for a shopping cart that will process credit card transactions. There may be more options as well, but this is what I have found on short notice.
Option 1:
It appears to be relatively cheap to just host a whole website with a shopping card and credit card transactions built in. Google Checkout has links to a couple of complete solution providers that offer WYSIWYG admin panels and editors for somewhere between 30-50 dollars a month.
Option 2:
Integrated Solutions that you build into your existing framework/website. They appear to offer differing levels of flexibility, ranging from an API, to a link to another website that has a cart.
Option 3:
Something like Satchmo which is a “webshop” for perfectionists with deadlines. I found out about Satchmo through a fellow member of PyAtl who had some success with it.
Why does E-Commerce have to be so hard anymore? Maybe it isn’t that hard, and I am very ignorant. It seems like 2007 might be a good time for mere mortals and Mom and Pop businesses to start taking orders online. So, what is the best solution for minimal effort? Is there a solution that works well with Python, and/or Python Web Application Frameworks?
On one level it would be great to know there is a completely Open Source solution to a relatively simple problem. After all, why pay 50 bucks a month if you can easily do it yourself. I think VOIP is a good example of small business doing Phone Service themselves, and the same model might apply for E-Commerce. On the other hand, processing credit cards is somewhat risk prone, so perhaps there is a middle ground that still serves as a good price point for small business owners.
Have you checked out Shopify.com? One of the cleanest shopping systems I've seen.
Perhaps the problem is that it isn't that difficult. At least for people who know what they're doing. I set up an ecommerce site for my wife and it wasn't that hard. Integrating with PayPal was a snap. I imagine Google would be at least as easy. So, what you wind up with is this proliferation of one-off solutions such as mine which don't combine with anything else and don't give anyone else something to build off of. I think good pluggable open source solutions are going to help here.
Checkouts are one of those applications that drip feature creep. Really simple do a paypal or amazon link. Oh, capturing your customers particulars? Well that's a CRM type of add-on. Want to support international? Now you need live foreign currency converters. The list goes on an on.
Probably the easiest I have done is a simple shopping cart input capture that is then routed to a secure forward to a designated email account. The email is formatted to also be the shipping label and invoice. You just print it out. Top half goes in the shipment, bottom on the box for shipment. The credit card payment is processed manually.
This arrangement works quite well so long as the product volume is reasonably low, like less than 50 pieces a day. This process also only works well if the merchant physically has the product. A cross bill, transship arrangement would not work under what is being suggested. But you know, 50pcs/day on a average $20 order is not shabby for the additional $30k in gross income. The 'automation' required is minimal and could be done in a day using current OS tools.
I would ask a crazier question -- does anybody know of a vendor who sells credit card slips in a form feed arrangement that can be fed to a tractor feed impact printer? A simple python script could read the same email stream and print out the names, accounts and totals on the slips. That capability would decrease the manual labor to just packaging and shipping.
The reason there isn't an Open Source solution that easily plugs into the frameworks of the day is risk. A single error can lead to financial loss and potential law suits from your customers. If you have a third-party payment solution, you can have your defrauded customers sue them, rather than you. With an Open Source product, you can't sue the community, so the buck stops at you.
Security is hard, credit card validation is easy. The math suggests that outsourcing the most sensitive of your operations to deeper pockets makes sense.
That said, if there was a single, solid, heavily peer-reviewed Open Source ecom solution with a solid API, I would use it - but this is one product that needs a track record before most people will risk it. A catch-22, you see.
if it's so "relatively simple problem" why dont you write one web service/app and make it open?
People who build those services and charge for them (50$/mnth is much for web biz?) have to eat something, so maybe your Mom and Pop can cook for them!? Then maybe it will be free.
I agree with most of what everyone has said. When your a small business it just doesn't make sense to take on the risk of writing your own credit card processing application, unless your the kind of guy that regularly climbs rocks without a rope.
A quick sidebar, about 14 years ago when I was 18, I happened to be rock climbing with some friends for the first time, and I happened to be half way about a 300 foot cliff when I looked over and saw a guy flying up the cliff with no ropes. This wasn't a trivial climb at all as it was a sheer face. I was both dumbfounded with his skill and his total disregard for his own life. I do admit it does sound like a fun rush, but one that I am to old to ever try.
There are quite a few programmers that are just like that rock climber, they can and do, climb cliffs without a rope. So, I suppose, outsourcing sounds good for the time being as I would not write that code myself.
Now, if there was an open source credit card processing system for python and it was well tested, then it might be a good opportunity. All in all though, I do appreciate a well written commercial application and have absolutely no problem paying for something that saves me time and makes me more productive. That is why I use OS X, that is why I bought OmniGraffle and that is why I bought VMware Fusion.
I guess my next question is what commercial shopping cart is a good fit for a Python Web App Framework?
Apparently, Amazon just released a competitor to Google Checkout. The examples for the API are in Java, PHP, and Ruby. Weird that Python is left out. What gives....?
I too have recently started looking in to e-commerce. As a long-time corporate Java developer, this has been all new to me. And as one of the previous comment-ors noted, the risk part is what scared me off.
I have a need to make a very customized online store. A couple of web designers I know want to sell some stuff. And being web designers, they're full of ideas on how the site should look and operate, and the concept is nothing like I've seen. But money is tight. After looking at as many options as I could find, this is where I'm headed:
0. Crash course in PHP
1. Pick one of the million $6.95/month web hosting solutions that supports PHP/MySQL.
2. Install osCommerce, and tear out (conceptually-speaking) all the customer-facing view (html), so all you're left with is PHP functions/modules.
3. Based on the designers' concepts, re-write the customer-facing view, with whatever the RIA fad-of-the-moment is. But plug in that new view to the osCommerce modules. Retain all the osCommerce admin screens, as they are not customer-facing.
As far as limiting risk, I really don't see a need to process your own credit card transactions. PayPal makes it dirt-simple, as long as you're willing to allow customers to temporarily go to the PayPal site for the transaction. And as a online customer myself, I always feel more safe doing business on the PayPal site rather than directly on joe-schmoes-online-junk.com.
Can anyone comment on this? Am I over-simplifying it? I already know that osCommerce has its "features", as you would expect from anything open source. But it seems to be widely adopted.
Why does the integration point have to be only Python? All you really need is a form of web-based API (URI-based access) that you can call from any application language. The cart/checkout/ etc...doesn't have to be written in what the rest of the site is written in. Place "cart" code in a sub-folder yourstore.com/cart/, or a sub-domain, like cart.yourstore.com.
Take example from large websites that comprised on many sub-sytems, from report generation in PDF, to email list managemenet system, to catalog maintenance. All sub systems often purchased from different vendors, all integrated together in a common html page at the end.
That being said. Why bother coding something for you wife? Just use one of the dozens of vendors out there that offer store/sites solutions, like http://www.prostores.com/? Granted you might loose some flexibility... but you're right, solutions have been around a long time for hosted store fronts of every type. And you're going to need to spend the time customizing the look-and-feel of you're wife's site with whatever provider you end up going with -- this, isn't as fun or cool as programming Python, but in the end, the goal is for your wife to sell products over the web.
As the creator of Satchmo, I'll give you some of my perspective.
The problem with eCommerce sites is that it seems that they never stay just ecommerce. The actual order taking and processing is one piece but you inevitably want to do something else. Let's say you want to add a blog or maybe links to articles about your site or custom quotes or lots of other things. You end up trying to figure out how to pull it all together. i don't think any one of them does a decent job.
OsCommerce, for example, is definitely the primary player out there. I will say that working with it is a nightmare. It is an example of what not to do with a PHP app. So, after working with that, I knew that there had to be another approach, thus Satchmo was born. Using Django gives it so many benefits. The biggest one is the purely template driven site. It makes it all so much nicer to modify.
Yeah, it is probably a little heavier weight than just throwing a pre-built site out there or adding a google checkout link but hopefully it provides enough flexibility without an insane amount of overhead.
As always, we're looking for input and feedback so check it out.