Credit Card Info, Where?

[mastromb]

In my database I have a payment table, but the payments can come in multiple forms (Cash, Check, Debit/Credit Cards). I want to record the specific infomation about those payments such as check number for checks. However for Debit/Credit Cards I want to keep track of the card number, CVS number, expiration date, etc.



My question though is should I create a separate table for the credit card information or should it just be part of the payment table. One reason I am leaning toward a separate table is so I can apply some security measures to that sensative information. If it is separate it would be a 1 to 1 relationship, I think.

What about the check number, should it be in a separate table as well? I have a combo box in the payment table to select the payment type.

[ajetrumpet]

to keep the data normalized, you should use fields in the same table. no other table is necessary i dont think. and you can always sensor that info out anyway. why another table to do it? you can do that anywhere!

[NTC]

if by payment table - you mean that every time you process a payment you record the credit card info with that record - - - and therefore the credit card info will be repeated in this table with each payment that is repeated (perhaps monthly) - then the credit card data should definitely be in a separate table - with just a unique ID cross referencing in the payment records.

normalized data means never repeating the same data.

[nelixtransax]

I know this is an older post, but I think it's important to note that it's very risky to store credit card information in your database in general, and if not done right, can jeopardize your PCI Compliance status.

The ideal way to handle this is to have your gateway provider store the billing details - credit card, exp date, cvv2, and you just store a token in your database. You can then use the token to access the billing information as needed in your gateway partners secure, PCI compliant, system. This type of setup removes a huge exposure from the merchant in terms of risk of breach and PCI compliance.