Stripe创建新checkout session前如何过期有效会话避免多标签支付问题

核心实现逻辑 #

你需要在创建新会话的逻辑前，增加用户维度的历史有效会话清理流程，结合Stripe官方的会话过期接口实现需求，具体操作步骤如下：

• 预先在你的业务数据库中，为每个用户维护关联的Checkout Session记录，字段至少包含：session ID、对应用户ID、关联tempObjectID、session状态（open/expired/completed/canceled）、创建时间
• 每次收到用户创建新Checkout Session的请求时，先查询该用户所有状态为open的历史session记录
• 遍历所有查询到的未支付历史session，逐条调用Stripe官方过期接口，Node.js环境代码示例：

  const stripe = require('stripe')('你的Stripe密钥');
  const expiredSession = await stripe.checkout.sessions.expire('历史session的ID');
  

• 历史session过期操作全部完成后，在数据库中将对应session的状态更新为expired，同时将关联的tempObject标记为失效
• 完成所有清理操作后，再执行新Checkout Session的创建逻辑，将新生成的session和对应的tempObject存入数据库，标记状态为open，再引导用户跳转支付

额外兜底校验规则 #

为了避免极端场景下的逻辑漏洞，建议增加以下校验：

• 处理Stripecheckout.session.completed事件的webhook时，先校验触发事件的session是否是对应用户当前唯一的open状态session，如果不符合规则直接终止后续subscriptionObject的创建流程，返回错误状态码
• 为tempObject设置24小时自动过期逻辑，和Stripe Checkout Session的默认过期时长保持一致，避免残留无效数据
• 可选优化：用户进入订阅购买页时，先查询是否存在未支付的open状态session，如果存在直接引导用户跳转至已有session的支付页，无需重复创建，同时减少无效操作

注：Stripe的Checkout Session标记为过期后，用户即使通过历史标签页访问原有支付链接，也会看到会话已失效的官方提示，无法完成支付，可彻底解决多会话同时生效的金额漏洞问题

内容的提问来源于stack exchange，提问作者Sulman Azhar