不同人的多次条纹支付尝试。他们应该共享相同的“clientSecret”吗？
Posted
技术标签:
【中文标题】不同人的多次条纹支付尝试。他们应该共享相同的“clientSecret”吗？【英文标题】：Multiple stripe payment attempts by different people. Should they share the same `clientSecret`? 【发布时间】：2021-12-03 06:58:01 【问题描述】：条纹PaymentIntent
条纹示例应用建议在加载付款表单时创建PaymentIntent。
同时，文档说您应该在知道向客户收取多少费用后立即创建PaymentIntent，并使用相同的意图来避免多次收费。
爱丽丝和她的朋友们一起旅行
让我们假设这种情况：产品是“长途旅行”，需要支付高额费用。 （> 3 000 欧元/美元），并且选择产品的人将支付链接发送给其他人以进行支付（可能是给其他旅行者）的变化很大。让我们称 Alice 为旅行领队，而 Alice、Bob 和 Charlie 为旅行者。
放弃 Alice 支付一部分，Bob 支付另一部分的想法......不是要分析的例子。
这个想法是，Alice 尝试全额付款，但如果她的卡失败，则要求 Bob 或 Charlie 进行全额付款。全额付款后，他们将安排他们之间的关系。
为此，系统会为 Alice 准备一个带有支付链接的报价单。 Alice 可以点击链接付费，但她也可以与 Bob 和 Charlie 分享链接。该链接包含报价 ID，因此没有机会伪造金额等等。
事实上，该链接在结帐前发送到“验证页面”：“这笔付款是给 Alice，行程 xxx，金额 xxx，[立即付款]”。
应该什么时候创建PaymentIntent 实体？
我可以想象多种场景：
单例早期初始化：在创建报价和首次生成支付链接时创建PaymentIntent，并使用相同的PaymentIntent加载它。
单例延迟初始化：第一次加载结帐页面时，创建付款意图并将ID保存到报价单中，以便后续结帐将重用已经初始化的ID。
优点：与“1.”一样，单个实体跟踪任何试图支付他们共享的特定报价的人的付款试验。 缺点：如果 Alice 和 Bob（或 Charlie）都在同一毫秒第一次加载结帐，以避免创建两个对象并破坏单例事物，则需要额外的编码逻辑。多个，一个用于会话：在加载结帐时，为每个 coockie 创建一个新的付款意图，这样 Alice 就会有她的付款意图，Bob 是他自己的，Charlie 也是他的。此外，PC 中的 Alice 和移动设备中的 Alice 可能会生成不同的PaymentIntents，因为它们可能有不同的 cookie。
Multiple, volatile：在每次结帐页面加载时创建一个PaymentIntent。
直觉
我的直觉说首选方案是单例、延迟初始化。我可以在一个地方看到对同一报价的所有尝试的良好跟踪，避免像第一个选项那样创建太多过时的项目。
事实上，在这种情况下，如果我们发现一个陈旧的商品实际上意味着有人“触摸了结帐但没有付款”，这是将陈旧的PaymentIntent 留在那里的正确意图。
从安全的角度来看，我想知道如果我在多个人和地点共享同一个 clientSecret 会发生什么（可能 Alice 在巴塞罗那，而 Bob 在马德里，而 Charlie 在巴黎）。
问题
应该使用 4 种方法中的哪一种？为什么？ 如果我选择单例延迟初始化，在多个浏览器、设备和 IP 上使用相同的clientSecret 是否有任何惩罚/安全/风险？
【问题讨论】：
【参考方案1】：您在这里很好地列出了选项，并且很好地涵盖了优缺点。
我倾向于同意选项 2（单例，延迟初始化），但由于客户/付款人在概念上发生了变化，我认为选项 3（多个，一个用于会话）可能是首选。您将在报价系统中跟踪是否已支付相关付款意向之一，然后取消其他付款意向并阻止进一步创建。您可以通过使用separate auth & capture 来建立额外的保证，避免在竞争条件下重复付款，只有在确保您没有同时获得两个授权付款意图时才捕获。
如果您想采用单例方法，在跨地域重复使用付款意图时获得有关风险问题的帮助，我建议您联系 Stripe 的support team，详细说明您的首选流程.
【讨论】：
以上是关于不同人的多次条纹支付尝试。他们应该共享相同的“clientSecret”吗？的主要内容，如果未能解决你的问题，请参考以下文章