当您可以使用Authorize.Net 的 Customer Information Manager API并完全摆脱 PCI 合规性和安全问题并让他们为您完成所有繁重的工作时，为什么还要将其存储在 MySQL 数据库中？CIM 让您创建客户付款配置文件，方法是在客户端存储客户的信用卡信息，然后在将来需要时通过在交易时引用付款配置文件 ID 来对该配置文件收费。

您必须遵守的关键法规是支付卡行业数据安全标准 (PCI DSS)，此处特别感兴趣的是第 3.4 节 -

保护存储的持卡人数据

使用以下任何方法使 PAN 在任何存储位置（包括便携式数字媒体、备份媒体和日志中）都无法读取：

• 基于强密码学的单向哈希（哈希必须是整个 PAN）
• 截断（散列不能用于替换 PAN 的截断段）
• 索引令牌和衬垫（衬垫必须安全存放）
• 具有相关密钥管理流程和程序的强大密码学

第 3 节的其余部分也值得深入阅读！

如果您使用存储在数据库无法访问的某个位置的密钥对敏感数据使用众所周知的对称密码（例如 AES 或河豚/双鱼），它可能（请参见下面的注释）满足要求。由于结果不可打印，因此您可以对结果进行 hex 或 base64 编码以进行存储。

显然，任何进行自动加密和解密的系统本质上都没有手动系统安全，因为密钥必须直接存储在服务器上才能正常工作。但是你越能把它们分开越好。

更好的是，许多网关提供商允许您不必在服务器上存储客户卡的机制，包括 Authorize.net 的 CIM 和 Paypal 的参考交易，仅举几个例子。

注意：这不构成法律或安全建议，不应如此解释。如果您有任何问题或疑虑，您应该始终聘请当地的安全专家。