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

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

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为物理盒添加额外的密码层。 确保盒子在一个有物理锁或键码组合的房间里。


当前回答

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

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

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服务器上找到任何有价值的东西。相信我,这值得你安心。

其他回答

As others have mentioned the easiest way into this area is with the use of Paypal, Google checkout or Nochex. However if you intend to to a significant amount of business you may wish to look up "upgrading" to higher level site integrations services such as WorldPay, NetBanx (UK) or Neteller (US). All of these services are reasonably easy to set up. And I know that Netbanx offers convenient integration into some of the off the shelf shopping cart solutions such as Intershop (because I wrote some of them). Beyond that you are looking at direct integration with the banking systems (and their APAX systems) but thats hard and at that point you also need to prove to the Credit card companies that you are handling the credit card numbers securely (probably not worth considering if you are not taking $100k's worth per month).

从第一个到最后一个的成本/好处是,早期的选择更容易(更快/更便宜)设置,让你为每笔交易支付相当高的手续费。后期的设置成本要高得多,但从长远来看你付出的更少。

大多数非专用解决方案的另一个优点是,您不需要保持加密的信用卡号码的安全。那是别人的问题:-)

不久前,我在一家公司工作时经历了这个过程,我打算很快在自己的公司再经历一次。如果你有一些网络技术知识,它真的没有那么糟糕。否则,你最好使用Paypal或其他类型的服务。

The process starts by getting a merchant account setup and tied to your bank account. You may want to check with your bank, because a lot of major banks provide merchant services. You may be able to get deals, because you are already a customer of theirs, but if not, then you can shop around. If you plan on accepting Discover or American Express, those will be separate, because they provide the merchant services for their cards, no getting around this. There are other special cases also. This is an application process, be prepared.

接下来,您需要购买一个SSL证书,当信用卡信息通过公共网络传输时,您可以使用它来保护您的通信。有很多供应商,但我的经验法则是选择一个在某种程度上是品牌名称的供应商。你对他们的了解越深,你的客户对他们的了解就越深。

Next you will want to find a payment gateway to use with your site. Although this can be optional depending on how big you are, but majority of the time it won't be. You will need one. The payment gateway vendors provide a way to talk to the Internet Gateway API that you will communicate with. Most vendors provide HTTP or TCP/IP communication with their API. They will process the credit card information on your behalf. Two vendors are Authorize.Net and PayFlow Pro. The link I provide below has some more information on other vendors.

Now what? For starters there are guidelines on what your application has to adhere to for transmitting the transactions. During the process of getting everything setup, someone will look at your site or application and make sure you are adhering to the guidelines, like using SSL and that you have terms of use and policy documentation on what the information the user is giving you is used for. Don't steal this from another site. Come up with your own, hire a lawyer if you need to. Most of these things fall under the PCI Data Security link Michael provided in his question.

If you plan on storing the credit card numbers, then you better be prepared to put some security measures in place internally to protect the info. Make sure the server the information is stored on is only accessible to members who need to have access. Like any good security, you do things in layers. The more layers you put in place the better. If you want you can use key fob type security, like SecureID or eToken to protect the room the server is in. If you can't afford the key fob route, then use the two key method. Allow a person who has access to the room to sign out a key, which goes along with a key they already carry. They will need both keys to access the room. Next you protect the communication to the server with policies. My policy is that the only thing communicating to it over the network is the application and that information is encrypted. The server should not be accessible in any other form. For backups, I use truecrypt to encrypt the volumes the backups will be saved to. Anytime the data is removed or stored somewhere else, then again you use truecrypt to encrypt the volume the data is on. Basically where ever the data is, it needs to be encrypted. Make sure all processes for getting at the data carries auditing trails. use logs for access to the server room, use cameras if you can, etc... Another measure is to encrypt the credit card information in the database. This makes sure that the data can only be viewed in your application where you can enforce who sees the information.

我使用pfsense作为防火墙。我用一个小型闪存卡运行它,并设置了两个服务器。一个是冗余故障转移。

我发现了Rick Strahl的一篇博客文章,它极大地帮助我理解电子商务,以及通过web应用程序接受信用卡。

这是一个很长的答案。我希望这些建议能有所帮助。

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

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

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

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

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

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

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

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

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

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.

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