CN111667334A - 审核失败订单处理方法、装置、计算机设备和存储介质 - Google Patents

Abstract

本申请涉及互联网技术领域，具体涉及一种审核失败订单处理方法、装置、计算机设备和存储介质。所述方法包括：接收订单审核失败通知；确定订单审核失败通知对应的目标订单；确定目标订单对应的审核失败原因类型；生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者；向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息。本发明实施例能够缩短用户下单周期，提高用户下单效率。

Description

审核失败订单处理方法、装置、计算机设备和存储介质

技术领域

本申请涉及互联网技术领域，特别是涉及一种审核失败订单处理方法、装置、计算机设备和存储介质。

背景技术

目前，在B2B(Business-to-Business)交易平台的下单流程中，用户要购买商品时，需要先针对该商品向交易平台提交购买商品的请求，然后交易平台会基于该请求中的信息(比如，商品信息、商品收货信息等)生成一个预占订单并发送给用户，由用户对预占订单进行审核。用户接收到预占订单后需要对预占订单中的信息进行审核，如果确认无误即可将自己确认购买的订单信息发送给交易平台，交易平台会对用户确认购买的订单信息进行审核，比如确认该订单信息与用户之前下的预占订单是否一致，确认仓库是否有与该订单信息对应的库存等多个审核项目，当所有审核项目都审核通过，那么交易平台才会生成正式订单，也就是说此时用户才成功完成下单。

然而，整个下单流程需要一定的时间周期，在实际场景有可能因为一些变化(比如，用户要购买的交易对象库存余量不足、订单金额扣除操作出错、某些接口调用超时等)导致用户对预占订单确认无误后，却无法通过交易平台的审核。通常订单没有通过交易平台审核，需要将流程节点转移到用户，让用户重新对预占订单进行审核，并再次向交易平台提交下单请求以指示交易平台审核订单，这就延长了整个下单周期。甚至有可能一些问题迟迟得不到解决，那么订单就没办法通过交易平台的审核，使得用户需要多次提交下单请求，直至问题得到解决。

发明内容

本发明针对现有技术的缺点，提供了一种审核失败订单处理方法、装置、计算机设备和存储介质，本发明实施例能够缩短用户下单周期，提高用户下单效率。

本发明根据第一方面提供了一种审核失败订单处理方法，在一个实施例中，该方法包括：

接收订单审核失败通知；

确定订单审核失败通知对应的目标订单；

生成预设通知信息；

将预设通知信息发送给目标订单对应的订单对接者；

向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息。

在一个实施例中，生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者，向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息，包括：

确定目标订单对应的审核失败原因类型；

若确定审核失败原因类型属于预设失败原因类型，生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者，向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息；

若确定审核失败原因类型不属于预设失败原因类型，向第一服务器发送根据目标订单的订单信息生成的订单审核失败消息。

在一个实施例中，生成预设通知信息，包括：

获取目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息；

根据目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息生成预设通知信息。

在一个实施例中，在确定审核失败原因类型属于预设失败原因类型之后，还包括：

生成与目标订单对应的订单自动审核规则；

监控***时间；

在***时间满足订单自动审核规则时，生成用于指示第二服务器对目标订单进行审核的订单审核请求，将订单审核请求发送给第二服务器。

在一个实施例中，确定目标订单对应的审核失败原因类型的步骤，包括：

判断订单审核失败通知是否为目标订单对应的首次审核失败通知；

若确定订单审核失败通知是目标订单对应的首次审核失败通知，确定目标订单对应的审核失败原因类型；

若确定订单审核失败通知不是目标订单对应的首次审核失败通知，确定目标订单对应的预设订单自动审核规则；

监控当前***时间；

在当前***时间满足预设订单自动审核规则时，向第二服务器发送订单审核请求，以指示第二服务器对目标订单进行审核。

在一个实施例中，确定目标订单对应的预设订单自动审核规则，包括：

确定目标订单对应的首次失败通知时间和预设审核重试时间；

若首次失败通知时间与当前***时间之间的时间差值不超过预设审核重试时间，确定目标订单对应的预设订单自动审核规则；

若首次失败通知时间与当前***时间之间的时间差值超过预设审核重试时间，删除目标订单对应的预设订单自动审核规则。

在一个实施例中，将预设通知信息发送给目标订单对应的订单对接者，之后包括：

接收第二服务器发送的订单审核成功通知，订单审核成功通知是第二服务器接收到订单对接者通过第三服务器发送的订单审核请求后，对目标订单进行审核，在确定目标订单审核成功后发送的；

更新目标订单对应的审核状态。

