Storing credit card information

  • Hi,

    We are planning to implement credit card payment from our site, instead of redirecting the user to a third party website. Any suggestions for storing credit card information in our own database, with regard to security? One article has suggested creating a seperate database, username and login for storing just the cc information. Is this a overkill or a must?

    Thanks.

  • Rumor has it that there are some very stiff penalties for storing unencrypted credit card information and other seemingly minor infractions on safeguards.  I would say there's no such thing as "overkill" when it comes to credit card, bank account, Social Security, and other personal information.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Best advice I can offer is to palm off the payment handling to one of the few websites that are already setup for this.

    If you have to take the headache on board,

    1. Always store credit card related details encrypted.

    2. Handle encryption/decryption client-side, never transmit un-encrypted details across the wire. I once had to explain to a friend why his approach of accepting the details from his web page in plain text and then encrypting them on the web server before sending to the database was not a good idea.

    3. Always store credit card related details encrypted.

    4. Store credit card details seperate from the rest of the system

    5. Always store credit card related details encrypted.

    6. Never associate stored credit card details with stored customer details, and never allow them to be associated in something like a report etc...

    7. Always capture a data element that must be entered via human intervention. eg: something like the Captcha image used in Blogs to avoid comment spam.

    Oh and in case I haven't mentioned it, always store credit card related details encrypted.

     

    --------------------
    Colt 45 - the original point and click interface

  • Hi,

    You said 'Handle encryption/decryption client-side'. You mean using javascript? Can you please explain on how to do this?

    Thanks.

  • Here's a link that shows a user-defined function that will encrypt any string using a simple algorithm:

    http://www.sql-server-helper.com/functions/string-encryption.aspx

    I emphasize on the word "simple" because if you look at the algorithm used, it's easy to decipher.  Your best option still will be to encrypt it using other softwares/applications.

    Here's another link to a software that you can use:

    http://www.xpcrypt.com

  • I would like to warn you about some pointers about encryption of data.

    If you use asymetric encription your encripted data will be useless for joins, group by, sorting and indexing!

    You will need to come up with some sort of hash to perform searches. 

    You can do stuff client side like ( Yahoo email does  on javascript) but SSL is a must when financial information is involved

    The encryption keys must be guarded by non DBA and probaly third party.

    be ready to encrypt the bakups before they go to tape

    And last but not least: Good luck!

     


    * Noel

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply