在选择 API 之前先描述业务事件
B2B 结账可能涉及约定价格、采购订单、审批额度和付款条款。先从一个工作流开始，并指明所涉及的系统。例如：经批准的买家下单，财务系统予以记录，仓库再将履约状态返回给客户门户。
本文描述的是一个规划示例，而非已完成的客户项目。同样的准备工作也适用于 CRM、付款和预订集成：识别事件、权威数据，以及一次成功交接意味着什么。
准备一份集成简报
- 系统与访问权限： 指明平台、账户套餐、API 版本、文档和沙箱。确认计划使用的端点和权限可用。
- 数据归属： 确定哪个系统拥有客户身份、价格、库存、订单状态和付款状态。提供删除了个人数据的代表性记录。
- 映射： 定义共享标识符、必填字段、货币、税务处理和时区。记录无法匹配的产品或客户应如何处理。
- 异常： 包括取消、部分履约、付款失败、价格变更以及下游系统不可用的情况。
- 运营： 确定由谁来审查失败、可以重放传输并批准更正。
假设通知可能重复或延迟到达
Webhook 处理需要明确的重试和重复处理策略。作为一个具体的平台示例，Stripe 在其 webhook 指南中记录了签名验证、重复事件和异步处理。付款通知应根据提供商的约定进行身份验证和处理。其他平台有各自的投递和重试规则；请逐一核实。
验收示例： 提交一个沙箱订单，将其事件投递两次，然后暂时禁用接收系统。验证订单仅创建一次、失败的传输可见，且重放能够恢复它。还要检查某家公司无法查看另一家公司的定价或订单。
商定首个版本包含的内容
一个现实的首期范围可能支持一种订单类型、一个仓库和一组已定义的状态。如果历史数据迁移、供应商入驻和特殊定价规则需要额外调研，则将它们分开处理。商定初期哪些环节是手动的，以及团队将如何衡量该集成是否减少了工作量。
交接应包括字段映射、安装说明、监控、重放流程以及平台升级的指定负责人。维护条款取决于相关系统和约定的合作方式。了解 API 开发与集成, 工作流自动化 以及 电商开发.
