Alex Rivera | Logout

Storing Credit Card Numbers in SESSION - ways around it?

Asked 2010-05-24T20:43:43.730
38

I am well aware of PCI Compliance so don't need an earful about storing CC numbers (and especially CVV nums) within our company database during checkout process.

However, I want to be safe as possible when handling sensitive consumer information and am curious how to get around passing CC numbers from page to page WITHOUT using SESSION variables if at all possible.

My site is built in this way:

  1. Step 1) collect Credit Card information from customer - when customer hits submit, the information is first run through JS validation, then run through PHP validation, if all passes he moves to step 2.
  2. Step 2) Information is displayed on a review page for customer to make sure the details of their upcoming transaction are shown. Only the first 6 and last 4 of the CC are shown on this page but card type, and exp date are shwon fully. If he clicks proceed,
  3. Step 3) The information is sent to another php page which runs one last validation, sends information through secure payment gateway, and string is returned with details.
  4. Step 4) If all is good and well, the consumer information (personal, not CC) is stored in DB and redirected to a completion page. If anything is bad, he is informed and told to revisit the CC processing page to try again (max of 3 times).

Any suggestions?

EDIT

I have received a lot of really good response on this question - majority seem to agree on the following:

  1. taking POST variables after validation is run
  2. encrypting ccnum and cvv (not sure you are allowed to store cvv in DB at all though)
  3. Storing in temporary DB
  4. Access DB immediately after 'review' page is OK'd
  5. decrypt details from DB
  6. send information to processor
  7. receive response
  8. terminate DB

I think this makes sense overall. Does anybody have good method for the encryption/decryption along with best way to create temp

php mysql session credit-card
Edit
Report

2 Answers

9

I know you mentioned you're aware of PCI compliance, but using any of the methods already described (eg persisting the card number to disc anywhere) will fall foul of PCI and mean you have a nightmare of compliance headaches ahead of you. If you really insist on persisting the card number to disc, then you might as well get a PCI auditor in now to help you through the process and offer advice. Ultimately they will need to validate the method you've taken is appropriate.

As an example, a lot of the answers here talk about using encryption. Thats the easy bit. They haven't talked about key management which is significantly harder

I think therefore a better approach would be to submit the card details to the payment gateway as soon as they are collected. A good many of payment gateways will allow you to perform a 'store only' style transaction, which will perform basic validation of card details and store the card number to their (already PCI compliant) server, and return you a token id instead. This method means you DONT store the full card number/cvv2 anywhere on your servers, and PCI compliance becomes a huge amount easier.

Later in the checkout process you use the token id to submit an authorisation and settlement.

PCI allows you to store the first six/last four digits (and expiry date) of the cardnumber in plaintext, so you can safely capture those wherever you're comfortable with so that they can be redisplayed just prior to the final step.

answered 2010-05-25T08:49:38.853
3

It appears that anyway you touch it, you'll need to provide for secure credit card number storage capabilities. If the server is compromised, at any time it will contain enough information to decrypt currently stored credit card numbers (i.e. keys and encrypted numbers). Potential solution is to use an internal server that acts as a "encryptor/decryptor" service and nothing else. This way compromising one machine does not expose credit card numbers.

answered 2010-05-24T20:54:56.160

Your Answer