对接数据库,模拟第三方接入信息
This commit is contained in:
@@ -59,8 +59,8 @@
|
||||
与 Mock 的关系:
|
||||
- Mock 用于第三方未联通阶段的替代数据源与故障注入;生产环境默认关闭。
|
||||
|
||||
### 方案 B:商家自选配送(商家自找承运方 / 平台只做订单)
|
||||
适用:平台招商、品类/区域差异大、平台希望给商家“选择承运方”的灵活性。
|
||||
### 方案 B:商家自选配送(商家自选承运商并发货 / 平台负责运单绑定与轨迹展示)
|
||||
适用:平台招商、品类/区域差异大、平台希望给商家“选择承运方”的灵活性;平台不承担“实际配送执行”,但需要提供统一的运单绑定入口与轨迹展示底座。
|
||||
|
||||
重要说明(商家只是平台商户的常见情况):
|
||||
- 默认不要求商家自建系统或自行对接第三方 API。
|
||||
@@ -75,6 +75,30 @@
|
||||
- 在平台选择承运方并完成发货动作:提供/回填 `tracking_no` 与必要的订单关联信息(如 `order_no`)。
|
||||
- 若商家坚持使用“商家与第三方的独立合同/账号”,可向平台提交第三方对接所需材料,由平台统一配置与代接入(不要求商家自建回调服务)。
|
||||
|
||||
可选增强:商家在平台内“自助对接第三方”(无需商家开发)
|
||||
- 定位:可选增强能力,非一期必做。
|
||||
- 目标:让商家在平台后台完成第三方账号授权/配置,从而在平台内完成下单打单、获取运单号、查询/订阅轨迹;平台仍统一入库与展示。
|
||||
- 常见两种形态(可二选一,也可并存):
|
||||
1) 聚合平台授权开通(推荐优先):平台统一对接一家聚合服务商;商家在平台内完成开通/授权后即可使用多家快递能力。
|
||||
2) 商家自带第三方账号(BYO Account):商家已与某快递/聚合平台签约;在平台后台录入密钥或走 OAuth 授权,平台代为调用第三方 API。
|
||||
- 商家后台最小页面/流程建议:
|
||||
- 【物流渠道管理】:选择渠道类型(聚合/直连)、开启/停用
|
||||
- 【授权与密钥】:录入/更新 `appKey/appSecret/token` 或 OAuth 绑定;展示“最后一次连通性检测”结果
|
||||
- 【回调配置提示】:展示平台 Webhook 地址与白名单要求(若第三方需要配置回调)
|
||||
- 【测试与排障】:一键“连通性测试/拉取一条轨迹/模拟下单”,失败给出可读错误
|
||||
- 安全要求(必须):
|
||||
- 第三方密钥加密存储、最小权限、变更审计;仅商家管理员可配置。
|
||||
- 不在前端暴露密钥;平台服务端代调用第三方接口。
|
||||
- 轨迹/运单数据仍写入平台统一表结构与事件模型,避免不同渠道把差异带到前端。
|
||||
|
||||
是否需要做(决策建议):
|
||||
- 暂不需要(建议先不做)的场景:一期目标仅是“商家回填运单号 + 平台展示第三方轨迹关键节点”,且商家规模不大/对接资源有限。
|
||||
- 建议需要(做了收益明显)的场景:商家量大且运单号回填错误率高、客服投诉“查不到物流/不更新”多;或明确要上“电子面单/平台一键下单”。
|
||||
- 推荐分期:
|
||||
- Phase 1:回填运单号 + 轨迹接入与统一展示底座(本项目当前优先级)。
|
||||
- Phase 2:先接入 1 家聚合平台做统一下单/面单/轨迹(降低多家直连成本)。
|
||||
- Phase 3:再开放 BYO Account(商家自带账号)自助配置(安全与运维成本最高)。
|
||||
|
||||
优点:平台轻、商家灵活。
|
||||
风险/成本:体验碎片化风险大;如果不强制回传规范,平台客服/前端会被迫处理多样差异,长期维护成本更高。
|
||||
|
||||
@@ -85,6 +109,18 @@
|
||||
- `tracking_no`:运单号生成与回传方式(商家生成/第三方返回/平台生成)。
|
||||
- 订单关联信息:`order_no`(或平台侧可解析的业务单号),用于把轨迹绑定到订单详情页。
|
||||
|
||||
运单号(`tracking_no`)获取方式(两种常见落地,二选一或并存):
|
||||
1) 回填运单号(最小模式,推荐先上线):
|
||||
- 商家在线下/快递官方系统/聚合平台完成下单与交接,获得运单号。
|
||||
- 商家在平台后台“发货”时选择承运商并回填 `tracking_no`。
|
||||
- 平台不需要调用第三方“下单/面单”接口,只需后续接入轨迹(Webhook/轮询)用于展示。
|
||||
2) 电子面单 / 在线下单(增强模式,体验更好):
|
||||
- 平台(或平台集成的服务商)需要对接第三方提供的“下单/面单”接口,向第三方提交发货所需信息(收件人/地址/重量/件数等),并获得:运单号 `tracking_no` + 面单文件/面单号等。
|
||||
- 第三方可以是:
|
||||
- 直连快递公司接口(每家快递一套协议);或
|
||||
- 快递聚合平台接口(一套协议覆盖多家快递)。
|
||||
- 兜底策略建议:若第三方下单失败/超时,允许商家改为“手工回填运单号”完成发货闭环。
|
||||
|
||||
轨迹数据接入方式(平台统一接入,推荐第一种):
|
||||
1) 第三方 -> 平台 Webhook 推送(推荐):
|
||||
- 平台与第三方完成订阅/回调配置;第三方直接回调平台 Webhook。
|
||||
|
||||
Reference in New Issue
Block a user