订单处理方法及装置与流程

本申请涉及互联网技术领域，尤其涉及一种订单处理方法及装置。

背景技术：

随着互联网技术的发展以及各种智能终端的普及，依存于智能终端的互联网类应用(aplcation，app)越来越多。通过互联网类app，用户可以在足不出户的情况下获取各种网络服务，例如购买商品、叫餐等。

用户使用互联网类app获取网络服务的过程一般是：选择商品或服务，提交订单，付款，等待收货。为了保证用户的权益，互联网类app一般允许用户取消订单。例如，用户通过一电商的购物app下单购买了一件商品，发现买错了，则可以申请取消订单，避免不必要的花费。又例如，用户通过一外卖app下单点了一份外卖，等了很长时间都没有送到，则可以申请取消订单。

随着订单数量的增加，取消订单的数量也越来越多。为了提高用户及商户的体验，及时且合理地处理取消订单的申请成为互联网类app面临的一大问题。

技术实现要素：

本申请发明人对现有互联网类app进行了跟踪调研，发现：现有互联网类app主要采用以下两种方式处理取消订单的申请：

第一种方式：用户申请取消订单，服务端将用户的取消订单申请推送至商户端，商户手动刷新订单状态，当看到取消订单申请时手动处理该取消订单。

第二种方式：用户申请取消订单，服务端直接默认商户同意取消订单，并向商户端发送订单取消通知消息。

在跟踪调研过程中，本申请发明人还发现：商户手动处理取消订单的方式，处理效率较低，如果商户端未能及时处理用户的取消订单申请，用户就会等待较长时间，用户体验较差。直接默认商户同意取消订单的方式，用户的取消订单申请能够得到及时处理，用户体验较好，但容易出现不合理取消订单的情况，商户利益严重受损。

由此可见，需要本领域技术人员付出创造性劳动提供一种解决方案，既能保证及时处理用户的取消订单申请，又能保证订单取消的合理性，同时保证用户体验和商户利益。

本申请发明人在付出大量创造性劳动后给出了一种解决方案，其主要原理是：制定多级最迟响应时间；当接收到用户的取消订单申请时，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间；在所确定的最迟响应时间内等待商户端处理待取消订单，若在所确定的最迟响应时间内商户端未处理待取消订单，则默认商户同意取消订单，这样既可以给商户留出时间处理，保证商户的利益，又可以保证用户的取消订单申请在合理时间范围内得到响应，同时保证了用户体验和商户利益。

基于上述，本申请实施例提供一种订单处理方法，包括：

根据用户端的取消订单申请，确定待取消订单；

从多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间；

若在与所述待取消订单相匹配的最迟响应时间内，商户端未处理所述待取消订单，通知所述用户端订单取消成功。

在一可选实施方式中，所述从多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间，包括：根据所述待取消订单的关联信息，从所述多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间。

在一可选实施方式中，所述根据所述待取消订单的关联信息，从所述多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间，包括：根据响应等级与关联信息的对应关系，确定所述待取消订单的关联信息匹配中的响应等级；从所述多级最迟响应时间中，获取所述待取消订单的关联信息匹配中的响应等级对应的最迟响应时间。

在一可选实施方式中，所述根据所述待取消订单的关联信息，从所述多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间，包括：根据所述待取消订单的关联信息，确定所述待取消订单的优先级；根据响应等级与订单优先级的对应关系，确定所述待取消订单的优先级匹配中的响应等级；从所述多级最迟响应时间中，获取所述待取消订单的优先级匹配中的响应等级对应的最迟响应时间。

在一可选实施方式中，所述待取消订单的关联信息包括：所述待取消订单的属性信息、所述用户端的属性信息以及所述商户端的属性信息中的至少一种。

在一可选实施方式中，在通知所述用户端订单取消成功之后，所述方法还包括：标记所述待取消订单的状态为已处理。

在一可选实施方式中，在通知所述用户端订单取消成功之前，所述方法还包括：向所述商户端推送订单取消消息，以提示所述商户端处理所述待取消订单。

在一可选实施方式中，所述方法还包括：接收所述商户端根据所述订单取消消息和/或定时触发而发送的网络查询请求；根据所述网络查询请求，向所述商户端发送当前尚未处理的待取消订单的数量。

本申请前述实施例提供的解决方案主要由服务端实施，为了配合前述实施例以提供更好的订单处理效果，本申请发明人还针对商户端提供了一种解决方案，其主要原理是：为了保证商户端能够可靠地收到用户申请取消订单的信息，结合来自于商户端和服务端双方的订单处理触发事件，并在触发事件的触发下通过网络服务请求向服务端请求尚未处理的待取消订单的数量，在数量不为0的情况下，提示商户进行处理，这样便于商户可靠、准确地获知是否存在尚未处理的待取消订单，以商户端能够及时进行订单处理，提高订单处理的效率和及时性。

基于上述，本申请实施例还提供一种订单处理方法，包括：

对商户端的订单处理触发事件以及来自服务端的订单处理触发事件进行监听；

当监听到所述商户端的和/或来自所述服务端的订单处理触发事件时，向所述服务端发送网络查询请求；

接收所述服务端返回的当前尚未处理的待取消订单的数量；

若所述数量大于0，提示商户处理所述当前尚未处理的待取消订单。

在一可选实施方式中，所述商户端的订单处理触发事件为：定时轮询事件；所述来自服务端的订单处理触发事件为所述服务端推送订单取消消息的事件。

在一可选实施方式中，提示商户处理所述当前尚未处理的待取消订单之后，所述方法还包括：响应于所述商户的处理操作，向所述服务端发送处理请求；接收所述服务端发送的订单处理异常通知消息；根据所述订单处理异常通知消息，提示所述商户订单处理异常。

