饿了么开放平台订单数据补偿场景接入方案

文档说明

针对具备订单处理能力的所有第三方开发者和自研商家，本文档旨在提供订单数据补偿方案。当平台的消息推送服务出现异常时，无法推送消息给开发者，此方案将可视为“救命稻草”，如果由于未接入此方案而导致订单无法履约，平台将对服务商进行顶格违规处理，请务必注意。

背景说明

保障平台稳定运行以及推送可达性是平台义不容辞的责任，平台提供了补偿接口供开发者主动查询未处理的订单，希望高质量的开发者能积极主动对接，同时订单推拉结合也是必须要接入的：(必接)订单推拉结合接入场景方案。

接口详情

接口权限申请路径：管理中心-我的应用-权限升级-数字化工具-推拉结合专项

接口调用时机

方案A：日常 无需调用，只有 故障 (平台侧消息推送功能出现异常无法推送消息) 时才需调用，频率规则参考「接口调用频率」段落。

或者

方案B：作为日常任务轮询调用，不区分场景。调用频率规则参考「接口调用频率」段落 B。注意：订单业务逻辑需要增加订单号幂等逻辑，否则与「推送消息补偿」获取到同一个订单，会处理异常。

接口调用频率

方案A：可做成开关形式。默认调用频率：日常，开关打开后切换为 故障 频率：日常 ：无需调用；故障 ：根据自建告警 or 平台侧通知，平台侧消息推送功能出现异常无法推送消息：轮询调用获取数据，每次请求之间间隔 1 秒（因为订单 5 分钟未接单会自动拒单，故障时异常数据会比较多，所以需要尽快的拿到数据进行）；

方案B：不做成开关形式。接口返回数据为空则等待 2 分钟后重试，接口返回数据不为空则间隔 1 秒后重试。

接口使用说明

调用eleme.order.getUnprocessOrders接口会返回未处理订单（用户下单已支付但商家未接单）的orderId，也就是订单status = unprocessed，当有数据返回时，可以调用eleme.order.confirmOrderLite进行接单

调用 eleme.order.getCancelOrders 接口会返回未处理取消单的orderId，也就是订单status = refunding& refundStatus = applied，当有数据返回时，可以调用eleme.order.agreeRefundLite同意取消单 或者 调用eleme.order.disagreeRefundLite不同意取消单

调用 eleme.order.getRefundOrders 接口会返回未处理退单的orderId，也就是订单status = settled & refundStatus = applied，当有数据返回时，可以调用eleme.order.agreeRefundLite同意退单 或者 调用eleme.order.disagreeRefundLite不同意退单

取消单：订单在完结状态之前，用户发起取消订单请求，称之为取消单，属于交易售中流程。退单：订单在完结状态之后，用户发起的取消订单请求，称之为退单，类比在商场购物后退货行为，属于交易售后流程

更新记录

V1.0（2023-04-23）

文档发布

V1.1（2023-06-30）

接口调用频率新增需要间隔 1 秒的限制，防止平台侧服务器负载过高

V1.2（2023-07-19）

接口调用频率 新增 不做成开关形式。

V1.3（2023-11-13）

方案 B 中的：接口返回数据为空则等待 1 分钟后重试 -> 接口返回数据为空则等待 2 分钟后重试

FAQ

Q：eleme.order.getUnprocessOrders接口如何测试？

A：可以在沙箱环境取消type=217消息订阅，模拟平台消息推送服务异常，不推送消息的场景，然后沙箱环境店铺下单，调用该接口后可以获取到未接单订单。

Q：订单数据补偿 有什么作用？

A：当平台的消息推送服务出现异常时，无法推送消息给开发者，这时候则需要通过该方案提供的接口去获取待接单订单，进行兜底操作，保证订单被履约；

Q：推送消息数据补偿 和 订单数据补偿 有什么区别？

A：前者是防止开发者服务异常(无法接受平台的消息推送)时订单无法被履约，后者是防止平台异常(无法推送消息)时订单无法被履约。两个方案都对接后，则能够保证绝大部分情况下订单都被履约。