本发明根据第二方面提供了一种审核失败订单处理装置，在一个实施例中，该装置包括：

失败通知接收模块，用于接收订单审核失败通知；

目标订单确定模块，用于确定订单审核失败通知对应的目标订单；

通知信息生成模块，用于生成预设通知信息；

通知信息发送模块，用于将所述预设通知信息发送给所述目标订单对应的订单对接者；

成功消息发送模块，用于向第一服务器发送根据所述目标订单的订单信息生成的订单审核成功消息。

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

本发明根据第四方面提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述任一方法的实施例的步骤。

在本发明实施例中，前台***在接收到订单审核失败通知之后，先确定该订单审核失败通知对应的目标订单；然后就生成预设通知信息并将预设通知信息发送给目标订单对应的订单对接者，以及向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息，这样的话即使用户确认过的订单审核失败了，用户也不需要再对自己确认过的订单进行审核，可以减少用户因下单而投入的人力成本和时间成本，而由于前台***还会通知目标订单对应的订单对接者来跟进解决问题，可以提高导致订单审核失败的问题的解决效率，缩短订单从用户提交开始下单到成功转化为正式订单的时间。

附图说明

图1为一个实施例中一种审核失败订单处理方法的应用环境图；

图2为另一个实施例中一种审核失败订单处理方法的应用环境图；

图3为一个实施例中一种审核失败订单处理方法的流程示意图；

图4为另一个实施例中一种审核失败订单处理方法的流程示意图；

图5为一个实施例中一种审核失败订单处理装置的结构框图；

图6为一个实施例中计算机设备的内部结构图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅用以解释本申请，并不用于限定本申请。

如图1所示为本发明一个实施例中审核失败订单处理方法的应用环境。

用户端10可以跟交易平台进行交互以实现下预占订单和下正式订单。其中，交易平台包括第一服务器21、前台***22以及第二服务器23。

示例性地，第一服务器21可以是用户***，第二服务器23可以是中台***。其中，中台***23主要负责对通过用户确认的订单信息进行审核。具体地，用户可以在审核预占订单信息的时候通过用户端10向用户***21发送用于确认购买交易对象的下单请求，用户***21接收到用户发送的下单请求后，获取通过用户确认的订单信息并将其发送给前台***22，前台***22会将该订单信息再发送给中台***23。中台***23对该订单信息进行审核，审核之后会将审核结果通知前台***22，假如订单审核成功，中台***23会给前台***22发送订单审核成功通知，假如订单审核失败，中台***23会给前台***22发送订单审核失败通知。

以往前台***22在接收到中台***23发送的订单审核失败通知后，会根据该通知生成订单审核失败消息发送给用户***21。而本实施例将以往导致订单审核失败的影响因素进行总结归类得到多种审核失败原因类型，以及各个类型对应的解决方式，然后将该多个解决方式中不需要用户参与的解决方式所对应的审核失败原因类型设置为预设失败原因类型，并对前台***22的业务逻辑进行调整。具体地，当前台***22接收到中台***23发送的订单审核失败通知后，先对该通知对应的订单进行分析，确定出该订单对应的审核失败原因类型，如果该订单对应的审核失败原因类型是预设失败原因类型，即不需要用户参与就能让该订单通过中台***23的审核，那么前台***22向用户***21发送根据目标订单的订单信息生成的订单审核成功消息，同时生成预设通知信息发送给该订单对应的订单对接者，以通知该订单对接者去解决该订单无法通过中台***23审核的问题。这样对于用户来说，就不需要再次甚至多次对自己确认过的订单进行审核，减少用户因下单而投入的人力成本和时间成本，此外前台***22会及时通知相关的订单对接者来跟进解决问题，可以提高导致订单审核失败的问题的解决效率，缩短订单从用户提交开始下单到成功转化为正式订单的时间。

在另一个实施例中，本发明的审核失败订单处理方法的应用环境还可以是如图2所示。其中，交易平台还包括第三服务器24。示例性地，第三服务器24可以是后台***。订单对接者在解决完问题之后可以通过后台***24实时向中台***23发送订单审核请求以调用中台***23对订单对接者负责处理的订单进行审核。当然，可能地，订单对接者还可以通过智能设备来与后台***24进行交互，以通过后台***24向中台***23发送订单审核请求。

其中，用户端10可以是各种智能设备，包括但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和台式计算机等，而用户***21、前台***22、中台***23和后台***24在各自实现上可以用独立的服务器或者是多个服务器组成的服务器集群来实现。