在一可选实施方式中，所述根据所述订单处理异常通知消息，提示所述商户订单处理异常，包括：根据所述订单处理异常通知消息，确定订单处理异常的类型；采用与所述订单处理异常的类型相匹配的提示方式，提示所述商户订单处理异常。

相应地，本申请实施例还提供一种订单处理装置，包括：

确定单元，用于根据用户端的取消订单申请，确定待取消订单；

获取单元，用于从多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间；

通知单元，用于若在与所述待取消订单相匹配的最迟响应时间内，商户端未处理所述待取消订单，通知所述用户端订单取消成功。

在一可选实施方式中，所述获取单元具体用于：根据所述待取消订单的关联信息，从所述多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间。

在一可选实施方式中，所述获取单元具体用于：根据响应等级与关联信息的对应关系，确定所述待取消订单的关联信息匹配中的响应等级；从所述多级最迟响应时间中，获取所述待取消订单的关联信息匹配中的响应等级对应的最迟响应时间。

在一可选实施方式中，所述获取单元具体用于：根据所述待取消订单的关联信息，确定所述待取消订单的优先级；根据响应等级与订单优先级的对应关系，确定所述待取消订单的优先级匹配中的响应等级；从所述多级最迟响应时间中，获取所述待取消订单的优先级匹配中的响应等级对应的最迟响应时间。

在一可选实施方式中，所述待取消订单的关联信息包括：所述待取消订单的属性信息、所述用户端的属性信息以及所述商户端的属性信息中的至少一种。

在一可选实施方式中，所述装置还包括：标记单元，用于在所述通知单元通知所述用户端订单取消成功之后，标记所述待取消订单的状态为已处理。

在一可选实施方式中，所述装置还包括：发送单元，用于在所述通知单元通知所述用户端订单取消成功之前，向所述商户端推送订单取消消息，以提示所述商户端处理所述待取消订单。

在一可选实施方式中，所述装置还包括：接收单元，用于接收所述商户端根据所述订单取消消息和/或定时触发而发送的网络查询请求；相应地，所述发送单元还用于：根据所述网络查询请求，向所述商户端发送当前尚未处理的待取消订单的数量。

本申请实施例还提供一种订单处理装置，包括：

监听单元，用于对商户端的订单处理触发事件以及来自服务端的订单处理触发事件进行监听；

发送单元，用于在所述监听单元监听到所述商户端的和/或来自所述服务端的订单处理触发事件时，向所述服务端发送网络查询请求；

接收单元，用于接收所述服务端返回的当前尚未处理的待取消订单的数量；

提示单元，用于在所述数量大于0时，提示商户处理所述当前尚未处理的待取消订单。

在一可选实施方式中，所述商户端的订单处理触发事件为：定时轮询事件；所述来自服务端的订单处理触发事件为所述服务端推送订单取消消息的事件。

在一可选实施方式中，所述发送单元还用于：响应于所述商户的处理操作，向所述服务端发送处理请求；

所述接收单元还用于：接收所述服务端发送的订单处理异常通知消息；

所述提示单元还用于：根据所述订单处理异常通知消息，提示所述商户订单处理异常。

在一可选实施方式中，所述提示单元具体用于：根据所述订单处理异常通知消息，确定订单处理异常的类型；采用与所述订单处理异常的类型相匹配的提示方式，提示所述商户订单处理异常。

本申请实施例还提供一种服务端设备，包括：存储器和处理器；所述存储器存储有一条或多条计算机指令，所述一条或多条计算机指令在被所述处理器执行时实现上述服务端所执行的方法中的步骤。

本申请实施例还提供一种存储有计算机程序的计算机存储介质，所述计算机程序被执行时实现上述服务端所执行的方法中的步骤。

本申请实施例还提供一种一种商户端设备，包括存储器和处理器；所述存储器存储有一条或多条计算机指令，所述一条或多条计算机指令在被所述处理器执行时实现上述商户端所执行的方法中的步骤。

本申请实施例还提供一种存储有计算机程序的计算机存储介质，所述计算机程序被执行时实现上述商户端所执行的方法中的步骤。

在本申请实施例中，在服务端，采用多级最迟响应时间，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间，在该最迟响应时间内等待商户端处理，若在该最迟响应时间内商户端未处理，则默认订单取消成功，这样既可以给商户留出时间处理，保证商户的利益，又可以保证用户的取消订单申请在合理时间范围内得到响应，同时保证用户体验和商户利益。另外，在商户端，结合来自商户端和服务端双方的订单处理触发事件触发订单处理，保证商户端能够可靠地获知尚有未处理的取消订单申请，进而配合服务端的多级最迟响应机制，进一步提高订单处理的及时性和可靠性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一实施例提供的订单处理方法的流程示意图；

图2为本申请另一实施例提供的订单处理方法的流程示意图；

图3为本申请又一实施例提供的订单处理方法的流程示意图；

图4为本申请又一实施例提供的订单处理方法的流程示意图；

图5a为本申请又一实施例提供的订单处理方法的流程示意图；

图5b为本申请又一实施例提供的取消订单列表页的样式示意图；

图5c为本申请又一实施例提供的订单详情页的样式示意图；

图6为本申请又一实施例提供的订单处理方法的流程示意图；

图7为本申请又一实施例提供的订单处理装置的结构示意图；

图8为本申请又一实施例提供的订单处理装置的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1为本申请一实施例提供的订单处理方法的流程示意图。如图1所示，所述方法包括：

101、根据用户端的取消订单申请，确定待取消订单。

102、从多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间。

103、若在与所述待取消订单相匹配的最迟响应时间内，商户端未处理所述待取消订单，通知所述用户端订单取消成功。

参见步骤101，用户端下单后，可以向服务端发送取消订单申请，以申请取消订单。对服务端来说，可以接收用户端发送的取消订单申请，该取消订单申请携带有待取消订单的订单号。基于此，服务端可以根据取消订单申请，确定待取消订单。

