Convince the company not to store credit card numbers in our webapp
The company I work for needs a system to perform monthly credit card charges to customer accounts. Customers will be able to update their credit card information from an online interface written in PHP (which will be presented through HTTP over SSL). The monthly charges will be run manually through a password-protected admin area of the same interface, which will basically amount to a batch call to Authorize.Net's API.
My coworkers want to store the (encrypted) credit card information in a MySQL database. They plan to encrypt the credit card numbers with PHP's mcrypt extension. presumably using Rijndael/AES or Twofish. The subject of key management was glossed over, but the following two options were mentioned:
storing keys in the database, with a separate key for each credit card entry; or
storing a single encryption key for all credit card entries in a PHP file as a variable (similar to how PHP applications such as WordPress and MediaWiki store database credentials).
How can I convince them not to go this route? We will be using Authorize.net for payment processing, so I mentioned their Customer Information Manager service as an alternative to storing credit card information ourselves. However, I don't know the subject
well enough to make a compelling argument (my arguments were "none of us are security experts" and "I wouldn't feel comfortable with a company storing my credit card information in this manner").
If I am unable to convince them to use a 3rd party service like Customer Information Manager. what should I keep in mind in order to keep customers' credit card information safe? In particular, how should I manage encryption keys? Should there be a separate encryption key for each customer entry? Where can I store the keys so I can decrypt the credit card information before sending the transactions over to Authorize.Net? The two options mentioned above don't seem very sound to me (but again, I don't know the subject well enough to make a compelling argument against either).
Update. I found someone in the company familiar with PCI DSS compliance, so I'm working with him to make sure this gets done right. However, I would still appreciate answers to my questions above (both to improve my knowledge and to help others in a similar situation).
Update 2. Success! Another developer sat down and read the PCI DSS guideline and decided that it's a bad idea to store the information ourselves after all. We will be using Authorize.Net's Customer Information Manager service.