1. 初始数量不是最终购买记录
一则公开开发者提问描述了这样的困惑：销售积分包时允许买家调整数量，但买家选择多个之后，开发者从创建会话的响应中读到的仍然是一。这个案例说明开发者确实需要区分初始购物篮与已完成的购买记录，并不证明 Stripe 目前存在缺陷。[3]
Stripe 文档明确要求另一个步骤：付款完成后，请求 Checkout Session 的最终行项目及其数量；买家删除的项目也会从响应中消失。[1]应把创建响应视为配置快照，而不是会在应用内自动更新的对象。对于一次性托管结账，履约应以服务端重新取得的最终购物篮为依据，不能使用原购物车、浏览器传入的数量，或事先写入订单元数据的数量。
2. 开放结账前，明确可调整范围
在需要调整的行项目上启用 adjustable_quantity。Stripe 文档给出的默认最小值为零、最大值为 99，最大值最高可配置为 999999。初始数量超过 99 时，必须显式设置不小于初始数量的上限。Checkout 不允许买家删除购物篮中仅剩的最后一个项目。[1]
配置建议：同时审核初始数量、下限和上限。必须保留的商品可设置正数下限；可选配件则应明确允许删除，并让履约代码能够处理该项目不存在的情况。创建会话前，在服务端验证商品身份和业务限制。数量调节控件应表达已经批准的销售条件，而不是代替服务端审批。
3. 按上限预留，再核对购买差额
Stripe 明确说明，使用可调整数量时，应按 adjustable_quantity. 预留库存，而不是按初始行项目数量预留。[1]这是商户需要落实的库存管理职责，并不意味着 Stripe 会维护商户的库存账。
示意设计：会话初始数量为二，最多可以买六件，就先预留六件，而不是两件。最终购买四件且订单满足履约条件后，将四件预留库存转为已售库存，再释放剩余两件。分别保存预留、购买和释放数量，避免重复通知再次释放同一批两件库存。
应用侧建议：在创建并开放会话之前，以原子操作在并发买家之间分配预留库存。每个会话都设置六件上限，并不等于拥有一个共享库存锁。如果为每位买家预留六件会造成过多占用，应降低提供给买家的数量上限，而不是承诺未经保护的库存。
4. 在统一履约流程中读取最终行项目
Stripe 履约指南要求服务端函数接收会话标识，重新获取会话并展开 line_items，检查 payment_status，履行行项目并记录履约状态。该函数必须能正确处理重复调用和并发调用。由于客户未必会访问成功页面，不能省略网络钩子。[2]
建议顺序是：验证网络钩子签名，将会话关联到本地订单，读取最终项目，再将每个 Price 映射到内部商品，使用该行返回的 quantity。可调整数量指南也演示了直接列出会话行项目的方法。[1]不要通过支付总额除以目录单价来反推数量。如果取得的购物篮不完整，或者出现无法识别的商品，应保留异常记录并暂停处理，而不是猜测。
对于延迟确认的支付方式，会话完成不等于可以发货。Stripe 通过 checkout.session. 通知后续付款成功。[2]未付款订单应保持待处理状态。应用实现上，建议将最终购物篮、库存调整和履约标记一并提交，并持久化后续任务，避免重复发货或重复发放权益。
5. 验收数量变化，而不只是付款成功
建议在沙盒中检查：把两件增加到四件，把六件减少到一件，删除可选的第二个项目，以及尝试删除最后一个项目。将服务端读取的购物篮与买家的实际选择比较，不要只查看创建响应。重放通知，确认库存释放和积分发放都不会重复。销售积分包时，使用最终购买包数乘以商户自行定义的每包积分数。
还应检查延迟付款成功和商品映射缺失的情形。记录会话标识、最终数量、预留库存变动及履约决定，避免保存不必要的客户数据。本文没有执行上述测试。公开资料核查日期为 2026 年 9 月 22 日；未能确认来源的发布日期和更新日期。这些来源也没有确立地区可用性。本文不声称 PayIn 提供相关功能，也不讨论会话到期计时、发票导出或 Payment Link 完成次数限制。
来源与日期
技术行为以官方文档为依据；社区提问只说明定性需求。于2026-09-22读取核验，检索日期不等于原文发布日期；未注明的日期仍视为未知。本文为文档研究，不是实际账户测试，不代表 PayIn 产品功能，也不是法律、税务或财务意见。账户资格与地区可用性需要另行确认。
- [1] 允许买家调整行项目数量 · 发布日期未注明; 更新日期未注明 · 核验于2026-09-22。
- [2] 履行订单 · 发布日期未注明; 更新日期未注明 · 核验于2026-09-22。
- [3] 如何获取买家最终购买的数量 · 发布日期未注明; 更新日期未注明 · 核验于2026-09-22。