如图3所示，是本发明一个实施例提供的一种审核失败订单处理方法，下面以该方法应用于图1或图2中的前台***为例进行说明。该方法包括以下步骤：

步骤S110：接收订单审核失败通知。

在本实施例中，第二服务器在接收到订单审核请求后，就会对订单审核请求对应的订单进行审核，并在审核之后将审核结果通知前台***，假如订单审核成功，第二服务器会给前台***发送订单审核成功通知，假如订单审核失败，第二服务器会给前台***发送订单审核失败通知。需要说明的是，订单审核请求可能来自前台***、也可能来自第三服务器，但第二服务器接收到不同来源的订单审核请求后处理逻辑是相同的，即对订单审核请求对应的订单进行审核，然后将审核结果发送给前台***。

步骤S120：确定订单审核失败通知对应的目标订单。

在本实施例中，前台***接收到第二服务器发送的订单审核失败通知后，确定与该通知对应的订单(即目标订单)。

具体地，第二服务器可以将审核失败订单的订单信息包含在订单审核失败通知中发送给前台***，这样前台***可以从通知中获得目标订单的订单信息。在另一实施方式中，订单审核失败通知中只有审核失败订单的订单号，这样前台***可以从通知中获得审核失败订单的订单号，然后从本地预存的订单信息中找到与该审核失败订单的订单号对应的订单信息。

步骤S130：生成预设通知信息。

具体地，前台***生成预设通知信息的步骤，包括：

获取目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息；

根据目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息生成预设通知信息。

其中，订单信息可以包括订单标识、交易对象类型信息、交易对象数量信息、收货信息等；审核失败原因信息用于告知订单对接者订单审核失败的详情信息，方便订单对接者对订单进行后续处理，审核失败原因信息可以包括目标订单的审核失败原因类型以及目标订单审核失败的详情信息，不同的审核失败原因类型所对应的详情信息不一样，具体包含哪些信息可以根据实际情况进行设置，比如，如果是库存不足，可以将用户要购买的交易对象的当前库存信息、用户要购买的交易对象数量信息、该交易对象的供货商信息等作为订单审核失败的详情信息；下单用户信息可以是指下单用户的账号信息和/或联系信息。

具体地，为了提高预设通知信息的生成效率，可以预先设置好通知信息模板，可以理解的，如果有多类通知信息(比如，邮件通知、通讯软件通知或者短信通知等)可以为每类通知信息设置一个通知信息模板，然后将获取到的目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息填入模板进而生成预设通知信息。

步骤S140：将预设通知信息发送给目标订单对应的订单对接者。

在本实施例中，订单对接者是负责处理审核失败的订单的人，具体地，可以是为每一个下单用户指定一个对接订单的人(下文称为对接人)，其中，订单对接者是指该对接订单的人使用的智能终端(可理解的，前台***会记录每个对接人及其智能终端之间的关联关系)，这样同一下单用户的所有订单在审核失败后都由一个对接人处理。预设通知信息用于通知目标订单的订单对接者对应的对接人去处理导致该目标订单无法通过第二服务器审核的问题。

步骤S150：向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息。

在本实施例中，前台***会根据目标订单的订单信息来生成订单审核成功消息，并将其发送给第一服务器。需要说明的是，本实施例中不限定前台***在执行步骤S140和步骤S150时的执行顺序，可以是同时执行步骤S140和步骤S150，也可以是区分前后顺序来执行。

本实施例中，当前台***接收到订单审核失败通知后就确定与该通知对应的目标订单，然后将生成的预设通知信息发送给目标订单对应的订单对接者、将根据目标订单的订单信息生成的订单审核成功消息发送给第一服务器，从而即使用户确认过的订单审核失败了，用户也不需要再对自己确认过的订单进行审核，可以减少用户因下单而投入的人力成本和时间成本，而由于前台***还会通知目标订单对应的订单对接者来跟进解决问题，可以提高导致订单审核失败的问题的解决效率，缩短订单从用户提交开始下单到成功转化为正式订单的时间。

在一个实施例中，生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者，向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息，包括：

确定目标订单对应的审核失败原因类型；

若确定审核失败原因类型属于预设失败原因类型，生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者，向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息；

若确定审核失败原因类型不属于预设失败原因类型，向第一服务器发送根据目标订单的订单信息生成的订单审核失败消息。

在本实施例中，考虑到某些场景中，订单审核失败的原因除了可能是交易平台内部原因，还有可能是用户的一些错误操作等，所以需要由交易平台的开发人员预先对以往导致订单审核失败的影响因素，比如，用户确认购买的订单信息与预占订单的信息不一致、用户要购买的交易对象库存不足、订单金额扣除失败、某些接口如用于调用第二服务器进行订单审核的审核接口调用超时等情况进行总结归类，得到多种审核失败原因类型以及各个类型对应的解决方式，然后将该多个解决方式中不需要用户参与的解决方式所对应的审核失败原因类型设置为预设失败原因类型。

比如，开发人员经过总结后发现有4种审核失败原因类型，订单不一致(即用户确认购买的订单信息与预占订单的信息不一致)、库存不足(即用户要购买的交易对象库存不足)、订单金额扣除失败、接口调用超时(该接口可以指多种接口)。其中，对于订单不一致的审核失败原因类型，解决方式可以是由前台***将相关信息如用户确认购买的订单信息和预占订单的信息发送给用户，让用户再次进行确认；对于库存不足的审核失败原因类型，不需要用户参与解决问题，可以由客户经理来负责处理，譬如由客户经理与提供相关交易对象的商家进行协调从而补充库存；而对于订单金额扣除失败或接口调用超时这两种审核失败原因类型，也不需要用户参与解决问题，通常可以由技术人员来解决。经过总结后，可以将库存不足、订单金额扣除失败以及接口调用超时这3种审核失败原因类型设置为预设失败原因类型。

进一步地，在定义好审核失败原因类型，可以为每个审核失败原因类型分配唯一标识，比如，error01、error02等，本实施例不限制唯一标识的形式和样式；而在设置好预设失败原因类型之后，将设置的预设失败原因类型的对照信息存储在前台***。这样第二服务器完成订单审核后，如果确定订单审核失败，就将该订单对应的审核失败原因类型的唯一标识包含在订单审核失败通知中，发送给前台***，而前台***可以根据该预设失败原因类型的对照信息来确定该通知所对应的订单的审核失败原因类型及其是否属于预设失败原因类型。

如果前台***确定目标订单的审核失败原因类型属于预设失败原因类型，那么就获取相关信息以生成预设通知信息，并将生成的预设通知信息发送给目标订单对应的订单对接者。其中，确定订单对接者时还可以是由前台***根据目标订单的审核失败原因类型来确定目标订单的订单对接者。

进一步地，如果前台***确定目标订单对应的审核失败原因类型不属于预设失败原因类型，那么前台***就向第一服务器发送根据目标订单的订单信息生成的订单审核失败消息，从而告知用户其确认过的订单审核失败。

本实施例中，如果前台***确定目标订单对应的审核失败原因类型属于预设失败原因类型，由于预设失败原因类型对应的解决方式并不需要用户参与，前台***自动执行预设处理逻辑即可解决，因此，前台***会根据目标订单的订单信息生成的订单审核成功消息，然后将该订单审核成功消息发送给第一服务器。后续第一服务器会自行通知用户，其确认的订单已通过审核。这样当订单审核失败后，用户就不需要再次甚至多次对自己确认过的订单进行审核，可以减少用户因下单而投入的人力成本和时间成本，而由于前台***还会通知目标订单对应的订单对接者来跟进解决问题，可以提高导致订单审核失败的问题的解决效率，缩短订单从用户提交开始下单到成功转化为正式订单的时间。

在一个实施例中，如图4所示，在确定审核失败原因类型属于预设失败原因类型之后，还包括：

步骤S210：生成与目标订单对应的订单自动审核规则；

步骤S220：监控***时间；

步骤S230：在***时间满足订单自动审核规则时，生成用于指示第二服务器对目标订单进行审核的订单审核请求，将订单审核请求发送给第二服务器。

在本实施例中，为了提高问题解决效率进而缩短下单流程周期，前台***在确定目标订单的审核失败原因类型属于预设失败原因类型之后，会生成与目标订单对应的订单自动审核规则，并监控***时间，当***时间满足订单自动审核规则时，就生成订单审核请求，以指示第二服务器对目标订单进行审核。

具体地，前台***可以制定定时任务，定时向第二服务器发送订单审核请求以调用第二服务器对目标订单进行审核。其中，定时任务对应的任务触发时间间隔根据由相关人员如开发人员或***管理员根据具体应用场景进行适当设置以及调整，比如，在一个场景中，定时任务的任务触发时间间隔可以设置为是30分钟、60分钟、90分钟等。

在一个实施例中，确定目标订单对应的审核失败原因类型的步骤，包括：

判断订单审核失败通知是否为目标订单对应的首次审核失败通知；

若确定订单审核失败通知是目标订单对应的首次审核失败通知，确定目标订单对应的审核失败原因类型。

从上述实施例可以了解到，对于没有通过审核的订单，前台***会定时向第二服务器发送订单审核请求，以指示第二服务器对那些之前已经审核过但没有通过审核的订单再次进行审核，所以前台***接收到的订单审核失败通知有可能对应于第一次经过第二服务器审核的订单，也有可能对应于某个已经审核过但没有通过审核的订单，对于后者，由于这种订单的审核失败原因类型已经确定过了，所以前台***就不需要再次确定这种订单的审核失败原因类型。

具体地，前台***在确定目标订单对应的审核失败原因类型之前，先判断该订单审核失败通知是否为目标订单对应的首次审核失败通知，只有在确定该订单审核失败通知是目标订单对应的首次审核失败通知之后，才执行确定目标订单对应的审核失败原因类型的操作。

更具体地，前台***在向第二服务器转发来自第一服务器的通过用户确认的订单信息(下文简称为用户确认订单)后，给用户确认订单设置一个与订单标识相关联的辅助识别标识，比如，该辅助识别标识默认为0，代表前台***是首次接收到订单对应的订单审核失败通知，该辅助识别标识为1时，代表前台***不是首次接收到订单对应的订单审核失败通知。这样当前台***接收到某订单的订单审核失败通知后，确定与该订单审核失败通知对应的订单标识，并进而确定与该订单标识对应的辅助识别标识，根据辅助识别标识当前的数值即可进行判断出接收到的订单审核失败通知是否为该订单对应的首次审核失败通知。需要说明的是，前台***如果确定订单审核失败通知为该订单对应的首次审核失败通知，即该订单对应的辅助识别标识为0，之后需要将该辅助识别标识的值设置为1；而如果前台***确定该订单对应的辅助识别标识为1，则不需要重新设置该辅助设备标识的值。

进一步地，本实施例提供的审核失败订单处理方法还包括：

若确定订单审核失败通知不是目标订单对应的首次审核失败通知，确定目标订单对应的预设订单自动审核规则；

监控当前***时间；

在当前***时间满足预设订单自动审核规则时，向第二服务器发送订单审核请求，以指示第二服务器对目标订单进行审核。

具体地，如果前台***确定该订单审核失败通知不是目标订单对应的首次审核失败通知，从上述实施例可知，在该目标订单首次审核且没通过第二服务器的审核之后，前台***会为其生成对应的订单自动审核规则。所以此时，前台***不需要执行步骤S140和步骤S150，直接确定该目标订单对应的预先设置好的订单自动审核规则，并在监控到的当前***时间满足该订单自动审核规则时，向第二服务器发送订单审核请求，从而指示第二服务器对该目标订单进行审核。

基于上述实施例，在一个实施例中，前台***确定目标订单对应的预设订单自动审核规则的步骤，包括：

确定目标订单对应的首次失败通知时间和预设审核重试时间；

若首次失败通知时间与当前***时间之间的时间差值不超过预设审核重试时间，确定目标订单对应的预设订单自动审核规则；

若首次失败通知时间与当前***时间之间的时间差值超过预设审核重试时间，删除目标订单对应的预设订单自动审核规则。

通常，目标订单因为库存不足、订单金额扣除失败或者接口调用超时等情况导致没有通过第二服务器的审核时，通过订单对接者即可在较短时间内(比如，三天内、一周内、十天内，具体时间长度在不同场景中可能不同)解决相关问题，使目标订单通过第二服务器的审核。然而，在实际应用场景中，导致订单没办法通过审核的问题可能没有办法在较短时间内解决，如果此时前台***仍然定时发送用于指示第二服务器对该订单进行审核的订单审核请求的话，对于前台***和第二服务器来说，都需要消耗一些计算资源来处理这类订单的相关事务(比如，为该订单发送订单审核请求、审核该订单等)，有可能会影响到对其他订单的处理效率。因此在本实施例中，为每个没有通过第二服务器审核的订单设置一个预设审核重试时间，只有当该订单对应的首次失败通知时间与当前***时间之间的时间差值不超过该预设审核重试时间，前台***才会确定出该订单对应的预设订单自动审核规则，并执行后续操作；反之，前台***会将该订单对应的预设订单自动审核规则删除，即前台***不会再定时发送订单审核请求以调用第二服务器对该订单进行审核。其中，预设审核重试时间可以由相关人员根据具体应用场景进行设置以及适当调整，比如，可以设置为10天、15天等。

在一个实施例中，前台***将预设通知信息发送给目标订单对应的订单对接者的步骤之后，包括：

接收第二服务器发送的订单审核成功通知，订单审核成功通知是第二服务器接收到订单对接者通过第三服务器发送的订单审核请求后，对目标订单进行审核，在确定目标订单审核成功后发送的；

更新目标订单对应的审核状态。

具体地，交易平台中的第三服务器可以为订单对接者提供实时处理功能，当订单对接者处理完目标订单的相关问题之后，可以实时地通过第三服务器向第二服务器发送订单审核请求，以指示第二服务器对目标订单进行审核。当第二服务器接收到第三服务器发送的订单审核请求后，对该订单审核请求对应的订单进行审核，并在确定该订单审核成功之后向前台***发送订单审核成功通知，前台***在接收到该通知后，只需要将该订单对应的审核状态更新为审核成功、或者已处理。

进一步地，考虑到前台***为该订单生成的预设订单自动审核规则还处于生效状态(比如，该订单对应的首次失败通知时间与当前***时间之间的时间差值不超过预设审核重试时间)，为了避免前台***还向第二服务器发送订单审核请求，订单***在更新该订单对应的审核状态之后(也可以是之前或者同时)确定出该订单对应的预设订单自动审核规则，并将其删除。

在一个实施例中，如图5所示，提供了一种审核失败订单处理装置，包括以下模块：

失败通知接收模块110，用于接收订单审核失败通知；

目标订单确定模块120，用于生成预设通知信息；

通知信息生成模块130，用于确定目标订单对应的审核失败原因类型；

通知信息发送模块140，用于将预设通知信息发送给目标订单对应的订单对接者；

成功消息发送模块150，用于向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息。

在一个实施例中，该审核失败订单处理装置还包括，原因类型确定模块、失败消息发送模块和处理模块。

该原因确定模块用于确定目标订单对应的审核失败原因类型。

失败消息发送模块用于向第一服务器发送根据目标订单的订单信息生成的订单审核失败消息。

该处理模块用于在原因确定模块确定审核失败原因类型属于预设失败原因类型时，调用通知信息生成模块130以生成预设通知信息，调用通知信息发送模块140以向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息，以及调用成功消息发送模块150以向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息；在原因确定模块确定审核失败原因类型不属于预设失败原因类型时，调用失败消息发送模块以向第一服务器发送根据目标订单的订单信息生成的订单审核失败消息。

在一个实施例中，通知信息发送模块，包括：

信息获取子模块，用于获取目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息；

通知信息生成子模块，用于根据目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息生成预设通知信息。

在一个实施例中，审核失败订单处理装置还包括：

审核规则生成模块，用于在确定审核失败原因类型属于预设失败原因类型之后，生成与目标订单对应的订单自动审核规则；

时间监控模块，用于监控***时间；

审核请求发送模块，用于在***时间满足订单自动审核规则时，生成用于指示第二服务器对目标订单进行审核的订单审核请求，将订单审核请求发送给第二服务器。

在一个实施例中，原因类型确定模块，包括：

判断子模块，用于判断订单审核失败通知是否为目标订单对应的首次审核失败通知；

原因类型确定子模块，用于当确定订单审核失败通知是目标订单对应的首次审核失败通知时，确定目标订单对应的审核失败原因类型。

在一个实施例中，原因类型确定模块，还包括：

审核规则确定子模块，用于当确定订单审核失败通知不是目标订单对应的首次审核失败通知时，确定目标订单对应的预设订单自动审核规则；

当前时间监控子模块，用于监控当前***时间；

审核请求发送模块，还用于在当前***时间满足预设订单自动审核规则时，向第二服务器发送订单审核请求，以指示第二服务器对目标订单进行审核。

在一个实施例中，审核规则确定子模块，包括：

时间信息确定单元，用于确定目标订单对应的首次失败通知时间和预设审核重试时间；

审核规则确定单元，用于当首次失败通知时间与当前***时间之间的时间差值不超过预设审核重试时间时，确定目标订单对应的预设订单自动审核规则；

审核规则删除单元，用于当首次失败通知时间与当前***时间之间的时间差值超过预设审核重试时间时，删除目标订单对应的预设订单自动审核规则。

在一个实施例中，审核失败订单处理装置还包括：

成功通知接收模块，用于接收第二服务器发送的订单审核成功通知，订单审核成功通知是第二服务器接收到订单对接者通过第三服务器发送的订单审核请求后，对目标订单进行审核，在确定目标订单审核成功后发送的；

审核状态更新模块，用于更新目标订单对应的审核状态。

关于审核失败订单处理装置的具体限定可以参见上文中对于审核失败订单处理方法的限定，在此不再赘述。上述审核失败订单处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

