我正在与一个新客户合作一个项目，由于业务类型，他们在获取商家帐户来处理他们的在线支付时遇到了一些问题。该系统的工作方式与 Just Eat/Expedia 等类似，客户在网站上下订单，然后将订单传递到场地，网站收取佣金。
客户询问我们是否可以将客户付款详细信息存储在我们的数据库中（加密），然后将它们传递到场所，以便使用他们内部的卡系统自行处理。我知道这存在 PCI 合规性问题，但我无法直接回答我们需要做什么。我已经和几家托管公司谈过了，其中一家说我们需要一个具有独立 Web 和数据库服务器的集群，而另一家则说我们不会。我以前从未做过这样的事情，我通常只是将付款处理外包给 SagePay 等人。
这是建议的付款流程：
我想确保任何流程都是正确的，我最不想做的就是让网站受到攻击，支付详细信息，并对任何损失负责！
任何建议将不胜感激。
You failed to include an actual question....
However: PCI compliance is non-trivial; there are multiple levels of compliance, and the standards are a little dense...in general, as long as you don't store payment details, it's relatively easy to comply. If you do store payment details, your compliance requirements become a lot more complex, and may include processes such as vetting employees.
Your intention to transfer payment details to the venues looks like a huge red flag - you're basically giving credit card details to third parties, which I as a consumer would not be happy about, and is almost certainly not allowed within any of the PCI standards.
It's worth talking to a specialist payment gateway provider about the options you have - for instance, most credit card transactions consist of an "authorisation" call, which submits the card details and amount; the service checks the card is good for the money, and "ring fences" the amount on the account, and issues back an authorization code. The actual "settlement" can occur later - up to 10 days for some cards, and can use just the authorization code, rather than the full card details. A specialist payment provider will know what options you have.
It may be possible for you to share the authorization code with your venues, to allow them to take payment (though this would almost certainly require you all to use the same gateway provider).
It would be straightforward to change the flow you mention to include auth/settle logic:
另一种方法是完全将信用卡信息的存储从您手中拿走，并将负担交给有能力和专业知识的其他人，同时让您在必要时轻松向客户收费。Authorize.Net 提供他们的客户信息管理器 API，允许您为客户创建付款配置文件。他们处理信用卡信息的存储，并为您提供支付 ID。然后，您可以在必要时根据该付款 ID 收费，而无需访问实际的付款详细信息。