在本实施例中，服务端采用多级最迟响应时间机制，不同最迟响应时间的响应等级不同。对不同响应等级的最迟响应时间来说，其区别在于响应时间的长短不同。一般来说，响应等级越高，最迟响应时间越短；响应等级越低，最迟响应时间越长。假设响应等级从高到低依次为第一响应等级，第二响应等级以及第三响应等级；则按照响应等级从高到低的顺序，响应等级对应的最迟响应时间依次为1分钟，5分钟，14分钟。这里以响应等级包括三个等级为例进行说明，但并不限于三个响应等级，具体可视应用场景而定。最迟响应时间是指用户提交取消订单申请后，留给商户端进行处理的最大时间范围，也是默认商户同意取消订单所需等待的最长时间。

值得说明的是，在特殊情况下，允许最高响应等级对应的最迟响应时间为0，这种情况可适用于一些特殊用户或特殊订单的取消申请。这意味着，服务端接收到用户提交的取消订单申请时，立即默认商户端同意取消订单，以保证该用户的体验。

参见步骤102，基于步骤101中确定的待取消订单，可以从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间。在与待取消订单匹配的最迟响应时间内，等待商户端处理待取消订单。商户端对待取消订单的处理包括同意取消所述待取消订单，或者拒绝取消所述待取消订单。

在与待取消订单匹配的最迟响应时间内，商户端可能处理待取消订单，也可能因为各种原因未处理待取消订单。若与待取消订单匹配的最迟响应时间内，商户端未处理待取消订单，则为了避免用户因长时间得不到响应导致用户体验较差的问题，默认商户同意取消待取消订单，则可参见步骤103，通知用户端订单取消成功。

可选地，通知用户端订单取消成功的方式可以是：以发消息的方式，通知用户端订单取消成功；和/或，以打电话的方式，通知用户端订单取消成功。

在本实施例中，服务端采用多级最迟响应时间，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间，在该最迟响应时间内等待商户端处理，若在该最迟响应时间内商户端未处理，则默认订单取消成功，这样既可以给商户留出时间处理，保证商户的利益，又可以保证用户的取消订单申请在合理时间范围内得到响应，同时保证用户体验和商户利益。

在上述实施例或下述实施例中，需要从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间。一种可选实施方式包括：根据待取消订单的关联信息，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间。其中，待取消订单的关联信息包括：待取消订单的属性信息、用户端的属性信息以及商户端的属性信息中的至少一种。

可选地，待取消订单的属性信息可以包括但不限于：待取消订单的下单时间、送单地址、用户的备注信息、订单号和/或预计送达时间等。

用户端的属性信息可以包括但不限于：用户标识、用户等级、用户的生命周期和/或用户的交易偏好等。用户的生命周期可以是进入期、成长期、稳定期、衰退期或流失期。

商户端的属性信息可以包括但不限于：商户标识、商户等级、商户类型和/或商户价值等。商户类型可以根据配送渠道来区分。例如，将采用系统提供的配送渠道的商户定义为系统配送类型的商户，将采用自身提供的配送渠道的商户定义为自配送类型的商户。商户价值主要是指商户给系统带来的商业价值。

在一示例中，预先设置响应等级与关联信息的对应关系。基于此，根据响应等级与关联信息的对应关系，确定待取消订单的关联信息匹配中的响应等级；从多级最迟响应时间中，获取待取消订单的关联信息匹配中的响应等级对应的最迟响应时间，即为与待取消订单匹配的最迟响应时间。

示例1：假设与响应等级对应的关联信息为下单的时间范围，则下单时间所属的时间范围不同，会对应不同的响应等级。例如，共设置三个响应等级，从高到低依次为第一响应等级、第二响应等级以及第三响应等级。按照响应等级从高到低的顺序，与三个响应等级对应的下单的时间范围分别为：10:00-20:00，6:00-9:00，21:00-5:00。则下单时间在10:00-20:00这段时间内的订单对应的响应等级最高，则最迟响应时间，亦即默认商户同意取消订单所需等待时间相对最短；下单时间在6:00-9:00这段时间内的订单对应的响应等级次之，则最迟响应时间，亦即默认商户同意取消订单所需等待时间相对较长；下单时间在21:00-5:00这段时间内的订单对应的响应等级最低，则最迟响应时间，亦即默认商户同意取消订单所需等待时间相对最长。基于此，可以根据待取消订单的下单时间，确定该下单时间所属的时间范围，然后将下单时间所属的时间范围在响应等级与下单的时间范围之间的对应关系中进行匹配，以获取下单时间所属的时间范围所对应的响应等级，进而获取所确定的响应等级所对应的最迟响应时间，即为与待取消订单匹配的最迟响应时间。

示例2：假设与响应等级对应的关联信息为用户等级，则用户等级不同，会对应不同的响应等级。例如，假设共设置三个响应等级，从高到低依次为第一响应等级、第二响应等级以及第三响应等级。按照响应等级从高到低的顺序，与三个响应等级对应的用户等级分别为：第一用户等级-第三用户等级，第四用户等级-第六用户等级，第七用户等级-第十用户等级。此示例中，以十个用户等级为例进行说明，但并不限于此。则对应于第一-第三用户等级的订单对应的响应等级最高，则最迟响应时间，亦即默认商户同意取消订单所需等待时间相对最短；对应于第四-第六用户等级的订单对应的响应等级次之，则最迟响应时间，亦即默认商户同意取消订单所需等待时间相对较长；对应于第七-第十用户等级的订单对应的响应等级最低，则最迟响应时间，亦即默认商户同意取消订单所需等待时间相对最长。则可以根据待取消订单对应的用户等级，确定该用户等级对应的响应等级，进而获取所确定的响应等级所对应的最迟响应时间，即为与待取消订单匹配的最迟响应时间。

