我正在开发一个SDK，该SDK可以接受无权拥有信用卡数据(cc_data)的电子商务公司(商家)的在线卡支付。目前我正在努力想出一个合适的解决方案来保护API。
当前解决方案使用无状态会话(不会更改)，如下所示：
付款单初始化
- 商家使用http基本身份验证进行API调用以启动支付
- 作为回应，商家获得支付链接和代币
- Merchant使用支付链接来调用iframe：每个输入(名称、cc_number等)都有一个iframe，包括作为iframe提交。这将提供尽可能少的预设计，以便商家可以设计自己的付款形式
Iframes，收集cc_data并提交
- 每个iframe都有一个相应的html和javascript。例如name.html和name.js，submit.html和submit.js。输入的数据存储在sessionstorage中
- 推送提交后，submit.js将对支付API端点(我们自己的服务器，因此为了内部安全，使用CSRF令牌)进行AJAX调用，以发布cc_date
问题
现有的支付API端点也需要给商家的令牌，但我还没有找到一个合理的解决方案来从商家那里获得它，因为系统是无状态的。在某种程度上，我的解决方案没有遵循标准的令牌授权，即令牌是给用户授权其操作的，因为用户(在我的情况下是商家)没有调用该操作。我只使用我自己的服务器提供的CSRF令牌来调用它。
可能的解决方案
在某种程度上，在我看来，也许我应该放弃代币授权的想法，因为事实并非如此——商家没有打电话，因此无需授权(在付款启动过程中，它已经对自己进行了身份验证)。但一些开发人员确实指出，在我的情况下，CSRF代币可能不够安全，因为他们有可能访问它(例如，模仿保存代币的web浏览器)，然后他们可以在代币有效期间滥用支付API端点。
考虑到前面提到的内容，我仍在努力寻找一种解决方案，以启用API安全性的方式传递授权令牌。显而易见的可能解决方案是使用postMessage()将令牌从商家(父窗口)发送到submit.js(iframe origin)。但我不太喜欢这个想法，因为有很多可能的来源，代币可能来自哪里，因此我无法做出合理的过滤，我将消息排除在外。将令牌发布到服务器不是一个选项，因为它是无状态的。。。以及调用iframes以不提供包含头的可能性。
提出想法
因此，目前我正在寻找解决方案，并认为Stackoverflow可能是寻求建议的最佳场所。也许我应该彻底改变我目前的概念验证(这意味着我的问题没有好的解决方案)，所以也欢迎在这个层面上提出建议。当然，重要的是要考虑到服务器是无状态的，cc_data不能到达商家，并且整个支付表单的设计应该尽可能在商家的控制之下。
谢谢你事先的建议。
这是我第一次在Stackoverflow上发帖(几周前我刚开始是一名初级开发人员)，也是一次新的有趣体验。
编辑：业务需求
- 无重定向支付，支付表单显示在商家网站上
- 商户应尽可能多地控制支付表单的设计(在初始化支付时，商户也可以选择iframe来源的样式)
- 商户不得访问cc_data(或以商户可理解的形式拥有该数据)
实际上我第二天就自己解决了这个问题，但我想先在实践中检查我的解决方案。答案其实很简单：双提交cookie。
因此，基本上，每当submit.html被submit.js(iframe按钮负责将支付数据发送到API端点)调用时，它都会从后端服务器获得一个CRSF令牌。服务器还将使用https安全cookie将加密cookie附加到submit.html。
现在，每当submit.js对API端点进行调用时，CSRF令牌都将与头一起发送回。后端服务器获取附加到submit.html的加密cookie，解密并将其与标头中的CRSF令牌进行比较。如果匹配，则请求有效。
更多信息可以在这里找到：OWASP作弊cheet。