claude/reserve-pay-after-approval-2026-09-22 · 最后动的时间 2026-09-22分工只登记在仓库顶层的 BOUNDARIES.md，本页不另写。
读图：入口是客人提交订场请求（现在不用先登录），主线一路往下走到「确认信 + 日历邀请发出」。三个标着「机器把关」的框——自动把请求挂到账号名下、点付款前核实身份与状态、付款回调核实没重复确认——全是机器自动判断，没有人工经手；其余几步要么是客人的动作，要么是店长的判断。右边两个虚线框是岔路：店长随时可以拒绝（不收钱），订上之后店长还能取消（全额退款）——两条岔路走完，客人手上已经开出的付款页都会跟着失效。
← 回 订场办活动页 /reserve PRD v0.2 · 同级：/reserve 订场页改版 · 提高转化的计划 · 订场「批准之后才付款」· 工作流文档
读图：这份是「批准之后才付款」子 PRD（图中高亮那一块）；往上一步是订场页主 PRD，同一层还有它自己的工作流文档、以及主 PRD 原有的改版计划页。
问题：店长批准一条订场请求后，回信里是一条谁拿到都能直接付款的链接。客人现在还得先登录才能提交请求，这跟 8 月 25 日「先不登录也能交、注册那一侧再收齐信息」的口径反了。我们目前只收到过一条真订场请求，它停在人工审核那一步 22 天没人动 —— 也就是说，批准之后这一段，至今没有一个真人走过。
做法：订场表恢复不用登录也能提交；批准信换成「建账号或登录才能付款」的邀请信，不再是一条直接能付的裸链接；用提交时那个邮箱注册或登录后，请求自动挂到账号名下，账号页里随时有一个「Pay now」按钮可以回去点，不再全靠一封邮件里的链接还活着。
输入：一条已经被店长批准、状态是「等付款」的订场请求——姓名、邮箱、门店、日期、人数，还有批准那一刻算好的金额。
输出：客人在账号页看到这条请求、点一下「Pay now $X」就能付款；付完款状态变成「已确认」，系统照旧发确认信和日历邀请。
两个新东西：①批准时发的邀请信，换成「用这个邮箱建账号或登录，才能继续付款」，不再带一条谁拿到都能直接付的链接；②账号页那一行订场记录旁边，长出一个「Pay now $X」按钮——点了以后系统先核实这是不是本人的请求、状态还对不对，核实通过才带去 Stripe 付款。
什么算好：下面 8 条检查全绿。
按重要度排，可跑的整表在附录。
| 编号 | 功能 | 怎么验 |
|---|---|---|
| F01 | 批准信不再是能直接点开付款的链接，改成「建账号或登录」的邀请信，金额写清楚 | 新测试断言批准邮件正文里没有可以直接点开付款的链接 |
| F02 | 订场表恢复不用先登录也能提交（跟 8 月 25 日的口径一致）。订场表分两步：第 1 步问日期、门店、人数，第 2 步问姓名邮箱电话并交表 —— 现在卡人的就是第 2 步。 | 新测试断言订场表第 2 步不登录也能交 |
| F03 | 用提交时那个邮箱注册或登录后，这条请求自动挂到账号名下，账号页看得到 | 新测试模拟同邮箱注册/登录，账号页的列表里能看到这条请求 |
| F04 | 账号页那一行出现能点的「Pay now $X」，点了真的到 Stripe 付款页，金额和批准时算的一致 | 新测试模拟点击，走到真实的 Stripe 付款会话，金额对得上 |
| F05 | 只有这条请求本人、且还在等付款状态时，才点得动付款；别人或状态不对时点不动 | 新测试模拟别人的登录令牌、以及状态已经变化两种情况，都拿不到付款页 |
| F06 | 重复点付款，或者旧付款页过期了，都不出乱子（不重复收钱，也不会点了没反应） | 新测试模拟连续点两次、以及付款页已经过期两种情况 |
| F07 | 店长拒绝或取消时，客人手上正等付款的那个付款页要跟着失效 | 新测试模拟先点过付款、店长再拒绝/取消，付款页跟着失效 |
| F08 | 付款成功之后的确认信 + 日历邀请，跟现在完全一样，不受影响 | 现有测试原样跑绿，确认没被这次改动牵连 |
account-claim-history.mjs），不是商城结账。