示例3：假设与响应等级对应的关联信息为用户的生命周期，则用户所处的生命周期阶段不同，会对应不同的响应等级。例如，共设置四个响应等级，从高到低依次为第一响应等级、第二响应等级、第三响应等级以及第四响应等级；相应地，用户的生命周期包括进入期、成长期、稳定期、衰退期和流失期。考虑到处于进入期和衰退期的用户对响应时间比较敏感，则处于这些生命周期的用户的取消订单申请需要及时响应，于是可以对应较高的响应等级，例如对应第一响应等级。对于处于成长期的用户来说，需要保证用户的积极性，但这些用户对响应时间的容忍度相对高一些，故可以对应相对较高的响应等级，例如对应第二响应等级。对于处于稳定期的用户来说，考虑其比较稳定，可以对应相对较低的响应等级，例如对应第三响应等级。对于处于流失期的用户来说，属于价值比较低，可以对应相对较低的响应等级，例如对应第四响应等级。

基于上述，可以将待取消用户所处的生命周期，在响应等级与用户生命周期的对应关系中进行匹配，确定匹配中的生命周期对应的响应等级；然后，获取所述确定的响应等级对应的最迟响应时间，即为与待取消订单匹配的最迟响应时间。

示例4：假设与响应等级对应的关联信息为商户类型，则商户类型不同，会对应不同的响应等级。例如，假设共设置三个响应等级，从高到低依次为第一响应等级、第二响应等级以及第三响应等级。可选地，可以设置第一响应等级为立即响应等级，比较适用于系统对配送渠道控制能力很强的场景，比较适用于系统配送类型的商户。对这类商户来说，一旦有用户申请取消订单，立即默认这类商户同意取消订单。第二响应等级对应的最迟响应时间相对较短，例如可以是30分钟，适用于系统对配送渠道控制能力不是很强，比较适用于自配送类型的商户。例如，若待取消订单关联的商户属于自配送类型的商户，且待取消订单已经超时，对于这种情况可适用于第二响应等级，即需要商户在最迟响应时间(例如30分钟内)响应用户的取消订单申请，否则默认商户同意取消订单。第三响应等级对应一较长的响应时间，例如4个小时，适用于除上述两种类型之外的其它类型的商户。如果用户提交取消订单申请，那么无论发生什么事情，需要商户在最迟响应时间(例如4个小时)内进行响应，否则默认商户同意取消订单。

在此说明，上述示例给出一些响应等级与关联信息的对应关系的举例，但并不限于此。响应等级除了与一种关联关系对应之外，也可以同时对应于几种关联关系。对本领域技术人员来说，可在上述示例的基础上做适应变形从而获得更多响应等级与关联信息的对应关系，均属于本申请实施例的保护范围。

在另一示例中，预先设置响应等级与订单优先级的对应关系。基于此，可以根据待取消订单的关联信息，确定待取消订单的优先级；根据响应等级与订单优先级的对应关系，确定待取消订单的优先级匹配中的响应等级；从多级最迟响应时间中，获取待取消订单的优先级匹配中的响应等级对应的最迟响应时间，即为与待取消订单匹配的最迟响应时间。

示例a：假设待取消订单的关联信息为下单时间，则下单时间距离当前时间越早，待取消订单的优先级越高，反之，下单时间距离当前时间越近，待取消订单的优先级越低。则可以根据待取消订单的下单时间与当前时间的时间差，确定待取消订单的优先级。

示例b：假设待取消订单的关联信息为用户等级，则用户等级越高，待取消订单的优先级越高；反之，用户等级越低，待取消订单的优先级越低。则可以根据待取消订单对应的用户等级，确定待取消订单的优先级。

示例c：假设待取消订单的关联信息为商户等级，则商户等级越高，待取消订单的优先级越高；反之，商户等级越低，待取消订单的优先级越低。则可以根据待取消订单对应的商户等级，确定待取消订单的优先级。

实例d：假设待取消订单的关联信息为用户等级和商户等级，则可以综合考虑用户等级和商户等级，确定待取消订单的优先级。其中，可以根据应用场景，对用户等级和商户等级适应性的数值处理，例如加权求和，将数据处理的结果作为待取消订单的优先级。

图2为本申请另一实施例提供的订单处理方法的流程示意图。如图2所示，所述方法包括：

201、根据用户端的取消订单申请，确定待取消订单。

202、从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间。

203、若在与待取消订单相匹配的最迟响应时间内，商户端未处理待取消订单，通知用户端订单取消成功。

204、标记待取消订单的状态为已处理。

关于步骤201-203，可参见图1所示实施例中步骤101-103的描述，在此不再赘述。

本实施例与图1所示实施例的主要区别在于：在通知用户端订单取消成功之后，标记待取消订单的状态为已处理。可选地，在通知用户端订单取消成功之前，可以标记待取消订单的状态为未处理，或不做任何标记。

在本实施例中，通过区分待取消订单的状态，一方面便于服务端管理待取消订单；另一方面，通过标记待取消订单的状态为已处理，可以避免商户端重复处理，有利于可节约资源。

图3为本申请又一实施例提供的订单处理方法的流程示意图。如图3所示，所述方法包括：

301、根据用户端的取消订单申请，确定待取消订单。

302、根据待取消订单的关联信息，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间。

303、在与待取消订单相匹配的最迟响应时间内，向商户端推送订单取消消息，以提示商户端处理待取消订单。

304、在与待取消订单相匹配的最迟响应时间内，等待商户端处理待取消订单，并确定商户端是否处理待取消订单；若否，即在与待取消订单相匹配的最迟响应时间内，商户端未处理待取消订单，执行步骤305；若是，即在与待取消订单相匹配的最迟响应时间内，商户端成功处理待取消订单，则执行步骤306。

