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.