上线收款有哪些前置阶段？
四个，且是顺序进行的——Portal 首页会把前三个显示为按顺序解锁的卡片：
从这个顺序可以得出两点：
- **审核通过之前，支付方式开通无法开始。**首页卡片会保持锁定并明确提示。验证尚未完成时催开通，不会有任何推进。
- 集成验收在 sandbox 中进行，所以在阶段 3 仍在进行时你可以完成阶段 4 的全部工作。你不需要空等。
切到生产环境时到底有哪些变化？
两个环境如何相互隔离，以及其他所有 sandbox 特有的内容，见
Sandbox 环境与访问。
需要特别留意的是两行密钥。不要把 sandbox 凭证或 sandbox 密钥对带到生产环境——它们不可互换，用了错误环境的密钥会以无效密钥失败，而不是以权限问题失败。逐项检查清单（包括生成生产密钥对的命令）在已发布的
上线检查清单；为什么会以这种方式失败，见
我的订单被拒绝时。
我这边需要做哪些技术准备？
已发布的上线检查清单是权威依据，其中有四项值得在这里点出来，好让你把它们排进迭代计划，而不是在切换当天才发现：- 超时——推荐的调用超时时间，含下限。
- DNS——推荐的 TTL，以及不要固定 IP 地址。
- 日志与告警——特别是针对订单创建、订单查询和Webhook 通知处理，因为这是上线问题最先暴露的三个地方。
- 部署位置——关于区域和延迟的建议，如果部署在中国大陆则多一步。
集成验收要求什么？
你在 sandbox 中跑一组用例，把结果记录到模板中，再把模板提交给你的 Waffo 技术支持群，由其确认。检查的内容包括：支付成功与失败路径、Webhook 通知处理以及Webhook 通知幂等、退款和订阅（如果你集成了）、你对异常场景的处理、参数质量，以及你是否持久化了正确的标识符。 两个容易漏掉的实际要点：- **有些用例是用 sandbox 预留金额复现的。**它们会故意返回对应的错误。请使用已发布的列表，不要自己编金额——见 Sandbox 模拟器。
- **你不必测试每一种支付方式。**覆盖按代表性来：至少一张卡、每个国家每种类型至少一种支付方式，加上任何需要特殊参数的支付方式，以及在真机上测试钱包原生支付方式。
我以前集成过，这次只加一种支付方式，还要全部重做吗？
不需要——有一份面向后续一次性支付集成的简化模板，正是为这种情况准备的。只有你已至少通过过一次验收才能使用；首次集成使用完整模板。 它要求你先声明范围——你的商户 ID、签约产品、本次集成覆盖的支付方式和 API——然后只跑真正在范围内的用例：订单支付成功与失败、支付通知、取消、退款与退款通知，其中取消和退款仅在本次集成包含它们时才需要。两份模板及选择规则都在已发布的 验收标准页面。我已经在跑一次性支付，现在想做订阅，算第二次上线吗？
不是第二个账户，但确实是第二次集成，并且有自己的验收路径：在一次性支付模板旁边有一份独立的订阅验收模板，包含自己的用例——首期支付激活订阅、模拟续订、以及取消。 两个后果：- 两种产品在你的协议上是分开的，所以为一次性支付签约的支付方式并不自动适用于订阅。请查看 Service → Payin 的
Product列，以及支付方式配置响应中的 product 字段。 - Sandbox 允许你不用等待真实计费周期就模拟续订，续订用例就是这样跑的——见 Sandbox 测试。
上线第一天我应该关注什么？
四件事，而且全部可以由你自己查看，不需要问任何人：
第一天就值得养成的一个习惯：**以Webhook 通知或查询接口作为支付结果的权威依据，永远不要以客户跳转回你网站作为依据。**为什么如此、跳转能证明和不能证明什么，见支付结果。