Welcome to the MacNN Forums.

Hi guys,

Anyone expert in mySQL databases? A friend of mine, he is got a small company database in mySQL, he is got his own server and wants to create a ishop. That would mean to get the inventory forms into html and build a shop, i.e. amazon.

I have never done this, but I want to be somehow involved (if he hires someone) just to learn about it? But if anybody knows about resources (besides the mySQL web site), those will be highly appreciated. All the best and enjoy the weekend.

Why reinvent the wheel, just use one of the open source alternatives. Most will be much easier to setup and configure then trying to program a new site in php. Creating something from the ground up and having it looked polished will take time and $$$ where as there are many products already out there.

Then there's the security aspect since you're dealing with finances, you want to be careful to not leave any areas open that could be leveraged by a hacker. This again points to a canned solution where these things were (should have been) addressed.

Just my $.02

I've created shopping cart systems using MySQL and PHP, so perhaps I can be of help?

The problem with MacOSNerd's suggestion is that it is very hard to find a just-add-water store solution that addresses the special needs of your business, and provides room to grow. If you are not familiar with PHP, hacking in new features to an existing code base can be very difficult. Additionally, if you do find down the road that you need a feature not offered by your store software, essentially hitting the wall can be very burdensome on business - you're basically back at square one!

For example, if you offer coupon codes, sales that are triggered when certain criteria are met (e.g. 15% when you buy x or y or z), want to include support for your custom payment processor, etc. it can be difficult finding a product that matches your needs perfectly without introducing a lot of overhead and complexity with features you do not need. This is an argument for building something yourself.

As far as the security aspect, as long as you abide by the clearly laid out credit card processing guidelines (there is a four letter acronym for these which I can't remember right now), you will be legally protected. One of these stipulations is not saving anything beyond the last 4 digits of the credit card, and no CVV2 codes. Without having to store credit card data and simply redirecting to another payment processor (be it PayPal or your own CC processor), there really is no major risk involved - all you are doing is providing a means for the customer to select the products they want and logging these transactions minus CC/payment info.

This area is actually something I've spent a lot of time with, I'm happy to answer any specific questions you may have and/or direct you to some of the stores I've done.

So you're advocating building something from the ground up when the OP and/or his friend sound like they've had little or no experience in such development.

That's a risky move, you want to put your best foot forward and spend your time and resources well. The risk compromising credit card transactions cannot overstated.

Personally speaking if I have little expereince in developing in PHP, I'm not about to build an application that can process credit card transactions, there's too many variable that I won't know about and may not even know enough to ask the right question.

To put it this way, I'd rather not pit my inexperience against an experienced hacker and to be honest, I'm sure the customers that come that way don't want that as well since its there financial well being we're taking about.

A canned approach is a much faster way to implement what the OP is looking for and typically more bullet proof while providing some flexibility like processing coupon codes and such.

I may not be an expert in this matter but I can use common sense to see that the OP needs to be very careful in setting up a site that not only looks good, runs fast but also is well protected against intrusions.

A basic shopping cart system is pretty easy

Like I said, he would either be directing people to another secure site for CC processing (common, more likely here), or else communicating via the payment processor API on the backend and not retaining CC information. If you do this properly, there is nothing to be afraid of. The former technique is the same way that payments are processed with PayPal, and hundreds/thousands of sites direct payment to PayPal every day.

You are making a mountain out of a molehill based on your exposure to credit card identity theft FUD. Yes, there is a risk, but there is also a very clear spec defined for how these transactions should work in processing payment in house. If you follow this, not only will you have a functioning site, but you will also be afforded legal protection.

However, my recommendation would be to outsource the payment processing to a dedicated payment processor such as PayPal or your own merchant account. In doing so, this takes all of these sorts of technical considerations, worries, etc. completely out of the picture, leaving you with nothing more than the responsibility of having to develop a front end, and directing people to the payment processor site at the end for the customer to complete his/her order.