规划你的 eSIM 集成
公开的 eSIM API 访问尚不可用。本指南帮助你为 eSIM 专员准备集成需求简报。在实现请求或指派代理构建集成之前,请先确认访问权限并获取受支持的 API 合约。
定义客户和服务
明确谁购买服务、谁使用设备、谁付款。一笔旅行购买可能归属于一个客户账户。员工服务还需要将其分配给具体人员,并指定一位有权批准变更的负责人。
列出你的应用程序需要关联的记录:购买、已安装的配置文件及其配额。周期性移动服务还需要订阅者的持续套餐关系。这些是需要与接收服务的合约进行确认的需求。
明确购买结果
确定客户在哪里看到所选的套餐、覆盖范围、有效期和公示价格。保持报价货币不变。你的应用程序不得从批发成本或估算的货币转换来反推客户价格。
针对每笔购买,定义客户在接受、履约或拒绝后看到的内容。在集成需求简报中包含响应丢失的情况。在设计可能产生重复扣费的重试逻辑之前,先确认 API 如何识别已有操作。
完成结账并不代表设备已安装或使用了该服务。在客户旅程中将这些结果分开处理。
规划安装和支持
选择支持的设备以及负责帮助客户连接的人员。安装凭证需要通过私密、已授权的传递路径分发,不要将其暴露在分析数据、公开示例和支持截图中。
列出客户在购买后需要的信息:设置说明、已购套餐、配额观测数据和支持联系方式。在设计状态展示之前,先确认服务能提供哪些状态和观测时间。
确定实施检查清单
请你的 Bird 专员确认适用市场、可选套餐、访问要求以及针对你的使用场景发布的操作。获取请求和响应定义、授权要求、重试行为和支持的安装方式。
合约可用后,将合约和你的应用程序的身份模型提供给编码代理。让它追踪一笔购买直至确认结果,并覆盖被拒绝的请求和不确定的响应。在向客户提供服务之前,使用明确授权的账户和设备进行测试。
将获客与结果关联
在注册和应用程序的客户旅程中保留允许的营销活动上下文。定义哪个记录的结果将被计为转化,例如已履约的购买或经验证的首次使用。仅在注册 URL 上附加营销活动标识符并不能证明后续购买已被正确归因。