| 5:24 pm on Aug 6, 2008 (gmt 0)|
Yes, you forgot something very important.
Apart from sending the data securely from php to the mysql server, you should store the data in an encrypted fashion in the DB. Otherwise, if someone gets access to the DB, the data is right there in user-friendly text format :(
| 5:32 pm on Aug 6, 2008 (gmt 0)|
sven is right - the stuff needs to be kept encrypted in the database - you need to checkout mysql crypto features. Another issue however would be the fact that you'd need to store somewhere crypto keys and you therefore can't really have plain text PHP files with keys stored in them.
It's all a major hassle to deal with credit cards, much better to "outsource" it to Paypal, most users would probably convert better when they see well known payment provider rather than small lesser known site that wants their credit card.
[edited by: Lord_Majestic at 5:41 pm (utc) on Aug. 6, 2008]
| 5:55 pm on Aug 6, 2008 (gmt 0)|
Yes I mirror Majestic's advise.
I was going to mention it before but I saw you already tried talking them out of it.
Honestly, you can encrypt all day and all it takes is one dishonest employee, or unscrupulous cleaning crew member, or even an ignorant user that invites a virus onto your network to undo all your efforts.
| 6:12 pm on Aug 6, 2008 (gmt 0)|
Welcome aboard Lord_Webby.
Is your website and host PCI compliant [pubcon.com]?
This should be your FIRST stop. Have your clients read their contract: if they are using an in-store terminal to process CC info, their contract will explicitly disallow collection of credit card orders by any other means than card present or phone orders. Internet orders are a completely different contract with different fee structures.
Merchant accounts that allow collection and processing of credit cards via the numbers you describe will DEMAND PCI compliance. This involves not only your programming but the security of the network and hardware systems on which you do this, see the link above.
This is a BIG DEAL. If caught, the client will have to pay enormous fines and will be liable for all charges in arrears for the time they are operating in an non-PCI compliant environment.
If they forge onward with this, it's your job to make sure they are informed and you need it in a contract waiving you from responsibility - if it all comes down, you'll be the one they try to blame.
Last I'll throw in - I have *NEVER* encountered a project that REQUIRES storage of CC info. Subscription based, recurring billing, account credit and management, whatever the scenario - there is always a way to do it via a reputable credit card processor, which releases you from a PCI compliance audit. If one doesn't have what you need, another will. So there's "always a way" - if the client refuses to see it out of convenience or a tight purse, that is their decision to make. Just make sure you're covered.
Recent discussion [webmasterworld.com]
| 8:06 am on Aug 7, 2008 (gmt 0)|
The system is for a company that claims back credit card charges. Users enter personal information and add credit card details so that the company can claim back the credit card charges. Therefore they need to store the details but users never need to access the system again (hence no login information). I was thinking of only giving the website 'write' permissions. The data can then be accessed internally only - by staff (who Will have to login to access the data). I was going to restrict access to the internal website by only allowing internal IP addresses (192.168.*.*).
I've read that amazon use a seperate server connected via a serial port because it is easy to analyse the data being passed through and check why it is being accessed. Anyone know how you would check the information being passed through the serial port?
I believe the servers will be behind a sonicwall hardware firewall.
I should also add that there are no actual transactions taking place. All transactions are delt with offline. The system just needs to be secure to hold the personal and credit card data.
I have a 256bit encryption alogithm for storing details. I was going to use sourceGuardian or similar to encode the key and php files (probably pre-encrypt the key first as well).
I will read up on PCI compliance thanks.
| 6:13 pm on Aug 7, 2008 (gmt 0)|
You should definetely look at the 12 security requirements of PCI DSS if you intend to process payments, its not actually very difficult to comply.
Now if you *store* the CC details you could actually be breaking the law (in the UK), check out the 8 principles of data protection and see if you can still justify storing cc details.
| 7:48 am on Aug 8, 2008 (gmt 0)|
We arent actually processing any payments. Just storing the credit card number (no other details from the card). We are going to use a PCI compliant host.
Does anyone know how you would use a serial console for checking transmitted data's validity? I've been advised amazon does this.