在一个实施例中，提供了一种计算机设备，其内部结构图可以如图6所示。该计算机设备包括通过***总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作***、计算机程序和数据库。该内存储器为非易失性存储介质中的操作***和计算机程序的运行提供环境。该计算机设备的数据库用于存储至少一份订单信息、订单自动审核规则等数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种审核失败订单处理方法。

本领域技术人员可以理解，图6中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现以下步骤：

接收订单审核失败通知；确定订单审核失败通知对应的目标订单；生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者；向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息。

在一个实施例中，处理器执行计算机程序，实现生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者，向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息，包括：时，还实现以下步骤：

确定目标订单对应的审核失败原因类型；

若确定审核失败原因类型属于预设失败原因类型，生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者，向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息；

若确定审核失败原因类型不属于预设失败原因类型，向第一服务器发送根据目标订单的订单信息生成的订单审核失败消息。

在一个实施例中，处理器执行计算机程序，实现生成预设通知信息时，还实现以下步骤：

获取目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息；根据目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息生成预设通知信息。

在一个实施例中，处理器执行计算机程序，实现确定审核失败原因类型属于预设失败原因类型之后，还实现以下步骤：

生成与目标订单对应的订单自动审核规则；监控***时间；在***时间满足订单自动审核规则时，生成用于指示第二服务器对目标订单进行审核的订单审核请求，将订单审核请求发送给第二服务器。

在一个实施例中，处理器执行计算机程序，实现确定目标订单对应的审核失败原因类型时，还实现以下步骤：

判断订单审核失败通知是否为目标订单对应的首次审核失败通知；若确定订单审核失败通知是目标订单对应的首次审核失败通知，确定目标订单对应的审核失败原因类型；若确定订单审核失败通知不是目标订单对应的首次审核失败通知，确定目标订单对应的预设订单自动审核规则；监控当前***时间；在当前***时间满足预设订单自动审核规则时，向第二服务器发送订单审核请求，以指示第二服务器对目标订单进行审核。

在一个实施例中，处理器执行计算机程序，实现确定目标订单对应的预设订单自动审核规则时，还实现以下步骤：

确定目标订单对应的首次失败通知时间和预设审核重试时间；若首次失败通知时间与当前***时间之间的时间差值不超过预设审核重试时间，确定目标订单对应的预设订单自动审核规则；若首次失败通知时间与当前***时间之间的时间差值超过预设审核重试时间，删除目标订单对应的预设订单自动审核规则。

在一个实施例中，处理器执行计算机程序时，实现将预设通知信息发送给目标订单对应的订单对接者之后，还实现以下步骤：

接收第二服务器发送的订单审核成功通知，订单审核成功通知是中台***接收到订单对接者通过第三服务器发送的订单审核请求后，对目标订单进行审核，在确定目标订单审核成功后发送的；更新目标订单对应的审核状态。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

接收订单审核失败通知；确定订单审核失败通知对应的目标订单；生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者；向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息。

在一个实施例中，计算机程序被处理器执行，生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者，向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息时，还实现以下步骤：

确定目标订单对应的审核失败原因类型；

若确定审核失败原因类型属于预设失败原因类型，生成预设通知信息，将预设通知信息发送给目标订单对应的订单对接者，向第一服务器发送根据目标订单的订单信息生成的订单审核成功消息；

若确定审核失败原因类型不属于预设失败原因类型，向第一服务器发送根据目标订单的订单信息生成的订单审核失败消息。

在一个实施例中，计算机程序被处理器执行，生成预设通知信息时，还实现以下步骤：

获取目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息；根据目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息生成预设通知信息。

在一个实施例中，计算机程序被处理器执行，确定审核失败原因类型属于预设失败原因类型之后，还实现以下步骤：

生成与目标订单对应的订单自动审核规则；监控***时间；在***时间满足订单自动审核规则时，生成用于指示第二服务器对目标订单进行审核的订单审核请求，将订单审核请求发送给第二服务器。

在一个实施例中，计算机程序被处理器执行，确定目标订单对应的审核失败原因类型时，还实现以下步骤：

判断订单审核失败通知是否为目标订单对应的首次审核失败通知；若确定订单审核失败通知是目标订单对应的首次审核失败通知，确定目标订单对应的审核失败原因类型；若确定订单审核失败通知不是目标订单对应的首次审核失败通知，确定目标订单对应的预设订单自动审核规则；监控当前***时间；在当前***时间满足预设订单自动审核规则时，向第二服务器发送订单审核请求，以指示第二服务器对目标订单进行审核。

在一个实施例中，计算机程序被处理器执行，确定目标订单对应的预设订单自动审核规则时，还实现以下步骤：

