Sean Lange (10/3/2012)
These three payment methods have different data requirements:
1. Checks only need Payment Amount and Check Number (for our requirements).
2. ACH transactions only need Bank Name, Routing Number and Account Number.
3. Credit Cards need CC#, Expiration Date, Name on Card, CSC, Billing Address
You need to be EXTREMELY careful here. You have some serious issues going on here specifically with credit cards. DO NOT store CC# unless you are very certain your encryption is secure. You need to be PCI compliant for processing electronic credit card transactions. Your structures are in direct conflict with compliance. You are saying you are going to store the CSC. The whole point of that number is for protection with electronic transactions. It is used as secondary check to ensure that the card is present during the transaction. How certain are you that your data is encrypted during transit AND at rest? You are storing credit card data and bank account numbers. DO NOT take this lightly. The fines and penalties for mishandling this type of stuff can be staggering.
Thanks, I will definitely look into this. I have been concerned with this requirement to store CC data, myself. As it is, the application is an intranet-only application, not available outside the LAN. It uses SSL over our IPSEC infrastructure and the application applies triple-DES encryption to the data before it is stored in our database. I'm the paranoid sort, so I have planned to encrypt that encrypted input using column encryption. This storage is strictly temporary and used ONLY as a means to transport the CC info from the data entry users to the accounting users who will actually enter the CC data into the CC processing software from our bank (we get very few CC payments--currently less than 2%). Once the data has been entered into the CC processing software, it is removed from the Credit Card table.
Hopefully that covers me but I will definitely scrutinize those regulations. Thanks for the heads up