305、在与待取消订单相匹配的最迟响应时间结束时，通知用户端订单取消成功，并继续执行步骤307。

306、在商户端成功处理待取消订单后，通知用户端订单取消成功，并继续执行步骤307。

307、标记待取消订单的状态为已处理，结束此次操作。

参见步骤301，服务端接收到用户端提交的取消订单申请后，确定待取消订单。例如，可根据取消订单申请携带的待取消订单的订单号，确定待取消订单。步骤301的具体描述可参见前述实施例，在此不再赘述。

继续参见步骤302，服务端采用多级最迟响应时间机制，不同最迟响应时间的响应等级不同。服务端根据待取消订单的关联信息，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间。步骤302的具体描述可参见前述实施例，在此不再赘述。

在本实施例中，为了便于商户端能够及时处理待取消订单，服务端在确定待取消订单之后，在与待取消订单相匹配的最迟响应时间尚未结束之前，亦即，在与待取消订单相匹配的最迟响应时间内，向商户端推送订单取消消息，如步骤303所述。

对商户端来说，可以接收服务端推送的订单取消消息。若商户端成功接收到订单取消消息，可以按照商户端的提示方式提示商户有订单取消消息到达，以便商户及时处理。当然，还有可能因为各种原因，例如网络异常、商户端设备异常等原因导致商户端未能接收到或未能及时接收到订单取消消息，进而未能及时处理待取消订单。

在商户端接收到订单取消消息的情况下，商户可以及时处理待取消订单，例如同意取消，或拒绝取消。当然，即使商户端接收到订单取消消息，商户也有可能忽略该订单取消消息而不对待取消订单做处理。

对服务端来说，可以如步骤304所述，在与待取消订单相匹配的最迟响应时间内，等待商户端处理待取消订单。若在与待取消订单相匹配的最迟响应时间内，商户端未处理待取消订单，则如步骤305和步骤307所述，在与待取消订单相匹配的最迟响应时间结束时，默认商户端同意取消订单，通知用户端订单取消成功，并标记待取消订单的状态为已处理，结束此次操作。若在与待取消订单相匹配的最迟响应时间内，商户端成功处理待取消订单，则如步骤306和步骤307所述，在商户端成功处理待取消订单后，通知用户端订单取消成功，并标记待取消订单的状态为已处理，结束此次操作。

对于商户端接收到订单取消消息并及时处理待取消订单的情况，商户端及时处理待取消订单主要是指在与待取消订单相匹配的最迟响应时间内，及时处理待取消订单。

可选地，一种在与待取消订单相匹配的最迟响应时间内及时订单取消处理流程可以是：在与待取消订单相匹配的最迟响应时间内，商户端向服务端发送网络查询请求，以便请求服务端返回尚未处理的待取消订单的数量；接收服务端返回的尚未处理的待取消订单的数量；在该数量大于0的情况下，进行订单取消处理并向服务端返回处理完成消息。对服务端来说，在与待取消订单相匹配的最迟响应时间内，需要接收商户端发送的网络查询请求；根据网络查询请求向商户端返回当前尚未处理的待取消订单的数量，并等待接收商户端返回的处理完成消息；当接收到商户端返回的处理完成消息时，确定商户端成功处理待取消订单。

对商户端来说，可以根据服务端推送的订单取消消息向服务端发送网络查询请求。当然，为了保证商户端能够可靠地获知用户申请取消订单的信息，商户端还可以结合本地的定时轮询机制，定时触发向服务端发送网络查询请求。在该情况下，上述网络查询请求可以是商户端根据接收到的订单取消消息和/或定时触发而发送的。

由上述可见，服务端采用多级最迟响应时间，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间，在该最迟响应时间内等待商户端处理，若在该最迟响应时间内商户端未处理，则默认订单取消成功；若在该最迟响应时间内商户端处理，则在商户端处理完成后通知用户；这样既可以给商户留出时间处理，保证商户的利益，又可以保证用户的取消订单申请在合理时间范围内得到响应，同时保证用户体验和商户利益。

图4为本申请又一实施例提供的订单处理方法的流程示意图。如图4所示，所述方法包括：

401、对商户端的订单处理触发事件以及来自服务端的订单处理触发事件进行监听。

402、当监听到商户端的和/或来自服务端的订单处理触发事件时，向服务端发送网络查询请求。

403、接收服务端返回的当前尚未处理的待取消订单的数量。

404、若所述数量大于0，提示商户处理所述当前尚未处理的待取消订单。

参见步骤401，结合商户端和服务端双方的订单处理触发事件，触发订单取消处理流程；于是，对商户端的订单处理触发事件以及来自服务端的订单处理触发事件进行监听。其中，商户端的订单处理触发事件可以触发订单取消处理流程；来自服务端的订单处理触发事件也可以触发订单取消处理流程。

根据应用场景的不同，商户端的订单处理触发事件以及来自服务端的订单处理触发事件会有所不同，本实施例对此不做限定。

当监听到商户端的订单处理触发事件和/或来自服务端的订单处理触发事件时，开始进行待取消订单的处理。其中，待取消订单的处理流程如步骤402-404，即向服务端发送网络查询请求，以请求当前尚未处理的待取消订单的数量；然后，接收服务端返回的当前尚未处理的待取消订单的数量；以及在所述数量大于0，提示商户处理所述当前尚未处理的待取消订单。待取消订单是指用户端申请取消的订单。

在本实施例中，为了保证商户端能够可靠地收到用户申请取消订单的信息，结合来自于商户端和服务端双方的订单处理触发事件，当监听到任意一方的订单处理触发事件时触发订单取消处理流程，这样便于商户可靠、准确地获知是否存在尚未处理的待取消订单，以便商户端及时进行订单处理，提高订单处理的效率和及时性。

