Storing Credit Card Data
-
Greetings,
I am working on a new database and application with SQL Server. I have to keep my customers credit card info on file. Is it worth the extra work to create a seperate table for the credit card information and link via a companyid field? Or should I just include the credit card info in the customer table?
Thanks in advance!
-
What business rule should the design support? Can the customer only have one credit card?
Without the business rules and the data, it's tough to guess whether any particular design is correct.
And then again, I might be wrong ...
David Webb -
I apologize, I neglected to mention that. There is really no need for a customer to have more than one CC on file. The reason I was thinking of a seperate table was to make it more secure.
Thanks.
-
Hmmm, the only thing another table might give you is more granular security, but you can accomplish the same effect by insulating direct access to the underlying table through views. One view for folks who can see the cc info, one for folks who can't, and no access for anyone to the underlying table.
And then again, I might be wrong ...
David Webb -
Yeah, I suppose you are correct. no sense in making extra joins if I don't have to.
Thanks.
-
I have had a bit of experience with CC databases in the past (although the company it was with was quite dodgy to its customers - am glad I left before they went south!). Anyhow...
M'Card & VISA (and I assume others) have some fairly strict guidelines on the storage of CCs in databases, particular with web ones. Like another post from someone else tonight who was storing SSNs, you should ALWAYS encrypt the credit card number in the database. When you need to, you can decrypt the credit card in the client side code (eg, the web server code). If you need to search for a particular CC (CC's are the kind of things you do a range search on fortunately), you encrypt the search value and attempt to match the encrypted value to the encrypted value stored in the DB table.
That way, if someone gets your database, they still can't read the CCs. Finally, on a related note, I am also aware that different countries / banks have different rules if you can store the CSV numbers or not - might be worth looking in to.
-
I would agree with the poster who said to encrypt the data. There are a plethora of good encryption algorithms, most free, that you can use to do the job. I would take it a step further, though, I would keep the information in an isolated database that is accessable by one single machine, that holds the WebServices code that can actually interact with the database. If your application MUST use the internet, then you should implement 128 bit ssl security on the server, and the server should then do the decryption (to authenticated users). I would NOT rely on Microsoft SQL to handle the security ( though I am sure that it is probably decent at doing that). Use a separate authentication scheme, one either pre developed for you, or you yourself had developed, and only provide the credit card information to certain users, over a ssl line. While stored in the database, you could use some sort of public private key encryption, though I am concerned that using such a scheme, without imbedding the key in the source, or hidden on the HDD somewhere might pose a decent risk on its own.
Good luck
Aleksei
-
One further thought on the need to store CC information in the customer record. Do all customers have Credit Cards? If not, it would be appropriate to put CC information in its own table.
Steve
-
Good question. All customers do NOT have credit cards. Some pay by other means.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply