CN107833113A - 异常订单处理方法、装置及电子设备 - Google Patents

Abstract

本发明提供了一种异常订单处理方法、装置及电子设备，涉及互联网领域，以缓解现有技术中人工处理方式存在的效率低下，用户体验度较差的技术问题，能够改善用户体验度。其中，该异常订单处理方法包括：每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单；获取与上述业务订单对应的支付订单；根据上述支付订单的未成功支付状态，调取与上述支付订单对应的支付通道订单查询接口；根据上述支付订单的已支付信息，对上述业务订单的订单状态进行更新。

Description

异常订单处理方法、装置及电子设备

技术领域

本发明涉及互联网技术领域，尤其是涉及一种异常订单处理方法、装置及电子设备。

背景技术

随着互联网的发展，电子商务得到了巨大的发展，各种电商平台进入人们的生活。当代社会，越来越多的用户在网上购买商品，而商品购买的核心在于商品支付，一个商品支付成功与否决定着商品的交易是否有效。因此支付对于电商平台无疑是重中之重，但现实的支付上面仍然存在着一定的不稳定性因素。

用户通过支付购买商品时，偶尔会出现由各种不稳定因素造成钱支付成功，比如支付平台的不稳定性或者服务器的临时问题，造成的扣款成功，而订单却没成功的情况，这就导致了异常订单的出现，从而对用户及时使用产品带来了不便，影响了用户购物体验。目前，现有的异常订单处理方式主要是依靠人工的方式进行手动补单，耗时较长，处理效率低下，也会影响用户的购物体验。

综上所述，现有的人工对异常订单的处理方式存在效率低下，用户体验度较差的问题。

发明内容

有鉴于此，本发明的目的在于提供异常订单处理方法、装置及电子设备，以缓解现有技术中人工处理方式存在的效率低下，用户体验度较差的技术问题，能够改善用户体验度。

第一方面，本发明实施例提供了一种异常订单处理方法，包括：

每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单；

获取与所述业务订单对应的支付订单；

根据所述支付订单的未成功支付状态，调取与所述支付订单对应的支付通道订单查询接口；

根据所述支付订单的已支付信息，对所述业务订单的订单状态进行更新。

结合第一方面，本发明实施例提供了第一方面的第一种可能的实施方式，其中，该方法还包括：

获取所述业务订单的更新结果；

当所述更新结果为失败时，向用户端发送信息以提示用户进行处理。

结合第一方面，本发明实施例提供了第一方面的第二种可能的实施方式，其中，该方法还包括：

对支付状态为未支付的支付订单进行处理。

结合第一方面的第二种可能的实施方式，本发明实施例提供了第一方面的第三种可能的实施方式，其中，所述对支付状态为未支付的支付订单进行处理，具体包括：

每间隔第二预设时间，查询并获取过去第二设定时间段内的支付状态为未支付的支付订单；

调取与所述支付订单对应的支付通道查询接口，判断所述支付订单是否已支付成功；

当所述支付订单是已支付成功时，调取业务订单接口，查询与所述支付订单对应的业务订单；

对所述业务订单的订单状态进行更新。

结合第一方面，本发明实施例提供了第一方面的第四种可能的实施方式，其中，所述设定时间段的时长大于所述预设时间的时长。

结合第一方面，本发明实施例提供了第一方面的第五种可能的实施方式，其中，该方法还包括：

获取目标项目的所有订单，将所述订单进行分类，得到业务订单数据池以及支付订单数据池；

建立业务订单数据池与支付订单数据池的对应关系。

结合第一方面的第五种可能的实施方式，本发明实施例提供了第一方面的第六种可能的实施方式，其中，该方法还包括：

每间隔预设周期对所述业务订单数据池、支付订单数据池以及所述对应关系进行更新。

第二方面，本发明实施例还提供一种异常订单处理装置，包括：

获取模块，用于每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单；

对应模块，用于获取与所述业务订单对应的支付订单；

调取模块，用于根据所述支付订单的未成功支付状态，调取与所述支付订单对应的支付通道订单查询接口；

更新模块，用于根据所述支付订单的已支付信息，对所述业务订单的订单状态进行更新。

结合第二方面，本发明实施例提供了第二方面的第一种可能的实施方式，其中，该装置还包括：

处理模块，用于获取所述业务订单的更新结果；当所述更新结果为失败时，向用户端发送信息以提示用户进行处理。

第三方面，本发明实施例还提供一种电子设备，包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述第一方面所述的方法的步骤。

第四方面，本发明实施例还提供一种具有处理器可执行的非易失的程序代码的计算机可读介质，所述程序代码使所述处理器执行上述第一方面所述的方法。

本发明实施例带来了以下有益效果：

在本发明实施例提供的异常订单处理方法中，首先通过每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单；获取与上述业务订单对应的支付订单；然后根据上述支付订单的未成功支付状态，调取与上述支付订单对应的支付通道订单查询接口；最后根据上述支付订单的已支付信息，对上述业务订单的订单状态进行更新。因此，本发明实施例提供的技术方案，缓解了现有技术中人工处理方式存在的效率低下，用户体验度较差的技术问题，能够改善用户体验度，同时，该异常订单处理方法能够及时高效的处理异常订单，减少用户因异常订单而带来的一系列问题，一方面减少用户投诉，提高了用户体验度；另一方面减轻客服工作量，减少技术人员人工手动补单次数，节省了人力成本，有利于提高商家的信誉，使整个购买流程更加流畅完善。

本发明的其他特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点在说明书、权利要求书以及附图中所特别指出的结构来实现和获得。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明具体实施方式或现有技术中的技术方案，下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施方式，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种异常订单处理方法的流程示意图；

图2为本发明实施例提供的另一种异常订单处理方法的流程示意图；

图3为本发明实施例提供的第三种异常订单处理方法的流程示意图；

图4为图3中提供的步骤S301的流程图；

图5为本发明实施例提供的异常订单处理装置的结构示意图；

图6为本发明实施例提供的电子设备的结构示意图。

具体实施方式

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

目前现有的人工对异常订单的处理方式存在效率低下，用户体验度较差的问题。基于此，本发明实施例提供的一种异常订单处理方法、装置及电子设备，缓解现有技术中人工处理方式存在的效率低下，用户体验度较差的技术问题，能够改善用户体验度。

为便于对本实施例进行理解，首先对本发明实施例所公开的一种异常订单处理方法进行详细介绍。

实施例一：

图1示出了本发明实施例提供的一种异常订单处理方法的流程示意图。如图1所示，该异常订单处理方法包括以下几个步骤：

步骤S101：每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单。

考虑到处理过程可能会产生订单遗漏的情况，这里将上述设定时间段的时长大于上述预设时间的时长。

预设时间以及设定时间段的时长可以根据实际需要设置，例如根据项目需求(例如项目的业务订单的交易频率、交易量大小等)进行设置。

鉴于预设时间不宜设置为过长或者过短，预设时间设置过长会增加电子设备(例如服务器)的工作负荷，即需要采用高性能的处理器，从而增加了电子设备的成本，预设时间设置过短，可能异常订单的数量过少，达不到预期的效果，同时会造成电子设备的持续运行，增加功耗。

因此，优选的是，上述预设时间设置为10至30分钟，上述设定时间段设置为15至35分钟。

在一个实施例中，预设时间设置为15分钟，设定时间段为20分钟。

具体的，每间隔15分钟，从业务订单数据池中查询并获取过去20分钟内的订单状态为未成功的业务订单。业务订单数据池可以是以表格的形式或者数据库的形式存储于本地磁盘或者网络平台或者项目系统中。

步骤S102：获取与上述业务订单对应的支付订单。