在一可选实施方式中，商户端的订单处理触发事件为：定时轮询事件；来自服务端的订单处理触发事件为服务端推送订单取消消息的事件。基于此，一种订单处理方法如图5a所示，包括：

501、启动定时轮询事件。

502、判断定时轮询事件的定时是否结束；若是，执行步骤504；若否执行步骤503。

503、判断是否接收到服务端推送的订单取消消息；若是，执行步骤504；若否，返回执行步骤502。

504、向服务端发送网络查询请求。

505、接收服务端返回的当前尚未处理的待取消订单的数量。

506、判断所述数量是否大于0；若是，则执行步骤507；若否，则结束操作。

507、提示商户处理当前尚未处理的待取消订单。

在本实施例中，同时结合商户端的定时轮询事件和服务端推送订单取消消息的事件，触发订单取消处理流程。商户端的定时轮询事件会每隔一定时间，如30秒，触发一次订单取消处理流程。对于服务端推送订单取消消息的事件，商户端会在每次接收到商户端推送的订单取消消息时触发一次订单取消处理流程。

如果仅基于商户端的定时轮询事件，因为轮询有一定的时间间隔，如30秒，那么如果在所述时间间隔内，有用户申请取消订单，则无法及时收到用户申请取消订单的信息，存在信息延迟，会导致商户端无法及时处理用户的取消订单申请。如果仅基于服务端推送订单取消消息的事件，因为推送到达率不可能达到100％，会导致部分用户申请取消订单的信息未能推送至商户端，导致商户端无法及时处理用户的取消订单申请。在本实施例中，同时结合商户端的定时轮询事件以及服务端的推送事件，能够保证商户端及时、可靠地收到用户申请取消订单的信息。

在本实施例中，以先监听定时轮询事件，再监听服务端的推送事件为例进行说明，但并不限于此。这两个事件可以并行监听，也可以先监听服务端的推送事件，在监听定时轮询事件。

可选地，在提示商户处理当前尚未处理的待取消订单的时，可以采用声音提示方式，例如循环输入一段提示音，例如『用户申请取消订单，请及时处理』。

可选地，当当前尚未处理的待取消订单的数量等于0时，停止播放提示音。

除上述声音提示方式之外，当当前尚未处理的待取消订单的数量大于0时，可以根据商户端的运行状态，采用其他提示方式。可选地，如果商户端处于前台运行，则可以在商户端的界面上输出提示信息，例如在所述界面上的弹窗内展示提示信息以提醒商户；如果商户端处于后台运行，则可以通过系统通知方式，例如在系统通知栏中展示提示信息，以提醒商户。本申请实施例对提示信息的内容不做限定。例如，提示信息可以是『有顾客申请取消订单，请尽快处理，避免餐品损失』。

进一步可选地，上述提示信息可以作为商户端访问取消订单列表页的入口，例如与取消订单列表页相链接。所述取消订单列表页包含该商户端对应的所有用户申请取消的订单信息。基于此，商户可以通过点击上述提示信息，跳转到取消订单列表页。一种取消订单列表页的样式如图5b所示，该页面样式仅作为一种示例。

进一步，商户可以点击取消订单列表页上的任意订单，进而跳转到订单详情页，订单详情页会展示订单流转的详细信息。本申请实施例对订单详情页的样式不做限定，可视应用需求和场景灵活设计。例如，一种订单详情页的样式示例如图5c所示。

图6为本申请又一实施例提供的订单处理方法的流程示意图。所述方法可基于图4或图5a所述实施例的方法实现，以基于图4所示方法实现为例，如图6所示，所述方法在步骤404之后还包括：

405、响应于商户的处理操作，向服务端发送处理请求。

406、接收服务端发送的订单处理异常通知消息。

407、根据订单处理异常通知消息，提示商户订单处理异常。

在提示商户端处理当前尚未处理的待取消订单后，商户可以进行处理。商户处理当前尚未处理的待取消订单时，商户端可响应于商户的处理操作，并根据该处理操作向服务端发送处理请求，以请求服务端根据商户的处理操作，更改待取消订单的状态。

在商户端对待取消订单进行处理的过程中，可能存在各种订单处理异常的情况，例如，消息提醒异常、多设备处理异常、订单状态变化异常等。

消息提醒异常主要是指因为网络异常或商户端设备异常等，商户端收到用户申请取消订单的信息(例如订单取消消息)比较滞后，当商户端根据收到的信息去处理待取消订单时，实际上这些待取消订单可能因为匹配中的最迟响应时间到达而被默认取消，所以会发生这些待取消订单的状态不正确的异常情况，无法正常处理订单。

多设备处理异常是指商户端有多个店员具有权限处理待取消订单，当一待取消订单被其中一个店员处理掉后，另一店员再去处理的时候，就会出现已经被其它店员处理掉的异常情况，无法正常处理订单。

订单状态变化异常是指商户端处理待取消订单时，由于其它原因导致待取消订单的状态变化了，导致商户端无法正常处理订单的异常情况。

对于出现上述异常情况时，服务端可以向商户端发送订单处理异常通知消息，以提示商户端订单处理异常。相应地，商户端接收服务端发送的订单处理异常通知消息，根据订单处理异常通知消息，提示商户订单处理异常。

在一可选实施方式中，上述根据订单处理异常通知消息，提示商户订单处理异常，包括：根据订单处理异常通知消息，确定订单处理异常的类型；采用与订单处理异常的类型相匹配的提示方式，提示商户订单处理异常。

例如，若订单处理异常的类型是多设备处理异常，则可以通过弹窗方式，提示商户订单处理异常。

例如，若订单处理异常的类型是订单状态变化异常，则可以通过弹窗方式和声音提示方式，提示商户订单处理异常。

