订单状态同步服务

订单状态同步服务

简介

为及时获取订单状态和信息，用于对员工或用户的用车权限进行管控或对账，滴滴提供订单状态同步服务。订单状态同步需由订单状态回调和轮询同时进行。

说明

1. 接入方可以在管理中心的应用详情中开启应用的回调服务，请务必配置有效的回调地址。当产生需要通知回调的场景时，滴滴侧服务端将进行回调。
2. 收到回调通知后，请按照规定返回回调结果。通过该接口获取订单的最新信息。建议记录在本地数据库中，供后续对账等环节使用。
3. 为了避免由于网络等各方面因素导致的回调失败，造成双方系统的订单状态和信息不一致，建议采用回调+轮询的机制。即在回调基础上，针对未结束订单，每分钟轮询拉取一次订单详情接口，从而确保信息的一致性。直至订单到达终态后，不再进行轮询拉取。

支持场景

回调服务支持以下六类场景

• 订单中间状态流转
• 订单终态通知
• 订单支付确认通知
• 订单退款通知
• 订单改价通知
• 客服关单通知

回调服务设置

应用申请通过后，接入方可通过验证回调地址的方式开启订单回调服务，相关流程如下：

1，开启回调服务

进入开放平台管理中心，点击对应应用的详情，进入需要设置回调服务目标应用，点击回调服务下的“设置”按钮，进入如下页面

滴滴出行要求接入方填写URL

• URL是企业应用接收企业微信推送请求的访问协议和地址，支持http或https协议。

2，验证URL有效性

当点击“验证”时，滴滴出行将发送POST请求到填写的URL上，POST请求携带6个参数，

• POST请求携带header：Content-Type:multipart/form-data 。首次验证和正常回调header一致。

3， 接入方返回数据，验证生效

接入方收到请求后，如果确认此次POST请求来自滴滴出行，那么需要接入方返回以下格式json数据才能验证生效，回调服务才能开启。

4，配置回调预警接收人员信息

在正式环境下，当接入方回调频繁异常时，接入方会收到滴滴出行发送的短信和邮件。为了接入方可以正确接收。请添加开发人员的联系方式，路径如下：

进入开放平台管理中心，点进入需要配置预警的目标应用，点击“开发人员”的“设置”，填写需要接受预警人员的手机号码和电子邮箱，当回调出现问题时，滴滴出行会发送预警信息。

使用回调服务

当产生需要通知回调的场景时，滴滴出行会回调接入方。接入方收到回调后，需要重新调用订单详情接口，拉取最新的订单状态和信息，然后做相应处理。详情见接收订单状态回调。

滴滴出行服务器在2秒内收不到响应会断开连接，并重新发起请求，一共重试三次。如果在调试中，发现无法收到信息，可以检查是否信息处理超时。

当接收成功够，返回errno=0，表示接收成功。其他错误码一律当失败并重新发起重试。

同步进行轮询

成功下单后，在回调基础上，按照固定频率（参考频率每分钟1次）拉取订单详情接口，以保证与接入方的订单状态和信息保持一致。直至订单到达终态后，不再进行轮询拉取。详情见获取订单详情。

访问授权限制

• 订单接口访问频率限制
• 司机计费前（status＜500）访问限制在 10秒/次
• 司机计费后（status＞=500）访问限制在 300秒/次
• 如果超频：返回 errno: 36003

回调服务频繁失败处理办法

如果您频繁收到回调失败邮件通知，却可以正常收到回调，您可以通过以下方法排查问题。

1. 请检查返回的参数是否包括errno=0，其他结果将导致滴滴侧判断回调失败，触发回调失败邮件。
2. 请检查返回的参数是否为JSON格式，其他格式将无法校验导致回调失败。
3. 请检查返回的参数的时间是在2秒内，收到回调后超过2秒滴滴侧会自动断开连接重新触发回调。

回调相关问题

1.收不到订单状态回调通知？

客户自测回调地址的可用性，防火墙是否拦截

2.能收到订单状态通知，但是获取的数据为空？

回调请求header中的content-type是content-type:multipart/form-data

3.用车时未收到任何回调?

1.检查是否填写回调地址notify_url 2.检查创建的应用是否为"企业用车"

4.新增&修改回调地址不成功?

见文档使用回调服务 注意： 回调服务一定要返回errno=0才能增加或者修改回调服务地址成功

5.用车时回调失败?

1.检查配置的回调地址是否可用(自己curl一次)
2.针对回调邮件报警或者多次重复回调：看看服务的response是什么。必须返回errno=0才算成功，否则会继续回调
3.自己登录开放平台查看此订单回调的日志