“只需要连接到支付系统”这句话往往是三周延误的前奏。编码很少是真正的问题；账户、审批，以及测试环境与生产环境之间的差异才是。
为什么集成并不是一项小任务
连接外部服务不仅仅是调用它：
- 向服务提供商创建账户并完成验证，通常需要提交企业文件。
- 在获得生产环境访问权限前完成审批或审核——支付服务提供商尤其如此。
- 凭证管理，测试环境和生产环境需要分别管理。
- 处理服务提供商可能产生的每一种失败情况：拒绝、超时、部分成功、重复提交。
- 对账——将服务提供商所称发生的情况与应用程序记录的情况进行匹配。
- 针对沙箱环境进行测试，但沙箱的行为与生产环境不同。
真正的工作量集中在最后两项，而它们在功能列表中通常是不可见的。
应尽早启动的前置周期
这些是日历上的事项，而不是开发事项，应在项目启动时开始：
- 支付服务提供商。商户账户申请需要企业注册信息、银行资料，有时还需要进行商业模式审核。周期可能从几天到几周不等，某些业务类别也可能被拒绝——在围绕某个服务提供商进行设计前，最好先确认其是否接受你的业务。
- 消息服务。在许多市场，短信需要注册发送方标识并预先审批模板，这是一个有正式流程且有自身排队周期的过程。
- 平台集成。连接成熟的生态系统通常需要经过验证的账户，并且可能需要审核你的使用方式。
- 企业系统。连接客户现有系统意味着需要从第三方获取访问权限、文档和测试环境，而对方的时间安排并不由你控制。这通常是整个项目中耗时最长的环节。
沙箱不是生产环境
测试环境经过了简化。以下差异经常会在正式上线时暴露出来：
- 速率限制在沙箱中通常不存在或较为宽松，而在生产环境中会很严格。
- 沙箱中的延迟较低，因此测试中从未出现的超时可能会在生产环境中发生。
- 错误类型更少——沙箱只能产生少数几种场景，而生产环境可能产生许多种。
- 沙箱中的数据验证有时更宽松，因此真实数据可能因测试从未揭示的原因而被拒绝。
实际可行的缓解措施是在上线前进行生产环境冒烟测试：使用真实凭证执行少量真实交易，并端到端完成验证，包括对账。
针对必然发生的失败进行设计
外部依赖在某个时刻必然会不可用。届时应该如何处理，是设计决策，而不应由意外决定：
- 用户的操作应失败，还是进入队列？支付必须明确失败。通知则可以进入队列并重试。
- 用户会看到什么？具体的提示信息远胜于笼统的错误信息，也能减少支持工作量。
- 该操作是否可以安全重试？支付和消息 API 通常支持幂等键，使重试请求不会造成重复扣款。任何涉及资金的操作都不能省略这一机制。
- 如何发现问题？集成产生的错误应记录并触发告警，而不应被静默吞掉。
版本控制，以及你没有进行的变更
服务提供商会更改其 API。版本会提前通知弃用，而通知会通过电子邮件发送给注册账户的人——这也是账户应由客户持有的另一个原因。
两个习惯可以防止由此造成的中断：固定使用特定的 API 版本，而不是自动追踪最新版本；确保账户的通知地址能够触达会采取行动的人。由于已按公开计划停止支持弃用版本而导致集成停止工作，是可以避免的故障。
成本
第三方服务通常按使用量收费，而这往往是小型应用中最大的经常性成本。在作出承诺前，值得确认以下事项：
- 定价模式——按交易、按消息、按 API 调用或按活跃用户计费。
- 是否存在免费层级，以及达到其上限后会发生什么。
- 使用量达到当前的十倍时，成本如何增长。
- 是否存在最低消费或月度承诺。
在试点使用量下成本低廉的 AI 或消息集成，在规模扩大后可能成为主要运营成本，而提前了解这一点可能会改变服务提供商的选择。
Manboo 相关服务
- 面向 iOS 和 Android MVP 的 Flutter 应用开发。
- 面向 CRM、预订、库存和工作流系统的 业务软件开发。
- 面向运营仪表板和后台管理的 管理面板开发。
- 当你的产品准备好实现智能搜索、聊天或自动化时，选择 AI API 集成。
- 准备规划首个版本时，申请范围评审和项目估算。