If you're starting up a business, you probably don't have time to learn all you need to know to do this for yourself. The ideal solution would be to hire someone who's done it well before. Several times. That would be expensive, so next best is a properly built commodity script.

A canned script would not be bad for being written by someone else, but there are lots of bad scripts out there. I can't make a recommendation among those now available, but I can suggest some things to look for.

1. Runs under strict and warnings. That guards against a swarm of elementary errors.
2. Runs in taint mode. A simple precaution against some unsafe practices.
3. Uses perl core and CPAN modules instead of rolling its own routines for common needs. CGI, DBI, File::Basename, LWP and more are often displaced but rarely replaced. Hand-rolling is the mark of an amateur coder. He'll make other mistakes you may not see in time.
4. Checks for errors and reacts correctly after each trip to the system - open, close, DBI calls, all of it. That is another mark of careful attention to quality.
5. Make sure that all modifiable files are correctly locked in use. That prevents expensive errors and loss of data.
6. Similarly, look out for race conditions in creating temporary files names.
7. Look with caution at all email usage. Beware open relays and other weaknesses. Designers love open relays and never really believe in the damage they do.
8. See that logins, credit card transactions, and so on are always conducted over the https protocol.
9. Check that good advantage is taken of server facilities for authentication and other access control. suExec is valuable for allowing best use of unix file permissions.
10. Doesn't store passwords, stores cryptographic digests of them.

That list is not complete by any means, but it will give you a basis for judging the quality of a script. Sorry I couldn't make a recommendation, but I'm sure you'll get plenty of advice from the other monks.

I wouldn't recommend that. There is currently no one using Maypole for actual commerce, and the examples in the article are highly over-simplified. You'd be better off using an actual commerce package like Interchange, even though it has a lot of questionable design issues.

good luck.

True, on the surface, Yahoo has a good solution. However, they do not allow for much flexibility and the system can be difficult to work with if you have a complicated product line with lots of sizes, colors, options, etc. We tried like crazy to make it work, but had to abandon Yahoo for other solutions that allowed us more control (Perl, MySQL, etc.) Again, if your product line is kept simple, Yahoo solves lots of expensive problems with a minimum of hassle. My 2 cents.

—Brad
"Don't ever take a fence down until you know the reason it was put up. " G. K. Chesterton

True it can be difficult in some aspects (though you can get around almost everything with enough know-how and effort) but there are a couple of counter points. You could just link to the cart and host it elsewhere and also, they have a new system (StoreTags) that is just tagged based so you can design your site with any tool you want.


-Lee

"To be civilized is to deny one's nature."

Right now I'm impressed with OScommerce, although it is written in PHP and MySQL. I would recommend that you take a look at it as well.

If you really want to jump into rolling your own, you may want to contact this fellow from the CGI::Application list, who is also working on a new Perl-based. e-commerce system now.

I would be prepared to spend at least 30-50 hours of development time if you go this route.