上线验收与运营：沙盒测试、对账与风险处理
今天只做一件事：把9美元10次包从“看起来能付”测到“知道哪笔收款给了哪份额度”。 成品是一份测试记录和一张三笔交易的对账表。先完成5-3的测试商品，再按5-4“从本地签名练习进入真正的Sandbox结账”运行同一个server.mjs及本地购买按钮。5-4提供固定教学用户demo-user-a，并没有实现登录；本节先用该用户验证，接入你自己的应用后再以真实验证会话替换固定身份。没有测试账户时，完成5-4无账户签名路径和本节三笔纸面对账即可，不等一个教程未提供的结账入口。
全程使用独立Sandbox和测试资料，不产生真实扣款；禁止在live环境用真实银行卡或其他真实支付资料做练习测试。平台的测试功能并不等于你的应用已通过所有场景；这里给的是你要逐项实际观察的结果。
用一笔成功付款检查三处记录
打开Stripe测试说明，在 Testing interactively 中可以查到官方测试卡号与填写方式。配图中的测试流程说明了浏览器、平台与网站之间的消息顺序，你要核对的是自己这笔交易的三个落点。
先在终端用Control-C停止5-4的Node进程，把.env.sandbox中的DEMO_ORDER_ID设为demo-order-success-001，执行node --env-file=.env.sandbox server.mjs重新启动；CLI事件转发窗口保持运行。每次换ID都是新订单，重试这一笔则不换ID。若该ID以前已用过，换一个从未使用的后缀。
- 使用5-4本机演示时，打开
http://localhost:4242/balance，确认服务器固定的demo-user-a余额为0；若已接入自己的应用，则登录专用测试账号A并查看余额。 - 在5-4本机首页点击Open sandbox Checkout（或自己应用的9美元10次包按钮），进入测试Checkout。核对商品名称、金额9.00和USD；如果不符，返回修复价格映射，不继续支付。
- 填官方成功测试卡
4242 4242 4242 4242，有效期填未来月份，如12/34，安全码使用测试值123，其他字段按测试表单要求填写。 - 支付完成后，去平台找到对应会话，再回应用刷新余额。
你应同时找到：平台付款状态为paid、本机/balance中的orderId对应本次订单且fulfilled为true、固定教学用户余额10次。本机小演示未另存paid字段，付款状态应去平台查，不能把不存在的本地字段写进记录。浏览器出现成功页只能证明跳转发生，少任何一个落点都要继续查。
将这一行作为自己的记录格式，实际测试后替换示例标识：
case: happy-path-001
user: test-user-a
order: 本次实际订单号
provider_session: 本次实际cs_test_标识
expected: paid / fulfilled / credits=10
observed: 在三处实际查到后填写
这里有意不替你把observed写成passed。教程作者没有登录你的账户，不能预先完成你的联调结果。
再做四个会暴露错误的小实验
重复通知最容易漏测。打开Webhook投递说明，在 Workbench > Webhooks > Event deliveries 找到刚才那条事件，再按页面支持的重发方式投递。平台可能显示再次送达，用户A仍应只有10次，本地发放记录仍只有一条。若余额变成20，先修复订单唯一发放，再开放付款。
付款失败另起新订单：先保留成功单的记录，再用Control-C停止Node，把.env.sandbox中的DEMO_ORDER_ID改为demo-order-decline-001，重新执行node --env-file=.env.sandbox server.mjs。打开本机/balance确认归零，再从首页按钮创建Checkout，用官方测试页对应的拒绝场景付款。不要修改成功订单充当失败单。用户应看见可理解的失败提示；订单不能变成已发放，余额保持原值。若你使用某种延迟确认方式，则在处理中显示等待，确认成功后才发放。
关闭页面的实验不用特殊银行卡：保留失败单记录后，再停止Node，把DEMO_ORDER_ID改为demo-order-close-001并用同一命令重启；确认本机余额0，从首页新建Checkout，用成功测试卡付款。在返回应用前关闭页签，再从新页签打开http://localhost:4242/balance查看固定教学用户。服务端仍应完成发放。这个实验直接发现“只在成功页增加次数”的实现。
本机重启清空的是教学内存，不是Stripe中的交易；三笔测试各自的会话ID要在重启前记下。重复通知实验应在成功单尚在内存时完成，不能拿已换到下一订单的服务器重放旧单来验证。
最后用测试付款做一次退款，先在平台查退款记录。5-4的小演示没有实现退款回调或多包额度回收，平台退款不会自动扣回这台演示服务器的10次额度；本节先按5-5的状态稿纸面演练应用应如何变化。自己的应用实现退款关联和回收后，再实际测试应用处理状态。若产品选择回收未使用次数，明确找到对应订单的那一批额度，不要随意扣减其他购买包的余额。退款还没确认成功时，在账单页显示待处理。
用三笔样例把钱对齐
现在练习对账。以下金额全部是假设，处理费仍沿用5-1的3%加0.30美元，只为说明计算，实际费用从平台余额交易查。
| 订单 | 收款 | 假设处理费 | 退款本金 | 对平台余额的净影响 | 应用记录 |
|---|---|---|---|---|---|
| A，成功购买 | $9.00 | $0.57 | $0.00 | +$8.43 | 发放10次 |
| B，成功后全额退款 | $9.00 | $0.57 | $9.00 | -$0.57 | 关联原包的退款处理 |
| C，付款未成功 | $0.00 | $0.00 | $0.00 | $0.00 | 不发放 |
| 合计 | $18.00 | $1.14 | $9.00 | +$7.86 | 不能写成收入18美元已到账 |
计算顺序是 18 - 1.14 - 9 = 7.86。其中B假设原收款处理费未退回，是否还有其他退款费用要看实际账户规则。本表也没有扣模型费用，不能把7.86写成利润。
Stripe余额汇总报表提供分类交易明细导出，适合解释平台余额变化；它还特别区分了“余额变化”和“某次打款包含哪些交易”。因此银行今天收到多少钱，不能直接拿当天网站订单总额去减，跨天结算、退款和费用都可能混在其中。
下载一份能追到订单的明细
若你的账户已有可用报表，在 Reports > Balance 选择明确的日期区间和结算币种，导出明细CSV。Sandbox可能没有和正式账户完全一样的报表数据；没有时就先用上面的三笔教学表练习，不切到正式环境制造交易。
本地订单保留订单号、平台付款ID、币种、金额、发放状态、退款ID。平台明细导出后，按付款ID关联，不用客户姓名或邮件地址模糊匹配。若一笔付款在平台成功、本地未发放，先按订单补查服务端履约；若本地已发放、平台查不到对应付款，应暂停自动补发并查明环境或关联错误。
订阅场景另用Billing测试文档提供的测试时间工具观察续费，不必等一个真实月份。一次性包先把今天这条链跑完整，再增加订阅组合。
完成本节时，保存一笔实际成功联调的三个标识、一条重复投递不重复发放的结果，以及三笔教学对账的7.86美元合计。三者分别回答：交易是谁的、额度有没有多发、钱为什么与订单总额不同。