Accepting credit card payments

[loughderg]

Hi everyone,

I'm setting up a website for a friend who wants to be able to accept credit card payments online. This is to be hosted at p-z.

Rather than process the payments automatically, he wants the credit card details to be sent to an email address of his choosing. He then wants to be able to take the card details from the email and process the payment manually through the office card terminal.

I'd appreciate some advice on how to make the process as secure as possible (bearing in mind he's on a tight budget).

I've ordered a dedicated IP address to obtain a SSL cert, but appreciate that this will only encrypt the data from the browser to the server. The form data from the website is currently set up to be sent to an email address using a simple php script.

I'd appreciate some help with the following:

1. What pages do I need to make secure, i.e. do the form, submission confirmation and php script pages all need to be https?
2. Is the php script I have in place (web4future's Easiest Form2Mail) sufficiently secure for the taks of processing the submitted form, or should I be using something better?
3. What safeguards should I put in place at server level to make sure the data held there remains secure.
4. What is the best (and cheapest) way for my friend to retrieve the credit card data from the e-mail server?

You can probably guess from the above basic questions that I'm a novice at this whole thing, so I'd appreciate it if you could use basic layman's terms in your replies (so no parsing, arrays or parameters thanks )

I'd greatly appreciate any advice you may be able to give.

Many thanks,

William

[midwest]

I see that you have not recieved an answer so I'll give it a shot.

1. My preference is to do the whole site https

2. cant say for sure if it is secure...but at the least you should rename it so it does not have "mail" in the name. If there is a hole you can be sure that it(form2mail) will become a hot search term.

3. If I was to store CC#'s I would encrypt them with DES. Dont forget to validate with the Luhn formula(mod 10) first. You should also consider encrypting ~all~ customer data.

4. With an email client, driving to the server everyday would get bothersome
I would encrypt it with pgp or similar, this however may be beyond you and your client. No offense intended but it is not the easiest thing to do if unfamiliar with it. The best alternative is to split the CC# in two parts and send each part in a different email. For added security with this method you may wish to send each part to a different email address. Do not use IMAP-do not leave the mail on the server.

You say you are not experienced, this is not the thing to gain experience on, the repercussions are enormous. Hire it out or buy a canned solution. Just MHO.

a note of caution: unless your client has a very good (personal) relation with their bank it might be better to obtain a seperate merchant account for the online activity. That way if problems develop or they get slammed with too amny chargebacks they do not loose their brick&morter merchant account too.

HTH

[stratplan]

In these days of rampant Identity Theft, phishing, and other financial criminal activities, you (and your client) would best be served with a professional application.

It's been my experience that banks are not enthusiastic about on-line credit card entries and transactions where the card is not presented/swiped. They will charge out the kazoo for the account setup and then punish the account holder for any chargebacks. I would go the route of a third-party collector - a google search will turn up quite a few.

Bottom line: If you don't like swimming with sharks, don't go in this pond unprotected.

[loughderg]

Thanks for both of your replies.

I've discussed the security issue further with my friend and I think I've talked him round to using a 3rd party as stratplan suggested.

Best regards,

William