该步骤可以通过以下步骤实现：

a调取支付订单接口访问支付订单数据池。

b从支付订单数据池中获取与上述业务订单对应的支付订单。

需要指出的是，业务订单数据池的业务订单与支付订单数据池的支付订单是相互关联的。业务订单与支付订单可以是一对一的关系，即一个业务订单对应一个支付订单；业务订单与支付订单也可以是多对一的关系，即一个支付订单可以对应多个业务订单，例如用户支付了三个月的业务订单，业务订单可以有三个，支付订单只有一个。

步骤S103：根据上述支付订单的未成功支付状态，调取与上述支付订单对应的支付通道订单查询接口。

其中，未成功支付状态包括未支付状态或待支付状态。

具体的，该步骤主要通过以下步骤实行：

A当支付订单的支付状态为未成功支付状态时，获取支付订单的支付类型和/或支付订单号。

支付类型包括线上支付(例如第三方支付平台等)和线下支付(现金支付)；考虑到线下支付一般为人工处理，出错概率小，这里的支付类型主要针对线上支付类型。

B根据支付订单的支付类型和/或支付订单号，调取与支付订单对应的支付通道订单查询接口，查询上述支付订单是否已支付。

考虑到异常订单可能是由于系统延迟造成的支付订单的状态未及时更新，例如，用户虽然完成支付，但是系统内的支付订单的状态是未支付状态或者待支付状态等未成功支付状态，因此，该步骤通过调取与支付订单对应的支付通道订单查询接口，查询上述支付订单是否已支付的过程判断该笔业务订单是否为异常订单。

步骤S104：根据上述支付订单的已支付信息，对上述业务订单的订单状态进行更新。

具体的，根据上述支付订单的已支付信息，即上述支付订单为已支付，则确定该业务订单为异常订单，然后对上述业务订单的订单状态进行更新，实现及时对异常的业务订单进行处理。

相比于现有的人工补单的方式，该方法具有及时高效的优点，且能够减少对用户因订单失败带来的烦恼以及对商家投诉造成的商家信誉降低的问题，同时，减少了商家客服的工作量以及技术人员手动补单次数，使整个购买流程更加流畅完善。

考虑到更新状态可能出现异常的情况，例如意外掉电等突发情况可能导致的更新过程失败的情况。

进一步地，该方法还包括对更新结果进行确认的步骤：

步骤S105：获取上述业务订单的更新结果。

具体的，调取业务订单接口访问业务订单数据池，查询上述业务订单的更新字段，上述更新字段用于标识业务订单的订单更新状态(当对业务订单的订单状态进行更新时产生)，可以根据上述更新字段判断上述更新结果是否成功。

步骤S106：当上述更新结果为失败时，向用户端发送信息以提示用户进行处理。

具体的，用户端可以是手机、平板电脑、笔记本电脑、可穿戴电子设备等移动终端。这里的用户指的是技术人员、管理人员或者具有订单处理权限的客服等，实际使用时由商家根据实际需求自行设置人工处理人员。

上述信息可以是以邮件或者短信的形式发送。上述信息的内容包括但不限于异常订单的订单号以及建议处理方式。

在一个实施例中，当更新结果为失败时，向用户端发送邮件通知负责人(用户)进行人工处理。

在另一个实施例中，当更新结果为失败时，向用户端发送短信通知负责人(用户)进行人工处理。

通过上述对更新结果进行确认的步骤，可以在更新失败时，由人工进行处理，进一步保证了对异常订单的及时有效处理，避免对购买用户以及商家造成的不利后果，有利于提高用户的满意度和商家的信誉，改善两者的体验度。

需要指出的是，当上述更新结果为成功时，则返回获取与上述业务订单对应的支付订单的步骤，即处理下一笔订单状态为未成功的业务订单，直到全部处理完成后结束。

本发明实施例提供的异常订单处理方法，首先通过每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单；获取与上述业务订单对应的支付订单；然后根据上述支付订单的未成功支付状态，调取与上述支付订单对应的支付通道订单查询接口；最后根据上述支付订单的已支付信息，对上述业务订单的订单状态进行更新。因此，本发明实施例提供的技术方案，缓解了现有技术中人工处理方式存在的效率低下，用户体验度较差的技术问题，能够改善用户体验度，同时，该异常订单处理方法能够及时高效的处理异常订单，减少用户因异常订单而带来的一系列问题，一方面减少用户投诉，提高了用户体验度；另一方面减轻客服工作量，减少技术人员人工手动补单次数，节省了人力成本，有利于提高商家的信誉，使整个购买流程更加流畅完善。

实施例二：

如图2所示，本发明实施例提供了另一种异常订单处理方法，该异常订单处理方法包括：

步骤S201：获取目标项目的所有订单，将上述订单进行分类，得到业务订单数据池以及支付订单数据池。

具体实现时，可以通过爬虫技术获取目标项目的所有订单，根据上述每个订单的订单号标识对上述订单进行分类，例如可以通过聚类分析方式对上述订单进行归类，从而得到业务订单数据池以及支付订单数据池。

步骤S202：建立业务订单数据池与支付订单数据池的对应关系。

具体的，通过关联字段将业务订单数据池中的业务订单与支付订单数据池中的支付订单进行关联，建立起业务订单数据池与支付订单数据池的对应关系。

步骤S203：每间隔预设时间，从业务订单数据池中查询并获取过去设定时间段内的订单状态为未成功的业务订单。

步骤S204：从支付订单数据池中获取与上述业务订单对应的支付订单。

步骤S205：根据上述支付订单的未成功支付状态，调取与上述支付订单对应的支付通道订单查询接口。

步骤S206：根据上述支付订单的已支付信息，对上述业务订单的订单状态进行更新。

步骤S207：获取上述业务订单的更新结果，当上述更新结果为失败时，向用户端发送信息以提示用户进行处理。

考虑到业务的发展，项目的扩大，会有新的业务订单和支付订单的产生，因此，进一步的，该方法还包括定期更新订单的步骤：

步骤S208：每间隔预设周期对上述业务订单数据池、支付订单数据池以及上述对应关系进行更新。

考虑到频繁更新数据池对异常订单处理过程造成的不利影响，例如，异常订单还在处理更新，结果加入了很多新的业务订单，使处理器的工作负荷增加。因此，这里的预设周期设置为1天到3天。

本实施例中预设周期设置为1天。

通过步骤S208能够实现对业务订单数据池和支付订单数据池的自动定时更新。

需要指出的是，目标项目的所有订单也可以由人工进行分类，即通过人工的方式得到由业务订单构成的上述业务订单数据池以及由支付订单构成的支付订单数据池，并可以由人工来将业务订单与支付订单进行关联，从而建立业务订单数据池和支付订单数据池之间的对应关系。

实施例三：

图3示出了本发明实施例提供的第三种异常订单处理方法的流程示意图，参照图3，该方法基于实施例一，与实施例一的区别在于，考虑到支付订单与业务订单是一对多的关系的情形的存在，为了提高处理效率，该方法还包括：

步骤S301：对支付状态为未支付的支付订单进行处理。

具体的，对支付订单数据池中支付状态为未支付的支付订单进行处理。

如图4所示，该步骤S301主要通过以下步骤执行：

步骤S3011：每间隔第二预设时间，查询并获取过去第二设定时间段内的支付状态为未支付的支付订单。

这里同样的将上述第二设定时间段的时长大于上述第二预设时间的时长。

优选的是，上述第二预设时间设置为10至30分钟，上述第二设定时间段设置为15至35分钟。

在一个实施例中，第二预设时间设置为15分钟，第二设定时间段为20分钟。

具体的，每间隔15分钟，从支付订单数据池中查询并获取过去20分钟内的支付状态为未支付的支付订单。

步骤S3012：调取与上述支付订单对应的支付通道查询接口，判断上述支付订单是否已支付成功。

具体的，根据上述未支付的支付订单的支付订单号和/或支付类型，调取与上述未支付的支付订单对应的支付通道查询接口，判断上述未支付的支付订单是否已支付成功。

当判定上述未支付的支付订单是已支付成功时，即确定该未支付的支付订单为异常订单，则执行步骤步骤S3013；当判定上述未支付的支付订单为否时，即上述未支付的支付订单没有已支付成功，则返回步骤S3012，即判断下一笔未支付的支付订单是否已支付。

步骤S3013：调取业务订单接口，查询与上述支付订单对应的业务订单。

具体的，调取业务订单接口访问业务订单数据池，通过对应关系(关联字段)查询并获取与上述未支付的支付订单对应的业务订单。

步骤S3014：对业务订单的订单状态进行更新。

对未支付的支付订单(异常订单)对应的业务订单的订单状态进行更新，将订单状态更新为成功，并标识更新字段。

步骤S3015：获取上述订单状态的更新结果。

具体的，调取业务订单接口访问业务订单数据池，根据上述业务订单的更新字段判断更新结果是否成功。

步骤S3016：根据上述更新结果的失败信息，通知用户端进行处理。

进一步的，当上述更新结果为成功时，该方法还包括：根据上述更新结果的成功信息，对下一笔支付状态为未支付的支付订单进行处理。

需要说明的是，考虑到对订单状态为未成功的业务订单进行处理更新时与对支付状态为未支付的支付订单进行处理更新可能产生的相互影响，一种方式是：可以采取由两个不同更新字段来区分是由业务订单开始处理的更新过程，还是由支付订单开始处理的更新过程。例如，以第一更新字段标识由业务订单开始处理的更新结果，以第二更新字段标识由支付订单开始处理的更新结果。

另外一种方式，从提高处理效率的角度考虑，可以在对业务订单处理时，由业务订单数据池(例如业务订单表格)的顶端自上而下进行处理更新，在对支付订单处理时，由支付订单数据池(例如支付订单表格)的底端自下而上进行。需要指出的是，业务订单表格与支付订单表格的对应关系是确定的、位置关系也是对应的。

实施例四：

图5示出了本发明实施例提供的异常订单处理装置的结构示意图，如图5所示，该异常订单处理装置包括：

获取模块200，用于每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单。

对应模块300，用于获取与上述业务订单对应的支付订单。

调取模块400，用于根据上述支付订单的未成功支付状态，调取与上述支付订单对应的支付通道订单查询接口。

更新模块500，用于根据上述支付订单的已支付信息，对上述业务订单的订单状态进行更新。

进一步的是，该装置还包括：

处理模块600，用于获取上述业务订单的更新结果；当上述更新结果为失败时，向用户端发送信息以提示用户进行处理。

分类建立模块700，用于获取目标项目的所有订单，将上述订单进行分类，得到业务订单数据池以及支付订单数据池；建立业务订单数据池与支付订单数据池的对应关系。

进一步的，该装置还包括：

支付订单模块800，用于对支付状态为未支付的支付订单进行处理。

优选的，支付订单模块800具体用于：每间隔第二预设时间，查询并获取过去第二设定时间段内的支付状态为未支付的支付订单；调取与上述支付订单对应的支付通道查询接口，判断上述支付订单是否已支付成功；当上述支付订单是已支付成功时，调取业务订单接口，查询与上述支付订单对应的业务订单；对上述业务订单的订单状态进行更新。

实施例三：

参见图6，本发明实施例还提供一种电子设备100，包括：处理器40，存储器41，总线42和通信接口43，所述处理器40、通信接口43和存储器41通过总线42连接；处理器40用于执行存储器41中存储的可执行模块，例如计算机程序。

其中，存储器41可能包含高速随机存取存储器(RAM，RandomAccessMemory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口43(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接，可以使用互联网，广域网，本地网，城域网等。

总线42可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器41用于存储程序，所述处理器40在接收到执行指令后，执行所述程序，前述本发明实施例任一实施例揭示的流过程定义的装置所执行的方法可以应用于处理器40中，或者由处理器40实现。

处理器40可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器40中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器40可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(Digital SignalProcessing，简称DSP)、专用集成电路(Application Specific Integrated Circuit，简称ASIC)、现成可编程门阵列(Field-Programmable Gate Array，简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本发明实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本发明实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器41，处理器40读取存储器41中的信息，结合其硬件完成上述方法的步骤。

本发明实施例提供的异常订单处理装置及电子设备，与上述实施例提供的异常订单处理方法具有相同的技术特征，所以也能解决相同的技术问题，达到相同的技术效果。

本发明实施例所提供的进行异常订单处理方法的计算机程序产品，包括存储了处理器可执行的非易失的程序代码的计算机可读存储介质，所述程序代码包括的指令可用于执行前面方法实施例中所述的方法，具体实现可参见方法实施例，在此不再赘述。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置及电子设备的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

附图中的流程图和框图显示了根据本发明的多个实施例方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

在本发明的描述中，需要说明的是，术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。此外，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本发明的具体实施方式，用以说明本发明的技术方案，而非对其限制，本发明的保护范围并不局限于此，尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本发明实施例技术方案的精神和范围，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims (10)

1.一种异常订单处理方法，其特征在于，包括：

每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单；

获取与所述业务订单对应的支付订单；

根据所述支付订单的未成功支付状态，调取与所述支付订单对应的支付通道订单查询接口；

根据所述支付订单的已支付信息，对所述业务订单的订单状态进行更新。

2.根据权利要求1所述的方法，其特征在于，还包括：

获取所述业务订单的更新结果；

当所述更新结果为失败时，向用户端发送信息以提示用户进行处理。

3.根据权利要求1所述的方法，其特征在于，还包括：

对支付状态为未支付的支付订单进行处理。

4.根据权利要求3所述的方法，其特征在于，所述对支付状态为未支付的支付订单进行处理，具体包括：

每间隔第二预设时间，查询并获取过去第二设定时间段内的支付状态为未支付的支付订单；

调取与所述支付订单对应的支付通道查询接口，判断所述支付订单是否已支付成功；

当所述支付订单是已支付成功时，调取业务订单接口，查询与所述支付订单对应的业务订单；

对所述业务订单的订单状态进行更新。

5.根据权利要求1所述的方法，其特征在于，所述设定时间段的时长大于所述预设时间的时长。

6.根据权利要求1所述的方法，其特征在于，还包括：

获取目标项目的所有订单，将所述订单进行分类，得到业务订单数据池以及支付订单数据池；

建立业务订单数据池与支付订单数据池的对应关系。

7.根据权利要求6所述的方法，其特征在于，还包括：

每间隔预设周期对所述业务订单数据池、支付订单数据池以及所述对应关系进行更新。

8.一种异常订单处理装置，其特征在于，包括：

获取模块，用于每间隔预设时间，查询并获取过去设定时间段内的订单状态为未成功的业务订单；

对应模块，用于获取与所述业务订单对应的支付订单；

调取模块，用于根据所述支付订单的未成功支付状态，调取与所述支付订单对应的支付通道订单查询接口；

更新模块，用于根据所述支付订单的已支付信息，对所述业务订单的订单状态进行更新。

9.根据权利要求8所述的异常订单处理装置，其特征在于，还包括：

处理模块，用于获取所述业务订单的更新结果；当所述更新结果为失败时，向用户端发送信息以提示用户进行处理。

10.一种电子设备，包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现上述权利要求1至7任一项所述的方法的步骤。