这个问题讨论了不同的支付处理器和它们的成本,但我想知道如果我想接受信用卡支付,我需要做什么?

假设我需要为客户存储信用卡号码,因此依赖信用卡处理器来完成繁重工作的明显解决方案是不可用的。

PCI数据安全,这显然是存储信用卡信息的标准,有一堆一般的要求,但如何实现它们呢?

像Visa这样有自己最佳实践的供应商呢?

我需要用钥匙卡进入机器吗?那保护它不被大楼里的黑客入侵呢?甚至如果有人拿到了包含sql server数据文件的备份文件呢?

备份呢?周围还有其他数据的物理副本吗?

Tip: If you get a merchant account, you should negotiate that they charge you "interchange-plus" instead of tiered pricing. With tiered pricing, they will charge you different rates based on what type of Visa/MC is used -- ie. they charge you more for cards with big rewards attached to them. Interchange plus billing means you only pay the processor what Visa/MC charges them, plus a flat fee. (Amex and Discover charge their own rates directly to merchants, so this doesn't apply to those cards. You'll find Amex rates to be in the 3% range and Discover could be as low as 1%. Visa/MC is in the 2% range). This service is supposed to do the negotiation for you (I haven't used it, this is not an ad, and I'm not affiliated with the website, but this service is greatly needed.)

这篇博文给出了一个完整的处理信用卡的纲要(特别是在英国)。


也许我问错了问题,但我在寻找这样的建议:

使用SecurID或eToken为物理盒添加额外的密码层。 确保盒子在一个有物理锁或键码组合的房间里。


当前回答

PCI 1.2文档刚刚发布。它给出了一个如何实现PCI合规性和需求的过程。你可以在这里找到完整的文档:

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

长话短说,为专门存储CC信息的服务器(通常是DB服务器)创建一个单独的网段。尽可能地隔离数据,并确保只存在访问数据所需的最小访问权限。存储时加密。不要存储PAN。清除旧数据并旋转加密密钥。

不该做的事:

不要让可以在数据库中查找一般信息的同一个帐户查找CC信息。 不要把你的CC数据库和你的web服务器放在同一个物理服务器上。 不要允许外部(Internet)流量进入CC数据库网段。

Dos示例:

使用单独的数据库帐户查询CC信息。 禁止通过防火墙/access-lists访问CC数据库服务器 将CC服务器的访问限制为一组有限的授权用户。

其他回答

问自己以下问题:为什么要存储信用卡号码?很可能你不知道。事实上,如果你确实储存了它们,并设法偷了一个,你可能会面临一些严重的责任。

我写了一个存储信用卡号码的应用程序(因为交易是离线处理的)。这里有一个好方法:

Get an SSL certificate! Create a form to get CC# from the user. Encrypt part (not all!) of the CC# and store it in your database. (I'd suggest the middle 8 digits.) Use a strong encryption method and a secret key. Mail the remainder of the CC# to whoever processes your transactions (probably yourself) with the ID of the person to process. When you log in later, you will type in the ID and the mailed-out portion of the CC#. Your system can decrypt the other portion and recombine to get the full number so you can process the transaction. Finally, delete the online record. My paranoid solution was to overwrite the record with random data before deletion, to remove the possibility of an undelete.

这听起来工作量很大,但由于从未在任何地方记录完整的CC#,黑客很难在你的web服务器上找到任何有价值的东西。相信我,这值得你安心。

整个过程有很多。最简单的方法是使用类似paypal的服务,这样你就不会实际处理任何信用卡数据。除此之外,要获得批准在你的网站上提供信用卡服务,还有很多事情要做。你可能应该和你的银行谈谈,以及给你发商户ID的人帮助你设置这个过程。

一定要了解PCI所需的额外工作和预算。PCI可能需要巨额的外部审计费用和内部努力/支持。此外,要注意可能单方面对你征收的罚款/处罚,通常与“违法行为”的规模不成比例。

PCI 1.2文档刚刚发布。它给出了一个如何实现PCI合规性和需求的过程。你可以在这里找到完整的文档:

https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml

长话短说,为专门存储CC信息的服务器(通常是DB服务器)创建一个单独的网段。尽可能地隔离数据,并确保只存在访问数据所需的最小访问权限。存储时加密。不要存储PAN。清除旧数据并旋转加密密钥。

不该做的事:

不要让可以在数据库中查找一般信息的同一个帐户查找CC信息。 不要把你的CC数据库和你的web服务器放在同一个物理服务器上。 不要允许外部(Internet)流量进入CC数据库网段。

Dos示例:

使用单独的数据库帐户查询CC信息。 禁止通过防火墙/access-lists访问CC数据库服务器 将CC服务器的访问限制为一组有限的授权用户。

为什么要为PCI遵从性而烦恼??你最多可以省下百分之一的手续费。在这种情况下,你必须确保这是你想要在开发初期和随着时间的推移跟上最新需求的时间所做的事情。

在我们的例子中,使用订阅保存网关并将其与商家帐户配对是最有意义的。订阅保存网关允许您跳过所有PCI合规性,只做适当的事务处理。

我们使用TrustCommerce作为我们的门户,并对他们的服务/定价感到满意。他们有很多语言的代码,使得集成非常容易。