上述订单处理异常的类型与异常提示方式的对应关系仅为举例，并不限于此，具体可视应用场景灵活设定。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤101至步骤103的执行主体可以为设备a；又比如，步骤101和102的执行主体可以为设备a，步骤103的执行主体可以为设备b；等等。

图7为本申请又一实施例提供的订单处理装置的结构示意图。如图7所示，所述装置包括：确定单元71、获取单元72和通知单元73。

确定单元71，用于根据用户端的取消订单申请，确定待取消订单。

获取单元72，用于从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间。

通知单元73，用于若在与待取消订单相匹配的最迟响应时间内，商户端未处理所述待取消订单，通知用户端订单取消成功。

在一可选实施方式中，获取单元72具体用于：根据待取消订单的关联信息，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间。

在一可选实施方式中，获取单元72具体用于：根据响应等级与关联信息的对应关系，确定待取消订单的关联信息匹配中的响应等级；从多级最迟响应时间中，获取待取消订单的关联信息匹配中的响应等级对应的最迟响应时间。

在一可选实施方式中，获取单元72具体用于：根据待取消订单的关联信息，确定待取消订单的优先级；根据响应等级与订单优先级的对应关系，确定待取消订单的优先级匹配中的响应等级；从多级最迟响应时间中，获取待取消订单的优先级匹配中的响应等级对应的最迟响应时间。

在一可选实施方式中，待取消订单的关联信息包括：待取消订单的属性信息、用户端的属性信息以及商户端的属性信息中的至少一种。

在一可选实施方式中，装置还包括：标记单元，用于在通知单元通知用户端订单取消成功之后，标记待取消订单的状态为已处理。

在一可选实施方式中，装置还包括：发送单元，用于在通知单元通知用户端订单取消成功之前，向商户端推送订单取消消息，以提示商户端处理待取消订单。

在一可选实施方式中，装置还包括：接收单元，用于接收商户端根据订单取消消息和/或定时触发而发送的网络查询请求。相应地，发送单元还用于：根据网络查询请求，向商户端发送当前尚未处理的待取消订单的数量。

本实施例提供的订单处理装置，可用于执行上述图1-图3所示方法的流程，其具体工作原理在此不再赘述。

本实施例提供的订单处理装置，可位于服务端实现，或者独立于服务端但与服务端建立通信连接。

本实施提供的的订单处理装置，支持多级最迟响应时间，从多级最迟响应时间中，获取与待取消订单匹配的最迟响应时间，在该最迟响应时间内等待商户端处理，若在该最迟响应时间内商户端未处理，则默认订单取消成功；若在该最迟响应时间内商户端处理，则在商户端处理完成后通知用户；这样既可以给商户留出时间处理，保证商户的利益，又可以保证用户的取消订单申请在合理时间范围内得到响应，同时保证用户体验和商户利益。

图8为本申请又一实施例提供的订单处理装置的结构示意图。如图8所示，装置包括：监听单元81、发送单元82、接收单元83和提示单元84。

监听单元81，用于对商户端的订单处理触发事件以及来自服务端的订单处理触发事件进行监听。

发送单元82，用于在监听单元监听到商户端的和/或来自服务端的订单处理触发事件时，向服务端发送网络查询请求。

接收单元83，用于接收服务端返回的当前尚未处理的待取消订单的数量。

提示单元84，用于在数量大于0时，提示商户处理当前尚未处理的待取消订单。

在一可选实施方式中，商户端的订单处理触发事件为：定时轮询事件；来自服务端的订单处理触发事件为服务端推送订单取消消息的事件。

在一可选实施方式中，发送单元82还用于：响应于商户的处理操作，向服务端发送处理请求。接收单元83还用于：接收服务端发送的订单处理异常通知消息。提示单元84还用于：根据订单处理异常通知消息，提示商户订单处理异常。

在一可选实施方式中，提示单元84具体用于：根据订单处理异常通知消息，确定订单处理异常的类型；采用与订单处理异常的类型相匹配的提示方式，提示商户订单处理异常。

本实施例提供的订单处理装置，可用于执行上述图4-6所示的方法流程，其工作原理不再赘述。

本实施例提供的订单处理装置，可位于商户端实现，或者独立于商户端但与服务端建立通信连接。

本实施例提供的订单处理装置，结合来自商户端和服务端双方的订单处理触发事件触发订单处理，保证商户端能够可靠地获知尚有未处理的取消订单申请，进而配合服务端的多级最迟响应机制，进一步提高订单处理的及时性和可靠性。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

本申请实施例公开a1、一种订单处理方法，包括：

根据用户端的取消订单申请，确定待取消订单；

从多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间；

若在与所述待取消订单相匹配的最迟响应时间内，商户端未处理所述待取消订单，通知所述用户端订单取消成功。

a2、如a1所述的方法中，所述从多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间，包括：

根据所述待取消订单的关联信息，从所述多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间。

a3、如a2所述的方法中，所述根据所述待取消订单的关联信息，从所述多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间，包括：

根据响应等级与关联信息的对应关系，确定所述待取消订单的关联信息匹配中的响应等级；

从所述多级最迟响应时间中，获取所述待取消订单的关联信息匹配中的响应等级对应的最迟响应时间。

a4、如a2所述的方法中，所述根据所述待取消订单的关联信息，从所述多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间，包括：

根据所述待取消订单的关联信息，确定所述待取消订单的优先级；

根据响应等级与订单优先级的对应关系，确定所述待取消订单的优先级匹配中的响应等级；

从所述多级最迟响应时间中，获取所述待取消订单的优先级匹配中的响应等级对应的最迟响应时间。

a5、如a2-a4任一项所述的方法中，所述待取消订单的关联信息包括：所述待取消订单的属性信息、所述用户端的属性信息以及所述商户端的属性信息中的至少一种。