确定目标订单对应的首次失败通知时间和预设审核重试时间；若首次失败通知时间与当前***时间之间的时间差值不超过预设审核重试时间，确定目标订单对应的预设订单自动审核规则；若首次失败通知时间与当前***时间之间的时间差值超过预设审核重试时间，删除目标订单对应的预设订单自动审核规则。

在一个实施例中，计算机程序被处理器执行时，将预设通知信息发送给目标订单对应的订单对接者之后，还实现以下步骤：

接收第二服务器发送的订单审核成功通知，订单审核成功通知是中台***接收到订单对接者通过第三服务器发送的订单审核请求后，对目标订单进行审核，在确定目标订单审核成功后发送的；更新目标订单对应的审核状态。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种审核失败订单处理方法，其特征在于，包括：

接收订单审核失败通知；

确定所述订单审核失败通知对应的目标订单；

生成预设通知信息；

将所述预设通知信息发送给所述目标订单对应的订单对接者；

向第一服务器发送根据所述目标订单的订单信息生成的订单审核成功消息。

2.如权利要求1所述的审核失败订单处理方法，其特征在于，

所述生成预设通知信息，将所述预设通知信息发送给所述目标订单对应的订单对接者，向第一服务器发送根据所述目标订单的订单信息生成的订单审核成功消息，包括：

确定所述目标订单对应的审核失败原因类型；

若确定所述审核失败原因类型属于预设失败原因类型，生成预设通知信息，将所述预设通知信息发送给所述目标订单对应的订单对接者，向第一服务器发送根据所述目标订单的订单信息生成的订单审核成功消息；

若确定所述审核失败原因类型不属于预设失败原因类型，向第一服务器发送根据所述目标订单的订单信息生成的订单审核失败消息。

3.如权利要求1所述的审核失败订单处理方法，其特征在于，

所述生成预设通知信息，包括：

获取所述目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息；

根据所述目标订单对应的订单信息、审核失败原因信息、审核状态和下单用户信息生成预设通知信息。

4.如权利要求2所述的审核失败订单处理方法，其特征在于，

在确定所述审核失败原因类型属于预设失败原因类型之后，还包括：

生成与所述目标订单对应的订单自动审核规则；

监控***时间；

在所述***时间满足所述订单自动审核规则时，生成用于指示第二服务器对所述目标订单进行审核的订单审核请求，将所述订单审核请求发送给所述第二服务器。

5.如权利要求2所述的审核失败订单处理方法，其特征在于，

所述确定所述目标订单对应的审核失败原因类型的步骤，包括：

判断所述订单审核失败通知是否为所述目标订单对应的首次审核失败通知；

若确定所述订单审核失败通知是所述目标订单对应的首次审核失败通知，确定所述目标订单对应的审核失败原因类型；

若确定所述订单审核失败通知不是所述目标订单对应的首次审核失败通知，确定所述目标订单对应的预设订单自动审核规则；监控当前***时间；当所述当前***时间满足所述预设订单自动审核规则时，向所述第二服务器发送订单审核请求，以指示所述第二服务器对所述目标订单进行审核。

6.如权利要求5所述的审核失败订单处理方法，其特征在于，

所述确定所述目标订单对应的预设订单自动审核规则，包括：

确定所述目标订单对应的首次失败通知时间和预设审核重试时间；

若所述首次失败通知时间与当前***时间之间的时间差值不超过预设审核重试时间，确定所述目标订单对应的预设订单自动审核规则；

若所述首次失败通知时间与当前***时间之间的时间差值超过预设审核重试时间，删除所述目标订单对应的预设订单自动审核规则。

7.如权利要求1所述的审核失败订单处理方法，其特征在于，

所述将所述预设通知信息发送给所述目标订单对应的订单对接者，之后包括：

接收第二服务器发送的订单审核成功通知，所述订单审核成功通知是所述第二服务器接收到所述订单对接者通过第三服务器发送的订单审核请求后，对所述目标订单进行审核，在确定所述目标订单审核成功后发送的；

更新所述目标订单对应的审核状态。

8.一种审核失败订单处理装置，其特征在于，包括：

失败通知接收模块，用于接收订单审核失败通知；

目标订单确定模块，用于确定所述订单审核失败通知对应的目标订单；

通知信息生成模块，用于生成预设通知信息；

通知信息发送模块，用于将所述预设通知信息发送给所述目标订单对应的订单对接者；

成功消息发送模块，用于向第一服务器发送根据所述目标订单的订单信息生成的订单审核成功消息。

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

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

Images