基于Stripe的服务器/数据库访客结账业务逻辑实现问询

一、调整支付与数据库操作顺序（解决恶意提交/无效条目问题） #

原流程先创建正式数据库条目再处理支付的逻辑存在明显漏洞，建议改为先生成临时草稿、支付成功后再转正为有效条目的模式，同时覆盖「稍后支付」场景：

常规支付流程优化 #

• 前端提交广告详情到后端
• 后端创建草稿状态的临时记录：带唯一draft_id，标记status: draft，可额外记录提交IP、创建时间等信息
• 后端调用Stripe API创建Checkout Session，将draft_id存入会话的metadata字段，同时配置success_url和cancel_url（均携带draft_id）
• 前端重定向至Stripe结账页面
• 后端通过Stripe的checkout.session.completed webhook接收支付成功通知，从metadata中取出draft_id，将草稿记录转为正式广告条目（更新status: active）
• 新增定时清理任务：自动删除超过有效期（比如24小时）的未支付草稿，避免数据库冗余

「稍后支付」功能处理 #

• 用户填写表单后选择「稍后支付」，后端同样生成草稿记录
• 调用Stripe API创建Payment Link，将draft_id存入Payment Link的metadata
• 后端将Payment Link通过邮件发送给用户，同时在草稿记录中标记payment_link_sent: true并记录发送时间
• 用户点击链接完成支付后，webhook触发草稿转正逻辑；若超过7天未支付，自动删除该草稿

二、解决Stripe Checkout的success_url误导问题 #

Stripe Checkout的success_url会在结账流程完成（无论支付是否最终成功）跳转，需结合webhook和前端状态校验修正：

• 修改success_url指向：将success_url设置为前端的「支付结果查询页」，携带会话ID参数，格式示例：https://your-app.com/payment-result?session_id={CHECKOUT_SESSION_ID}
• 前端主动校验真实状态：用户进入查询页时，前端调用后端接口传入session_id，后端通过Stripe API查询会话的真实payment_status：
  • 若状态为paid，展示「支付成功，广告已发布」提示，引导用户查看广告
  • 若状态为unpaid或失败状态，展示「支付未完成，请重新尝试」提示，同时基于原草稿记录生成新的支付会话，提供一键重试入口
• 依赖webhook做最终同步：即使前端查询时因网络延迟未获取到最新状态，webhook收到支付成功通知后会立即更新数据库状态，用户刷新页面即可看到正确结果；同时可给用户发送邮件通知最终支付状态，进一步避免误解

三、额外优化建议 #

• 前端添加验证码、后端限制同一IP的提交频率（比如1小时内最多3次），减少恶意草稿生成
• 对于支付失败的用户，保留草稿记录，允许其直接从失败页面或邮件重新发起支付，无需重复填写广告内容

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