a6、如a1-a4任一项所述的方法中，在通知所述用户端订单取消成功之后，还包括：

标记所述待取消订单的状态为已处理。

a7、如a1-a4任一项所述的方法中，在通知所述用户端订单取消成功之前，还包括：

向所述商户端推送订单取消消息，以提示所述商户端处理所述待取消订单。

a8、如a7所述的方法还包括：

接收所述商户端根据所述订单取消消息和/或定时触发而发送的网络查询请求；

根据所述网络查询请求，向所述商户端发送当前尚未处理的待取消订单的数量。

本申请实施例公开b9、一种订单处理方法，包括：

对商户端的订单处理触发事件以及来自服务端的订单处理触发事件进行监听；

当监听到所述商户端的和/或来自所述服务端的订单处理触发事件时，向所述服务端发送网络查询请求；

接收所述服务端返回的当前尚未处理的待取消订单的数量；

若所述数量大于0，提示商户处理所述当前尚未处理的待取消订单。

b10、如b9所述的方法中，所述商户端的订单处理触发事件为：定时轮询事件；所述来自服务端的订单处理触发事件为所述服务端推送订单取消消息的事件。

b11、如b9所述的方法中，提示商户处理所述当前尚未处理的待取消订单之后，还包括：

响应于所述商户的处理操作，向所述服务端发送处理请求；

接收所述服务端发送的订单处理异常通知消息；

根据所述订单处理异常通知消息，提示所述商户订单处理异常。

b12、如b11所述的方法中，所述根据所述订单处理异常通知消息，提示所述商户订单处理异常，包括：

根据所述订单处理异常通知消息，确定订单处理异常的类型；

采用与所述订单处理异常的类型相匹配的提示方式，提示所述商户订单处理异常。

本申请实施例公开c13、一种订单处理装置，包括：

确定单元，用于根据用户端的取消订单申请，确定待取消订单；

获取单元，用于从多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间；

通知单元，用于若在与所述待取消订单相匹配的最迟响应时间内，商户端未处理所述待取消订单，通知所述用户端订单取消成功。

c14、如c13所述的装置中，所述获取单元具体用于：

根据所述待取消订单的关联信息，从所述多级最迟响应时间中，获取与所述待取消订单匹配的最迟响应时间。

c15、如c14所述的装置中，所述获取单元具体用于：

根据响应等级与关联信息的对应关系，确定所述待取消订单的关联信息匹配中的响应等级；

从所述多级最迟响应时间中，获取所述待取消订单的关联信息匹配中的响应等级对应的最迟响应时间。

c16、如c14所述的装置中，所述获取单元具体用于：

根据所述待取消订单的关联信息，确定所述待取消订单的优先级；

根据响应等级与订单优先级的对应关系，确定所述待取消订单的优先级匹配中的响应等级；

从所述多级最迟响应时间中，获取所述待取消订单的优先级匹配中的响应等级对应的最迟响应时间。

c17、如c14-c16任一项所述的装置中，所述待取消订单的关联信息包括：所述待取消订单的属性信息、所述用户端的属性信息以及所述商户端的属性信息中的至少一种。

c18、如c13-c16任一项所述的装置还包括：

标记单元，用于在所述通知单元通知所述用户端订单取消成功之后，标记所述待取消订单的状态为已处理。

c19、如c13-c16任一项所述的装置还包括：

发送单元，用于在所述通知单元通知所述用户端订单取消成功之前，向所述商户端推送订单取消消息，以提示所述商户端处理所述待取消订单。

c20、如c19所述的装置还包括：

接收单元，用于接收所述商户端根据所述订单取消消息和/或定时触发而发送的网络查询请求；

所述发送单元还用于：根据所述网络查询请求，向所述商户端发送当前尚未处理的待取消订单的数量。

本申请实施例公开d21、一种订单处理装置，包括：

监听单元，用于对商户端的订单处理触发事件以及来自服务端的订单处理触发事件进行监听；

发送单元，用于在所述监听单元监听到所述商户端的和/或来自所述服务端的订单处理触发事件时，向所述服务端发送网络查询请求；

接收单元，用于接收所述服务端返回的当前尚未处理的待取消订单的数量；

提示单元，用于在所述数量大于0时，提示商户处理所述当前尚未处理的待取消订单。

d22、如d21所述的装置中，所述商户端的订单处理触发事件为：定时轮询事件；所述来自服务端的订单处理触发事件为所述服务端推送订单取消消息的事件。

d23、如d21所述的装置中，所述发送单元还用于：响应于所述商户的处理操作，向所述服务端发送处理请求；

所述接收单元还用于：接收所述服务端发送的订单处理异常通知消息；

所述提示单元还用于：根据所述订单处理异常通知消息，提示所述商户订单处理异常。

d24、如d23所述的装置中，所述提示单元具体用于：

根据所述订单处理异常通知消息，确定订单处理异常的类型；

采用与所述订单处理异常的类型相匹配的提示方式，提示所述商户订单处理异常。

本申请实施例还公开e25、一种服务端设备，包括：存储器和处理器；所述存储器存储有一条或多条计算机指令，所述一条或多条计算机指令在被所述处理器执行时实现上述a1-a8任一项所述方法中的步骤。

本申请实施例还公开f26、一种存储有计算机程序的计算机存储介质，所述计算机程序被执行时实现上述a1-a8任一项所述方法中的步骤。

本申请实施例还公开g27、一种商户端设备，包括存储器和处理器；所述存储器存储有一条或多条计算机指令，所述一条或多条计算机指令在被所述处理器执行时实现上述b9-b12任一项所述方法中的步骤。

本申请实施例还公开h28、一种存储有计算机程序的计算机存储介质，所述计算机程序被执行时实现上述b9-b12任一项所述方法中的步骤。