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

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

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服务器的访问限制为一组有限的授权用户。

其他回答

我想补充一个非技术的评论,你可能会想一下

我的几个客户经营着电子商务网站,其中包括一对拥有中等规模商店的夫妇。这两者,虽然他们当然可以实现支付网关,但他们选择不,他们获取cc号,将其临时加密在线存储,并手动处理。

他们这样做是因为欺诈的高发率和人工处理允许他们在填写订单之前进行额外的检查。我被告知他们拒绝了20%多一点的交易——手工处理当然需要额外的时间,在一个案例中,他们有一个员工除了处理交易什么都不做,但如果他们只是通过在线网关传递抄送号码,支付他的工资的成本显然比他们的风险要小。

这两个客户端都提供具有转售价值的实物商品,因此特别容易暴露,对于像软件这样的产品,欺诈性销售不会导致任何实际损失,但如果您真的想要实现在线网关,则值得考虑在线网关的技术方面。

编辑:既然给出了这个答案,我想加上一个警世故事,说这是一个好主意的时代已经过去了。

为什么?因为我知道另一个线人也在用类似的方法。信用卡的详细信息被加密存储,网站通过SSL访问,处理后立即删除号码。你觉得安全吗?

他们的网络上没有一台机器受到密钥日志木马的感染。结果,他们被认定为几张伪造分数信用卡的来源,并因此受到了巨额罚款。

因此,我现在从不建议任何人自己处理信用卡。自那以后,支付网关变得更具竞争力和成本效益,欺诈措施也得到了改进。现在冒险已经不值得了。

我可以删除这个答案,但我认为最好还是编辑一下,作为一个警世故事。

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可能需要巨额的外部审计费用和内部努力/支持。此外,要注意可能单方面对你征收的罚款/处罚,通常与“违法行为”的规模不成比例。

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

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

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

Keep in mind that using SSL to send a card number from a browser to a server is like covering your credit card number with your thumb when you hand your card to a cashier in a restaurant: your thumb (SSL) prevents other customers in the restaurant (the Net) from seeing the card, but once the card is in the hands of the cashier (a web server) the card is no longer protected by the SSL exchange, and the cashier could be doing anything with that card. Access to a saved card number can only be stopped by the security on the web server. Ie, most card thefts on the net aren't done during transmission, they're done by breaking through poor server security and stealing databases.