当我的结账流程有确认页面时，最大限度地减少 PCI 合规性
我的购物车流程如下：
- 第 1 页。选择产品
- 第 2 页。在单页结账时输入地址、送货、信用卡详细信息。
- 第 3 页。用户确认订单 - 但我们想要最后一次追加销售的机会，因此我们必须能够更改收费金额。如果用户放弃此页面，他们不应被收取费用或获得任何授权，但我们必须能够打电话给他们并说服他们订购，而不必再次询问他们的电话号码。
第 4 页。收据页面
以后需要重复计费，金额和时间表各不相同。 （用户必须能够返回并更改其计划，而无需再次输入 CC 号码）。
以下是我不想想要做的：
- 将用户发送到第三方页面（因为我想要单页结帐并保留品牌）
- 最大限度地减少 PCI 合规性要求
- 授权付款并在用户不同意时取消付款确认。这在很多层面上都是自找麻烦！
由于我需要一个确认页面，我想我需要使用某种标记化系统，例如 braintree付款。您基本上将信用卡号存储在他们的服务上，然后他们给您返回一个代表该号码的令牌。然后您可以随时从该卡中扣款，金额不限 数量。这当然看起来是最灵活的解决方案。
我有点想知道这是否是最好的解决方案：
- 我不知道 BrainTree 是否是唯一提供此类服务的公司，但我也不相信它真的有必要。
- 如果我将 CC 临时存储在会话中直到用户确认，我仍然可以使用几乎任何支付网关。因此，问题就变成了“如果我将 CC 暂时存储在内存中是否重要”以及存储到什么程度。
“最纯粹”、最安全的方法似乎是重定向到 Braintree（或提供类似网关的其他人）。
编辑（分配赏金后）：
我得出的结论是，我绝对必须有一个系统，我们只需要满足 A 级 PCI。我们对 PCI 进行了更详细的研究，这些调查问卷与无卡商户（即电子商务）相关。
SAQ A ：（当 CC 号码甚至不接触我们的服务器时）。如果您在网上销售，您仍然需要填写此调查问卷，但这非常简单。
SAQ D ：（即使我们不存储 CC 号码，也会触及我们的服务器
）看看这些调查问卷就会发现需求之间存在巨大的差异。 PCI 要求经常被误认为是一个简单的列表，例如“维护防火墙”、“安全策略”、“限制物理访问” - 但如果您真正阅读调查问卷 D，您会发现它有更多的问题和要求。例如，您必须回答您的服务器是否受到摄像机保护，以及您的服务器上有哪种数据加密。
我真的很高兴知道有哪些实际产品或提供商可以帮助我做我想做的事情。如果真的只有一两家公司允许我这样做，那么我需要知道。
我与 Braintree 没有任何关系，只是我设法进入了他们的电子邮件营销名单。他们是我找到的唯一一家做到这一点的公司。如果你正在经营另一家公司做同样的事情，那么一定要自吹自擂。随着时间的推移，PCI 要求只会变得更加严格，任何读到这里的人可能已经意识到这一点。
I have a shopping cart flow like this:
- Page 1. Choose Products
- Page 2. Enter address, shipping, credit card details on a single page checkout.
- Page 3. User confirms the order - but we want a final opportunity to upsell, so we must be able to change the amount charged. If the user abandons this page they should not be charged OR authorized anything, but we must be able to call them and convince them to order without having to ask for their number again.
Page 4. Receipt page
Repeat billing is a requirement for later, with variable amounts and schedules. (The user must be able to come back and change their schedule without entering CC number again).
Here's what I dont want to do :
- Send the user to a third party page (because I want a single page checkout and retain branding)
- Minimize PCI compliance requirements
- Authorize payments and cancel them if the user doesn't confirm. This is asking for trouble on many levels!
Since I need a confirmation page I think I will need to use some kind of tokenization system such as offered by braintreepayments. You basically store the credit card number on their service and they give you back a token that represents that number. You can then make a charge against that card at any time for any
amount. This certainly seems the most flexible solution.
I'm kind of going round in circles trying to figure out if this is the best solution or not :
- I don't know if BrainTree is the only company that offers such a service, but I'm also not convinced its really necessary.
- If I temporarily store the CC in session until the user confirms it I can still use pretty much any payment gateway. Therefore the question becomes 'does it matter if I store the CC in memory temporarily' and to what degree.
The 'purest' safest approach seems to be to redirect to braintree (or someone else that offers a similar gateway).
Edit (after assigning bounty):
I've concluded that I absolutely have to have a system where we only need to meet level A for PCI. Been studying PCI in more detail and these questionnaires are the relevant ones for card-not-present merchants (i.e. e-commerce).
SAQ A : (when CC numbers don't even touch our server). You still have to fill out this questionnaire if you're selling online, but it is pretty easy.
SAQ D : (where CC numbers touch our server EVEN IF WE DONT STORE THEM)
Take a look at these questionnaires reveals a huge delta between requirements. The PCI requirments are often misrepresented as being a simple list such as 'maintain a firewall', 'security policy', 'limit physical access' - but if you actually read questionnaire D you'll see it has order of magnitute more questions and requirments. For instance you have to answer whether or not your server is protected by a video camera, and what kind of data encryption you have on your server.
I'd really appreciate knowing what actual products or providers out there that will facilitate me doing what I want to do. If there really is only 1 or 2 companies out there that let me do this then I need to know.
I've got no relationship to Braintree except I've managed to get on their email marketing list. They're just the only company I've managed to find that does this. If you are running another company doing the same then by all means blow your own trumpet. PCI requirements are only going to become more stringent over time and anyone who has got this far reading my question probably already realizes that.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，如果您将 CC 编号存储在内存中，这很重要。当卡号接触到您的网络时，您就处于 PCI 范围内。
我不在布伦特里工作，但在一家可以满足您需求的公司工作。您需要将标记化和数据传输到外部站点相结合。我们有一个解决方案可以解决重定向到外部站点的需求。 （我为编造这个感到非常自豪，人们为之疯狂。）它是专门为了解决你提到的所有问题而制作的。 （是的，你并不孤单。）
我不会通过自我推销来偏向你的搜索，因为我确信有很多人在这样做。 （另外，我不是以官方营销身份来到这里，也不想给自己带来任何问题。）
祝你好运。
更新：你可以是一家小公司，但仍然达到第一级。这完全取决于数量，如果你第一次就做对了，那么当你达到更高的等级时，就没有什么可以改变的。如果您不存储 CC 编号（通过标记化或其他选项），那么当您需要第三方审核员参与时，这会限制应用程序和服务器为 PCI 执行的操作。这只是一个问题。
如果卡号到达您的服务器，则直到该服务器为止的所有内容都在 PCI 范围内。审核员不接受将 CC 号临时存储在内存中会限制服务器范围的事实，这是极其愚蠢的。但你是对的；透明重定向、第二站点重定向，甚至简单的回发都无法保证数据不会被窃取。 PCI 旨在设置障碍，使数据泄露变得困难，然后能够说您已尽一切努力防止数据被盗。 （我的类比是，PCI 将所有责任都指向用户，而不是一直到处理器进行业务的人员。）
PCI 真正的大问题是，您无法预测 PCI 的严格程度。如果您达到需要审计员参与的程度，规则将被强制执行。每个审计员对 PCI DSS 要求的解释都略有不同，甚至审查 ROC 报告的人员也可能突然决定他们不喜欢您所做的事情。你关心什么并不重要；你关心什么并不重要。重要的是 PCI 人员是否会接受您的 ROC，或者他们是否会执行对规则的一些新解释。
我曾与许多审计师和许多大公司合作过 PCI。现在的解释是，限制范围意味着卡号无法接触您的网络。这对您有何影响完全取决于您当前或未来的交易量。
Yes, it matters if you store the CC number in memory. The moment the card number touches your network, you're in scope for PCI.
I don't work for Braintree but do work for a company that does what you need. You need a combination of tokenization and having the data hit an external site. We have a solution that works around the need to redirect to an external site. (I'm pretty proud of making that up, and people are going crazy for it.) It was made specifically to address everything you've mentioned. (Yes, you are not alone.)
I won't bias your search with self promotion as I'm sure there are lots of people out there doing it. (Plus I'm not here in an official marketing capacity and don't want to cause any problems for myself.)
Good luck.
Update: You can be a small company and still reach tier 1. It is all about volume, and if you do it right the first time there is nothing to change should you reach a higher tier. If you're not storing CC numbers (either by way of tokenization or other options), then that limits the applications and servers from what you need to do for PCI should you get to the point where a third party auditor needs to be involved. That is only one issue.
If the card number reaches your server at all, everything up to the point of that server is in scope for PCI. It is extremely silly that the auditors won't accept the fact that storing the CC number temporarily in memory should limit the scope of the server. But you're right; transparent redirect, second site redirect, or even a simple postback have no way of guaranteeing that data won't be stolen. PCI is about putting obstacles in place to make a data breach difficult, and then to be able to say that you've done all you could to prevent the data from being stolen. (My analogy is that PCI aligns the blame fingers to all point in the direction of the user rather than the people conducting business all the way up to the processor.)
The real big problem about PCI is that you can't anticipate how strict the rules will be enforced should you get to the point where an auditor needs to get involved. Every auditor interprets the PCI DSS requirements slightly differently, and even the people reviewing the ROC reports can suddenly decide they don't like what you're doing. It doesn't really matter what you're concerned about; what matters is if the PCI people are going to accept your ROC or if they are going to enforce some new interpretation of the rules.
I've worked with many auditors and many large companies going through PCI. The interpretation right now is that limiting scope means the card numbers can't touch your network. How that affects you is entirely dependent on your current or future volume.
如果您不将用户重定向到其他站点，则必须填写表格 D。它适用于所有具有 PAN 的系统，即使它们没有写入磁盘。如果您刚刚开始，我建议您采用重定向路线，这样您就可以避免这种情况。 PayPal 的信用卡产品实际上是一个合理的选择。如果不出意外的话，它们又大又坚固，不太可能去任何地方。
完全符合 PCI 标准既耗时又昂贵。我认为通常最好推迟到企业有一些收入为止。
You will have to fill out form D if you do not redirect the user to another site. It applies to all systems that have PANs, even if they aren't written to disk. If you're just getting started, I'd suggest going the redirect route so you can avoid that. PayPal's credit card offering is actually a reasonable choice for this. If nothing else, they're big and solid and unlikely to go anywhere.
Full PCI compliance is time consuming and expensive. I think it's generally best to defer that until a business has some revenue.
一般经验法则如下：如果您不读取、存储或处理 PAN (CC#) 和/或到期日期，则不需要 PCI 合规性。如果您甚至远程触摸该卡号，那么您就需要接受 PCI 合规性。
为什么不简单地使用 PayPal 呢？
Here's the general rule of thumb: If you don't read, store, or process the PAN (CC#) and/or exp date, then you don't need PCI Compliance. If you even remotely touch that card number, then you need to undergo PCI Compliance.
Why not just make it easy and do PayPal ?
如果您想最大限度地减少 PCI 要求，请重定向到托管支付页面或使用 iFrame 解决方案。有关更多详细信息，请参阅我帮助撰写的 Drupal PCI 合规性白皮书。
If you want to minimize your PCI requirements, redirect to a Hosted Payment Page or use an iFrame solution. For more details, please see the Drupal PCI Compliance white paper, which I helped author.