如何处理Stripe中未完成支付授权的试用订阅问题

你当前遇到的所有问题核心根源是：在用户完成支付方式授权前就提前创建了订阅，可参考以下三种优先级从高到低的方案优化：

方案1：调整订阅创建时机（最优解） #

• 取消当前提前创建订阅的逻辑，第一步先调用setup_intent.create接口单独生成用于验证支付方式的SetupIntent，关联对应用户的Customer ID后传给前端展示卡片输入页
• 监听setup_intent.succeeded事件，确认用户支付方式有效且已挂载到Customer账户下后，再调用subscription.create接口创建订阅，传入参数：
  • trial_period_days=30 配置30天免费试用
  • default_payment_method 传入刚才验证通过的支付方式ID
  • payment_behavior=default_incomplete
• 此时创建的订阅首单为0元试用账单，会自动标记为已支付，你可以直接复用原有的invoice.paid事件监听逻辑激活用户账户，无需额外关联SetupIntent和订阅
• 该流程下用户未完成卡片输入的情况下不会生成任何订阅，从根源上避免无效订阅的垃圾数据问题

方案2：基于现有流程做轻量修改（改造成本最低） #

如果不想调整现有订阅创建的主逻辑，仅需修改创建订阅时的参数即可解决问题：

• 创建订阅时新增传入参数payment_settings.payment_method_options.card.request_three_d_secure=any，同时设置pending_setup_intent参数，此时订阅创建后会处于pending状态而非激活状态，只有当关联的SetupIntent验证通过后，订阅才会自动变为激活状态
• 新增定时任务，每日扫描所有创建时间超过24小时、状态仍为pending、未关联有效支付方式的试用期订阅，调用subscription.cancel接口主动清理，无需等待下一阶段账单生成才自动失效
• 优化后你仍可监听invoice.paid事件激活账户，无需调整后续业务逻辑

方案3：使用Stripe托管的Checkout流程 #

直接调用Stripe Checkout的订阅创建接口，传入trial_period_days=30参数，由Stripe端托管支付方式收集、验证、订阅创建的全流程，你只需监听checkout.session.completed和invoice.paid事件即可，所有边界场景Stripe会自动处理，无需自行维护SetupIntent和订阅的关联逻辑，也不会生成无效订阅。

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