Open Source Shopping Cart

April 8, 2008 10:28 AM

Simple e-commerce solutions. I have a fully built site, with individual webpages pointing to specific product items. I simply want to add a backend shopping cart functionality that resides on the server, without relying on PayPal. Whats the best opensource solution that allows me to pass a variable (ie, add a "Buy This" button to already-designed pages) to a shopping cart php function (inventory isn't necessary at this point) and allowing checkout/payment?

Is this possible or is PayPal the easiest way to go without completely
rebuilding my site in an opensource commerce engine (ie OsCommerce)?

I know this has been addressed to some extent before , but I don't think I need a sweeping e-commerce solution, just a cart, checkout, and merchant services (visa/mc) hookup.

posted by pinto to computers & internet (7 answers total)

How important to you, and why, are each of your stated requirements:

- open source

- resides on your own server (all of it? payment processing? shopping cart?) - this is an important point, so please elaborate.

For merchant services, you might want to look at Mal's e-commerce: mals-e.com. I know people who have been using it with success for years.
posted by amtho at 10:54 AM on April 8, 2008

Hi amtho,

-Open source is preferred but if there are other free/cost effective options, I wouldn't rule them out.

-Again, figured we could keep cost down by keeping it on our server, but perhaps I don't understand the rest of the options out there.

We are a small boutique without a storefront and we want to keep things as lightweight as possible--while maintaining a professional and aesthetically customized cart solution...
posted by pinto at 11:12 AM on April 8, 2008

http://shopify.com
posted by jdgdotnet at 11:13 AM on April 8, 2008 [1 favorite]

Zen Cart won't work for you?
posted by crios at 12:03 PM on April 8, 2008

Never mind. I see what you're trying to do, with Zen Cart you would have to rebuild the site.
posted by crios at 12:06 PM on April 8, 2008

Payment processors generally work in one of two ways (many will offer both as options...):
The easiest one to setup, is where the customer submits a form on your site where the 'action' points at the payment processor. Through (generally) hidden form fields, you pass your account-id, the amount, an order number and any number of other things that they might want. Once the customer gets to the payment processor, they're asked for their card details, and the transaction happens (or doesn't happen...). One of the items you can send with your form will be a callback url, that the payment processor will POST to with the status of the order - normally with a hash that lets you verify it's actually them, and not just a hacker. This callback would then let you know (email, update a database, etc.) that there's been an order. From a purely technical point of view, there's no reason why you'd need an SSL certificate for this method, card details never go between the browser and your server. However (and this is a biggie) a lot of people assume that a padlock on the page they're viewing means that submitting things on that page is secure and inversely, that a lack of padlock means no security.
The other method involves the customer filling in a form on your site, that posts to your site, that includes their card details. You then, with some code on your server, make the POST to the payment processor's API (that is often XML-based, rather than a simple POST), and handle the response immediately. This will require an SSL certificate for your site, as credit-card details will be moving between the user and you.
The first way requires less coding, but the second will be more seamless to a customer. Some processors might only offer the 2nd option to merchants with a certain number of transactions per month, so check that.
posted by gregjones at 3:23 PM on April 8, 2008 [1 favorite]

You'll probably want to use outsourced/third-party payment processing. You can set up a shopping cart on your own site, but you'll probably have to re-do your products to serve them through a shopping cart UNLESS you get a highly customized programming solution.

There are some remotely-hosted shopping carts that say they will work wtih your own pre-existing web pages (I think), but I'm not sure I'd recommend these. There are a lot of things that make just using dynamically-generated (i.e. from the shopping cart software) pages good - ability to show the current cart contents, ability to work without having cookies enabled, ability to hae a "checkout" button appear only if there is something in the cart -- you may regard these as luxuries, but there may be other features I'm not listing that you'd want (even if you haven't thought of them yet, or if you don't see the need right now)... just a thought.

I did make a shopping cart once for a client that worked with his current pages (frames were involved... it was quite a thing, involved multiple scanned catalog pages), but it was highly custom and not very nice. Worked, though.
posted by amtho at 5:57 PM on April 8, 2008