倒计时只是显示，名额保留则是被记录的分配。小班课程或活动采购结账功能时，应先问谁负责留位、何时到期、付款证据迟到怎么办。本文提供网站验收要求，不是可直接接客售票的系统。
平台事实与实现选择分开
Stripe 托管式Checkout库存说明支持会话到期及到期事件，由自己的系统处理库存释放。文档规定定时expires_at在创建后30分钟至24小时之间，手动结束会话另行处理；核对日期为2026年10月16日。因此，网页显示五分钟倒计时，不代表定时会话就能设成五分钟。
五个名额的已填写事件账
合成串行例子：总容量五人，A要两席、B要三席、C要一席。每个事件关联唯一保留ID，没有真实学员或付款。
窄屏可横向滚动查看完整表格。
| 事件 | 保留 | 已售 | 可用 | 应作判断 |
|---|---|---|---|---|
| A保留两席 | 2 | 0 | 3 | 接受A |
| B保留三席 | 5 | 0 | 0 | 接受B |
| C申请一席 | 5 | 0 | 0 | 拒绝确认或进入候补 |
| A已付，通知重复一次 | 3 | 2 | 0 | 只出售一次 |
| A付款后又收到到期通知 | 3 | 2 | 0 | 不释放已售名额 |
| B到期通知重复两次 | 0 | 2 | 3 | 只释放一次 |
比较完整方案
原生预约产品可能已经负责容量与收款，应先演示真实行为，再决定是否增加另一套账。定制结账需要持久化保留状态和原子分配机制。展示型网站也可以仅受理余位咨询，但不能把咨询写成确认席位。方案是否合适取决于对客户的承诺。
有意义的验收
- 复现六行事件，确认“保留＋已售＋可用”始终为五。
- 在隔离集成环境同时申请最后一席，最多一笔能确认。
- 重放重复和乱序事件，不能重复出售或重复释放。
- 若名额已释放才出现付款证据，停止自动确认并进入明确的对账流程，不能默默超售，也不能假定已自动退款。
应保留的证据
记录保留ID、数量、会话ID、服务端到期时间、付款状态、分配状态及核对结果。成功页访问和浏览器计时都不够。迟到或未知证据与已确认销售分别记录。
边界
下载模型只演示串行状态变化，不是数据库并发测试、webhook接收器或收款集成；不覆盖异步付款、退款、取消和出席规则，这些需要供应方确认。持久化webhook收件箱处理的是消息接收，与名额分配属于不同验收任务。
复核本页教学例子
以下文件可在本地离线复核，只模拟本页说明的情况，不代表真实平台集成。 已填写输入及预期结果 · 可检查的教学函数
把两份文件存入同一文件夹，使用Node 22.13或更新版本运行：
node decision-check.mjs checkout-seat-hold-contract.json