Collecting Credit Card Information - not to collect payment

Question

I am working in PHP on a Linux server with MySQL.

I have a requirement (that I have attempted to talk them out of) to collect credit card information from users so tha

Answer 1

First of, I am not a lawyer. I have implemented CC-handling code several times previously, but I am only familiar with Danish laws and regulations, so your mileage may vary.

As far as I know, there are restrictions in place (law and regulations from the CC providers) that you need to be aware of. I don't know where you are in the world, but in many countries you need to be PCI certified to handle credit card data and that is an extremely onerous, expensive and on-going process.

Other countries, or states, may have notification rules in play that requires you to pay the cost of notifying the card holder if security is broken - and unless you are very careful, it is not unlikely.

In general, I would recommend against that procedure. You may risk being liable for any costs if it goes wrong.

Answer 2

This is very insecure and I think you're correct for opposing it. That said...

Some ideas:

• Can the hotel give you a rate/group code that you can disseminate to your users directly? Perhaps you could even give them a link that goes right to the hotel's reservation page, with the code already filled in.

• Don't even think about implementing this unless you can do it on an SSL-enabled site.

• Don't save the CC number anywhere, just generate the email and toss the number out. This alleviates you from having to worry about a ton of very difficult application / server security issues.

• Encrypt the email with GPG or equivalent so that it's protected in transit and can only be read by the intended recipient.

Answer 3

As someone who has worked on a system like this, it is 100% illegal to store any credit card information in plain text. You must encrypt all of the data and you are not allowed to know any piece of the keys. It is quite the catch 22, the only way to validate data is to guess as sad as that sounds. This is the exact reason why accidental charges occur.

Answer 4

It's really a bad idea to be storing card details. You're opening yourself up for a world of pain in the form of PCI-DSS audits. It is not as simple as 'use encryption', you need to have processes in place to securely manage the encryption keys, schedule key rotation, securely log access and so on and on... Storing card details is absolutely something you want to avoid.

If you have to have something in place, then the best option may be for you (as a company) to take payments from the credit cards to your own merchant account, then pay the hotels separately (from your bank account/whatever). You act as a proxy for the client making the payment to the hotel.

Most payment gateways allow you to store the card details securely, and charge at a later date (using a token id returned by the gateway), which will likely be useful here. But you wont be able to retrieve the card details to pass them through to the hotel in any way, which is why you would need to take payment, then organise a separate payment to the hotel.

Its still quite an undertaking though because a lot of areas of PCI-DSS will come into play even with this simplified solution.

You asked, so here is more information:

PCI-DSS is the Payment Card Industry Data Security Standard. It's a set of guidelines which basically apply to any company that 'touches' cardholder data, in particular the card number. Touching it literally means any handling of the data, even just having it pass through your network without it ever being persisted to disk is enough to mandate that you must comply, (though it is significantly easier if you don't persist the details to disk)

You didn't yet state which part of the world you're in, or how these card details are captured (internet/telephone/in person). These details are significant to how you can achieve compliance.

Start by taking a look at the PCI-DSS SAQ (Self Assessment Questionnaires). These SAQ's are the minimum requirements for companies that do not store cardholder details to disk, and should give a good impression of the security that needs to be in place across the network and policies that should be applied across the company.

As I said, if you're thinking of storing card details then things get more complicated, because as a general rule the SAQ is no longer good enough. You need to enrol the assistance of a QSA (Qualified Security Assessor) who will visit and advise on best practice for data storage and the various other points that come into play. For this level of compliance you're looking at yearly audits (carried out by the QSA), and quarterly network scans. Take a look at the audit procedures to get a detailed look at what is involved. In particular take a look at section 3 and do not underestimate the difficulty of implementing proper key management.

In summary, full PCI compliance will be very costly. Even for a company which already has pretty strong security policies the cost of bringing in a QSA and running quarterly scans and yearly audits alone will likely cost $thousands.

Answer 5

If you send the file via email, be sure to use secured connexions (HTTPS / IMAP or POP3 over SSL, SMTP over SSL) on both sending and receiving computers and have the file encrypted prior sending. You can encrypt your mail and attachment via OpenPGP, too. Also, ensure the security between the two mail servers (sending and receiving), or simply use the same domain for sending and receiving email addresses. Do not use the password-feature of a ZIP file or related comrpessing container, since they are usually cryptographically weak. If you send it on a filesystem (ie. USB pendrive), be sure to use a crypted one (ie. TrueCrypt).

Be sure to have a secured computer where the download and upload takes part (encrypted partition where the download/upload takes place, no spywares on the system, passworded system, firewalled).

Answer 6

I suggest you follow the Card Industry PCI compliance closely at least. Here is a PDF document.