我工作的公司需要一个系统来每月向客户账户收取信用卡费用。客户将能够从用 PHP 编写的在线界面（将通过基于 SSL 的 HTTP 呈现）更新他们的信用卡信息。每月费用将通过同一界面的受密码保护的管理区域手动运行，这基本上相当于对 Authorize.Net 的 API 的批量调用。
我的同事想将（加密的）信用卡信息存储在 MySQL 数据库中。他们计划使用PHP 的 mcrypt 扩展加密信用卡号，大概使用 Rijndael/AES 或 Twofish。密钥管理的主题被掩盖了，但提到了以下两个选项：
将密钥存储在数据库中，每个信用卡条目都有一个单独的密钥；或者
将 PHP 文件中所有信用卡条目的单个加密密钥存储为变量（类似于 WordPress 和 MediaWiki 等 PHP 应用程序存储数据库凭据的方式）。
我怎样才能说服他们不要走这条路？我们将使用Authorize.net进行支付处理，所以我提到了他们的客户信息管理器服务作为我们自己存储信用卡信息的替代方案。但是，我对这个主题的了解不足以提出令人信服的论点（我的论点是“我们都不是安全专家”和“我对一家公司以这种方式存储我的信用卡信息感到不舒服”）。
如果我无法说服他们使用像Customer Information Manager这样的第 3 方服务，为了保证客户的信用卡信息安全，我应该记住什么？特别是，我应该如何管理加密密钥？每个客户条目是否应该有一个单独的加密密钥？我可以在哪里存储密钥，以便在将交易发送到 Authorize.Net 之前解密信用卡信息？上面提到的两个选项对我来说似乎不是很合理（但同样，我不太了解这个主题，无法对任何一个提出令人信服的论点）。
更新：我在公司找到了熟悉 PCI DSS 合规性的人，所以我正在与他合作以确保正确完成这项工作。但是，我仍然希望回答我的上述问题（既可以提高我的知识，也可以帮助处于类似情况的其他人）。
更新 2：成功！另一位开发人员坐下来阅读 PCI DSS 指南，并认为自己存储信息毕竟不是一个好主意。我们将使用 Authorize.Net 的客户信息管理器服务。