一种异常订单处理方法和装置

技术领域

本申请涉及信息技术(internet Technology，IT)领域，尤其涉及一种异常订单处理方法和装置。

背景技术

随着移动支付迅猛发展，聚合支付凭借着自身的灵活性、便携性得到广泛的使用。聚合支付也被称为“第四方支付”，不同于第三方支付介于银行和商户之间的模式，聚合支付可以提供支付通道、集合对账、金融服务引导等服务内容。聚合支付简单理解就是通过技术服务聚合了各种第三方支付和线下收单等能力的支付方式，可以简化商家的接入和统一对账的问题，外加后续的增值服务。

但是，随着接入聚合支付平台的支付机构和商户越来越多，支付链路的复杂性也越来越高，现实中存在许多因素(诸如网络抖动、代理异常、商户机构处理异常等)会导致支付不稳定，可能出现支付机构扣款成功之后未将支付成功的结果正确回传给商户，导致支付异常，影响用户体验。

发明内容

本申请实施例提供一种异常订单处理方法和装置，能够提高支付异常处理的效率，从而提高用户体验。

第一方面，本申请实施例提供一种异常订单处理方法，应用于聚合支付平台，包括：对多个对象的历史数据进行评级，根据每个对象的评级结果动态分配该对象对应的调度资源，多个对象包括第一对象和第二对象，第一对象为第一商户或支付机构，第二对象为第二商户或支付机构，历史数据包括订单数、订单支付成功率中的至少一项，调度资源包括调度线程数、调度频率、内存中的至少一项；筛选异常订单，异常订单的支付状态为未知或失败，异常订单包括第一对象对应的异常订单和第二对象对应的异常订单；根据第一对象对应的调度资源处理第一对象对应的异常订单，根据第二对象对应的调度资源处理第二对象对应的异常订单。

基于本申请实施例提供的方法，对多个对象(商户或支付机构)的历史数据进行评级，根据每个对象的评级结果动态分配该对象对应的调度资源，即基于支付机构/商户维度对异常订单进行分类管理，合理分配用于处理异常订单的调度资源，避免因为某一个支付机构/商户异常过载而影响其他支付机构/商户的查补效率(对异常订单的处理效率)，能够提高支付异常处理的效率，从而提高用户体验。

在一种可能的实现方式中，该方法还包括：识别第一对象/第二对象对应的异常订单的错误码和状态码，根据错误码和状态码匹配目标案例，根据目标案例确定异常订单的异常根因，并执行修复策略和/或智能告警策略。即可以通过识别异常订单的错误码和状态码确定对应的智能策略，基于智能策略可以实现异常订单的修复、运维告警、根因透析等，可以节省运维/开发人员的对异常订单进行分析定位的工作量，保障运维人员能够第一时间感知异常，并做出响应，打破了网络层屏障，保障异常订单处理的自动闭环。

在一种可能的实现方式中，若第一对象对应的异常订单包括多个，根据第一对象对应的调度资源处理第一对象对应的异常订单包括：将第一对象的多个异常订单均匀分配给第一对象对应的多个线程，每个线程依次处理被分配的异常订单。这样，可以有序处理异常订单。

在一种可能的实现方式中，根据错误码和状态码匹配目标案例，根据目标案例确定异常订单的异常根因，并执行修复策略和/或智能告警策略包括：若确定异常根因是代理网关异常，执行的智能恢复策略包括自动切换到备用代理网关，执行的智能告警策略包括发送代理网关异常的告警信息。这样，可以快速修复代理网关异常，且可以节省运维/开发人员的对异常订单进行分析定位的工作量，保障运维人员能够第一时间感知异常，并做出响应，打破了网络层屏障，保障异常订单处理的自动闭环。

在一种可能的实现方式中，根据错误码和状态码匹配目标案例，根据目标案例确定异常订单的异常根因，并执行修复策略和/或智能告警策略包括：若确定异常根因是支付机构异常，执行的智能恢复策略包括调整异常订单的查补周期和进行拨测，执行的智能告警策略包括发送支付机构异常的告警信息。这样，可以节省运维/开发人员的对异常订单进行分析定位的工作量，保障运维人员能够第一时间感知异常，并做出响应，打破了网络层屏障，保障异常订单处理的自动闭环。并且，调整异常订单的查补周期(例如，增加查补周期的时长)可以使得异常订单的故障可以有充分的时间被修复，且可以节省查补资源(即减少无效查补导致的资源浪费)。

在一种可能的实现方式中，该方法还包括：若拨测结果指示支付机构异常已修复，或者当异常订单的下一个查补周期到来时，向支付机构重新查询异常订单的支付状态；若查询状态为支付成功，则刷新聚合支付平台的订单状态，并向商户发送支付成功的通知。这样，商户可以向用户提示支付成功，完成了异常订单的自动闭环处理。

第二方面，本申请提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面及其任一种可能的设计方式所述的方法。

第三方面，本申请实施例提供了一种异常订单处理装置，包括处理器，处理器和存储器耦合，存储器存储有程序指令，当存储器存储的程序指令被处理器执行时使得所述装置实现上述第一方面及其任一种可能的设计方式所述的方法。所述装置可以为服务器设备；或可以为服务器设备中的一个组成部分，如芯片。

第四方面，本申请实施例提供了一种异常订单处理装置，所述装置可以按照功能划分为不同的逻辑单元或模块，各单元或模块执行不同的功能，以使得所述装置执行上述第一方面及其任一种可能的设计方式所述的方法。

第五方面，本申请提供一种芯片系统，该芯片系统包括一个或多个接口电路和一个或多个处理器。该接口电路和处理器通过线路互联。上述芯片系统可以应用于包括通信模块和存储器的服务器。该接口电路用于从服务器的存储器接收信号，并向处理器发送接收到的信号，该信号包括存储器中存储的计算机指令。当处理器执行该计算机指令时，服务器可以执行如第一方面及其任一种可能的设计方式所述的方法。

第六方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令。当计算机指令在服务器上运行时，使得该服务器执行如第一方面及其任一种可能的设计方式所述的方法。

可以理解地，上述提供的第二方面所述的计算机程序产品及第三方面、第四方面所述的装置、第五方面所述的芯片系统及第六方面所述的计算机可读存储介质所能达到的有益效果，可参考如第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。

附图说明

图1为现有技术的一种聚合支付系统的示意图；

图2A为本申请实施例提供的一种聚合支付系统的示意图；

图2B为本申请实施例提供的一种服务器的结构示意图；

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

图4为本申请实施例提供的一种界面示意图；

图5为本申请实施例提供的一种流程示意图；

图6为本申请实施例提供的又一种流程示意图；

图7为本申请实施例提供的又一种界面示意图；

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

图9为本申请实施例提供的又一种聚合支付系统的示意图；

图10为本申请实施例提供的一种芯片系统的结构示意图。

具体实施方式

随着接入聚合支付平台的支付机构和商户越来越多，支付链路的复杂性也越来越高，现实中存在许多因素(诸如网络抖动、代理异常、商户机构处理异常、代理异常、程序本身、并发等原因等)会影响支付过程(造成的如支付不成功、支付成功而商城未收到发货通知、甚至重复支付等支付异常问题)，可能出现支付机构扣款成功之后未将支付成功的结果正确回传给商户，导致支付异常(即掉单)，影响用户体验。

例如，如图1所示，是一种聚合支付系统的架构示意图。其中，聚合支付平台可以对接多个商户(例如，商户A(例如，荣耀商城)、商户B等等)和多个支付机构(支付机构例如可以是

示例性的，以商户为荣耀商城，支付机构为银行为例对支付过程进行说明。支付过程包括：(1)、荣耀商城创建订单，向聚合支付平台发起支付请求；(2)聚合支付平台创建订单，并向银行发起支付请求。(3)银行完成扣款操作，将支付结果返回聚合支付平台。(4)聚合支付平台完成订单更新。(5)聚合支付平台将更新后的订单返回荣耀商城。荣耀商城可以变更订单状态(例如，将订单状态从待支付状态变更为已支付状态)。然而，以上任何一个环节异常都有可能造成支付异常(例如，掉单)。

当出现支付异常时，现有技术的解决方案如下：聚合支付平台通过订单流水号向支付机构查询当前订单的支付状态。聚合支付平台根据支付机构返回的查询结果判断订单是否已经支付成功。若无法查询到当前订单的支付状态，可以向支付机构轮询支付异常的订单的支付状态。

但是，上述方式具有以下缺陷：轮询支付异常的订单会导致整体系统开销过大，无法应对峰值场景(即异常订单激增的场景)；仅能处理网络抖动造成的回写失败(例如，支付机构回写支付结果(向聚合支付平台发送支付结果)失败)，没有对网络以及机构侧异常进行分析处理，无法感知一段时间无法恢复(无法立即恢复)的外部异常。

本申请实施例提供一种异常订单处理方法，能够实现异常支付的快速闭环。一方面，本申请提供一种基于资源策略的自动查补方案，基于资源策略的自动查补方案是指基于支付机构/商户维度对支付异常订单进行分类管理，避免因为某一个支付机构/商户异常过载而影响其他支付机构/商户的查补效率(对异常订单的处理效率)。另一方面，本申请还提供一种基于智能策略的自动查补，可以基于案例(Case)库自动识别异常场景(导致支付失败的场景)并做出响应，节省运维/开发人员对异常场景进行分析定位的工作量，实现支付机构/商户侧/代理侧异常自动识别、快速恢复。

如图2A所示，为本申请实施例提供的一种聚合支付系统的架构示意图。该架构包括商户，聚合支付平台和支付机构。可选的，该架构还可以包括智能运维平台。智能运维平台与聚合支付平台可以采用集中式部署或分布式部署的部署方式，本申请不做限定。

其中，商户可以包括购物应用或生活服务类应用，例如，荣耀商城、

支付机构(也可以称为支付渠道)可以包括第三方支付系统或银行。其中，第三方支付系统可以包括

聚合支付平台可以将第三方支付系统和银行聚合在一起，为商户提供更加轻巧、简单、快捷的收银服务。

其中，聚合支付平台可以包括记录中心、运营后台、通知管理、渠道网关、渠道、交易中心、退款平台、应用程序接口(application programming interface，API)网关等模块。各个模块的功能可以如表1所示：

表1

聚合支付平台还可以包括策略引擎，策略引擎可以调度其他模块(例如，通知管理、交易中心等模块)执行状态查补任务(即通过订单流水号去支付机构查询订单的支付状态)。策略引擎可以包括资源策略和智能策略。可以通过记录中心对历史数据进行分析评级(即评级)，得出各个支付机构/商户的资源策略，基于资源策略可以动态分配调度线程数、调度频率、内存等资源。可以通过识别支付链路上已知的错误码确定对应的智能策略，在检测到支付异常时，基于智能策略可以实现支付链路的自/手动修复、运维告警、根因透析等，能够快速的识别异常根因并作进一步处理，节约运维成本。

本申请实施例提供的异常订单处理方法可以应用于服务器。如图2B所示，为本申请实施例提供的服务器的一种硬件结构示意图。该服务器200包括至少一个处理器201，通信线路202，存储器203以及至少一个通信接口204。

处理器201可以是一个通用中央处理器(central processing unit，CPU)，微处理器，特定应用集成电路(application-specific integrated circuit，ASIC)，或一个或多个用于控制本申请方案程序执行的集成电路。

通信线路202可包括一通路，在上述组件之间传送信息。

通信接口204，使用任何收发器一类的装置，用于与其他设备或通信网络通信，如以太网，无线接入网(radio access network，RAN)，无线局域网(wireless local areanetworks，WLAN)等。

存储器203可以是只读存储器(read-only memory，ROM)或可存储静态信息和指令的其他类型的静态存储设备，随机存取存储器(random access memory，RAM)或者可存储信息和指令的其他类型的动态存储设备，也可以是电可擦可编程只读存储器(electricallyerasable programmable read-only memory，EEPROM)、只读光盘(compact disc read-only memory，CD-ROM)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。存储器可以是独立存在，通过通信线路202与处理器相连接。存储器也可以和处理器集成在一起。

其中，存储器203用于存储执行本申请方案的计算机执行指令，并由处理器201来控制执行。处理器201用于执行存储器203中存储的计算机执行指令，从而实现本申请下述实施例提供的异常订单处理方法。

可选的，本申请实施例中的计算机执行指令也可以称之为应用程序代码，本申请实施例对此不作具体限定。

在具体实现中，作为一种实施例，处理器201可以包括一个或多个CPU，例如图2B中的CPU0和CPU1。

在具体实现中，作为一种实施例，服务器200可以包括多个处理器，例如图2B中的处理器201和处理器207。这些处理器中的每一个可以是一个单核(single-CPU)处理器，也可以是一个多核(multi-CPU)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

可选的，服务器200还可以包括输出设备205和输入设备206。输出设备205和处理器201通信，可以以多种方式来显示信息。例如，输出设备205可以是液晶显示器(liquidcrystal display，LCD)，发光二级管(light emitting diode，LED)显示设备，阴极射线管(cathode ray tube，CRT)显示设备，或投影仪(projector)等。输入设备206和处理器201通信，可以以多种方式接收用户的输入。例如，输入设备206可以是鼠标、键盘、触摸屏设备或传感设备等。

上述的服务器200可以是一个通用设备或者是一个专用设备。在具体实现中，服务器200可以是台式机、便携式电脑、网络服务器、掌上电脑(personal digital assistant，PDA)、移动手机、平板电脑、无线终端设备、嵌入式设备或有图2B中类似结构的设备。本申请实施例不限定服务器200的类型。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请的描述中，除非另有说明，“至少一个”是指一个或多个，“多个”是指两个或多于两个。另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定，并且“第一”、“第二”等字样也并不限定一定不同。

为了便于理解，以下结合附图对本申请实施例提供的异常订单处理方法进行具体介绍。

如图3所示，本申请实施例提供一种异常订单处理方法，包括：

301、聚合支付平台进行状态查补任务调度。

举例来说，若用户在商户系统(例如，荣耀商城)选择商品并提交了商品订单，如图4所示，手机可以显示支付订单界面401。支付订单界面401可以包括多种支付方式，例如，可以包括

但是，可能出现银行支付阻塞的情况，导致银行并未将支付结果发送给聚合支付平台，聚合支付平台也无法将支付结果发送给商户，商户无法确定支付是否成功，消费者也无法从商户端确认支付是否成功，影响用户体验。

为了避免支付异常影响用户体验，聚合支付平台进行状态查补任务调度，即可以通过订单流水号去支付机构查询订单的支付状态。

302、筛选异常支付订单。

聚合支付平台通过订单流水号去支付机构查询订单的支付状态，根据查询结果判断订单是否已经支付成功，并可以筛选出异常订单。其中，异常订单也可以称为异常支付订单/未成功支付订单，可以是指消费者用户付款后(已被扣款)支付状态仍为未成功的订单。

对于每个支付订单，若聚合支付平台接收到支付机构返回的支付异常信息。或者，若聚合支付平台未从支付机构接收到支付状态信息，可以认为该订单异常(即该订单为异常订单)。

303、基于资源策略对各个商户或支付机构的异常订单进行处理。

在一种可能的设计中，可以通过订单数、订单支付成功率等指标对各个商户/支付机构的历史数据进行分析评级，得出对应的商户/支付机构的分级管理模型，再结合性能曲线模型计算各个商户/支付机构的资源策略(即通过性能曲线模型对各个支付渠道/商城进行资源优化调配)，基于资源策略动态分配各个商户/支付机构对应的调度线程数、调度频率、内存等资源。

其中，性能曲线模型可以反映并发用户数和资源利用率、吞吐量、响应时间等参数之间的关系。可以理解的是，随着并发用户数从0开始增加，聚合支付平台的吞吐量与资源利用率增加。然而，当并发用户数的持续增加，聚合支付平台的吞吐量与资源利用率都达到了饱和，随后吞吐量会急剧下降，系统性能将会急剧下降甚至崩溃。根据性能曲线模型，可以计算出聚合支付平台在保证资源利用率、吞吐量、响应时间等的情况下可以容纳的最佳并发用户数。结合性能曲线模型计算各个商户/支付机构的资源策略即在最佳并发用户数的基础上计算各个商户/支付机构的资源策略。

示例性的，如图5所示，基于资源策略对异常订单进行处理(也可以称为查补单(即掉单查补))的过程可以如下所示：

1)进行任务调度，筛选预设时间段(例如，近24小时或48小时)的异常订单并实例化任务(task)。2)根据分级管理模型执行任务分发策略，并且注册分发的任务的资源占用。3)资源控制模块将实例化任务(task)分发到对应的执行机(excutor)，并返回任务的资源占用。4)当执行机接收到实例化任务时，从线程池中取出一个线程来执行调度任务，线程处理异常订单(即执行查补单)。

需要说明的是，对于一次查补无法闭环的异常订单(这是由于异常订单的故障无法短时间内修复)，可以对该类异常订单进行查补周期调整，增加查补周期的时长(例如，下一次查补周期时间增加5分钟)，以便该异常订单的故障可以有充分的时间被修复，且可以节省查补资源(即减少无效查补导致的资源浪费)。

示例性的，以支付机构为

表2

表3

表4

这样，基于商户/支付机构维度对支付异常订单进行分类管理，避免因为某一个商户/支付机构异常过载而影响其他商户/支付机构的查补效率(即处理异常订单的效率)。通过分级管理策略更合理的规划了服务资源，降低了处理异常订单的资源消耗，提升了处理异常订单的效率。

304、基于智能策略对异常订单进行处理。

对于聚合支付平台外部系统(例如，商户或支付机构)、网络层的异常导致的异常订单，通过梳理已知的异常场景，可以组建完备的Case库。Case库可以包括多个Case，每个Case对应一种错误码、状态参数(例如，HTTP状态码)及其对应的根因分析、支付链路的自/手动修复策略和/或智能告警策略。其中，错误码可以是聚合支付平台(的交易中心、收银台)、支付机构、商户、网关对应的错误码。状态参数例如可以是超文本传输协议(hypertext transfer protocol，HTTP)状态码。基于Case库，对支付订单进行智能分析，即按照异常订单对应的错误码、状态参数匹配相应的Case，根据相应的Case可以得到根因分析，并可以执行对应的修复策略(自动/手动修复支付链路)和/或智能告警(智能运维告警)。

示例性的，Case库可以如表5所示：

表5

需要说明的是，表5仅是一种Case库的示意，Case库还可以包括相比表5更多或或更少的信息，本申请不做限定。例如，Case库中还可以包括代理服务器故障、商户服务暂时不可用等异常情况对应的Case。

如图6所示，在对异常订单的处理过程中，智能运维平台可以识别异常订单对应的错误码、状态码，根据异常订单对应的错误码、状态码匹配相应的Case，根据不同的Case执行对应的修复策略(自动/手动修复支付链路)和/或智能告警(智能运维告警)。

可选的，每个Case还可以对应扩展参数(例如，支付终端的设备类型、IP地址、支付订单的支付机构、支付金额、支付时间等)。基于Case库，对支付订单进行智能分析，即按照异常订单对应的错误码、状态参数和扩展参数匹配相应的Case，根据相应的Case得到根因分析，并执行对应的修复策略(自动/手动修复支付链路)和/或智能告警(智能运维告警)。

举例来说，在对某异常订单的处理的过程中，如表5所示，若根据该异常订单的错误码、状态码匹配到Case00003，则确定该异常订单的根因是银行支付阻塞，导致一段时间无法将支付结果正确通知给聚合支付平台；确定该异常订单的智能恢复策略是生成异常告警，开启监控拨测，调整异常支付订单的查补周期，待拨测结果符合预期执行立即查补；确定该异常订单的智能告警策略是通知运维人员XX银行支付异常。可选的，智能告警策略还可以包括向运维人员通知异常订单的根因(例如，银行支付阻塞)、恢复建议(例如，开启监控拨测，调整异常支付订单的查补周期等)等，本申请不做限定。以便运维人员收到异常支付的告警提醒，结合根因分析以及恢复建议通知及时进行处理，从而尽快疏通银行支付阻塞。

又例如，在对某异常订单的处理过程中，如表5所示，若根据错误码、状态码匹配到Case00001，确定该异常订单的根因是网络连接超时(代理侧异常)，导致聚合支付平台与支付机构/商户通信失败；确定该异常订单的智能恢复策略是自动切换到备用代理；确定该异常订单的智能告警策略是通知运维人员XX支付机构支付异常，异常信息是网络连接超时。可选的，智能告警策略还可以包括向运维人员通知异常订单的恢复建议(例如，自动切换到备用代理等)等，本申请不做限定。这样，运维人员收到异常支付的告警提醒后，可以结合根因分析以及恢复建议通知及时进行处理(例如，及时定位和修复代理服务故障)，从而尽快修复代理侧异常。

在对异常订单的处理过程中，基于智能运维平台完备的Case库可以保障对异常订单的根因自动识别并实现异常链路自动修复和/或智能告警，可以节省运维/开发人员的对异常订单进行分析定位的工作量，保障运维人员能够第一时间感知异常，并做出响应，打破了网络层屏障，保障异常订单处理的自动闭环。

另外，针对无法自动修复的异常订单，根据智能策略匹配相应的Case，通过智能运维平台产生相应的智能告警，通知线上的运维人员，帮助运维人员快速识别支付异常可能的原因，使运维人员通过操作员(Operater，OP)管理界面执行手动查补(即人工对异常订单进行查询和监控)，实现异常支付订单的手动闭环。

305、异常订单新的查补周期到达，再次通过订单流水号去支付机构查询订单的支付状态。

对于一次查补无法闭环的异常订单(这是由于异常订单的故障无法短时间内修复)，当该异常订单新的查补周期(新的查补周期的时长大于上一次查补周期的时长)到达，再次通过订单流水号去支付机构查询订单的支付状态。

306、在异常订单的新的查补周期中，若仍无法查询到支付结果，则再次匹配智能策略并调整该类异常支付订单的查补周期。

在一种可能的情况中，由于支付机构异常未修复，则异常订单仍无法查询到支付结果，可以重复步骤304，即再次基于智能策略对该异常订单进行处理。并且，可以再次对该类异常订单进行查补周期调整，增加查补周期的时长(例如，下一次查补周期时间增加10分钟)，以便该异常订单的故障可以有充分的时间被修复，且可以节省查补资源(即减少无效查补导致的资源浪费)。

307、若拨测监控检测到支付机构异常已修复，则对支付机构异常导致的异常订单立即执行查补操作。

在一种可能的设计中，若基于拨测监控检测到支付机构异常已修复，可以立即根据异常订单的流水号重新去支付机构查询异常订单的支付状态，重新与支付机构进行消息握手，以便补齐支付状态回写。

308、根据支付机构返回的查询结果判断异常订单是否已经支付成功。

若仍无法查询到支付结果或者查询状态为支付异常，则再次匹配资源策略并调整该类异常支付订单的查补周期，具体过程可以参考步骤306。若查询状态为支付成功，可以执行步骤309-311。

309、若查询状态为支付成功，则刷新聚合支付平台的订单状态。

例如聚合支付平台将异常订单的状态从支付异常(例如，未支付成功)调整为支付正常(例如，支付成功)。

310、聚合支付平台向商户发送支付成功的通知。

即聚合支付平台向异常订单(状态已刷新)对应的商户发送支付成功的通知。

311、商户接到通知之后更新订单状态。

商户可以刷新订单的状态。例如，如图7中的(a)和(b)所示，商户在我的订单界面1407可以将订单的状态从订单处理中状态1408调整为支付成功状态1409。

基于本申请实施例提供的方法，在出现支付异常的时候能够疏通异常链路、自动闭环异常支付；由于不同的支付机构以及不同的商户所提供的服务差异性不同，为了保障用户的支付体验，确保异常支付能勾及时有效的闭环处理，本申请针对不同的支付机构/商户计算分级管理模型，通过分级管理模型生成不同的资源策略，通过资源策略合理的规划了服务资源，提升了处理异常订单的效率(查补效率)，同时避免了因过度查补(大量轮询异常订单)导致的性能问题；同时针对支付链路上可能出现的异常场景制定智能策略，每个智能策略包含了根因透析、智能修复以及智能告警，能够快速的识别异常根因，并作进一步处理，节约运维成本。

如图8所示，本申请实施例提供一种异常订单处理方法，以代理服务器异常(故障)导致异常订单的场景为例进行说明，包括：

801、聚合支付平台进行状态查补任务调度。

802、筛选异常支付订单。

步骤801-802可以参考步骤301-302，在此不做赘述。

803、基于智能策略对异常订单进行处理。

例如，参考上文表5所示，若根据错误码、状态码匹配到Case00001，确定该异常订单的根因是网络连接超时(代理侧异常)，导致聚合支付平台与支付机构/商户通信失败；确定该异常订单的智能恢复策略是自动切换到备用代理；确定该异常订单的智能告警策略是通知运维人员XX支付机构支付异常，异常信息是网络连接超时。可选的，智能告警策略还可以包括向运维人员通知异常订单的恢复建议(例如，自动切换到备用代理等)等，本申请不做限定。这样，运维人员收到异常支付的告警提醒后，可以结合根因分析以及恢复建议通知及时进行处理(例如，及时定位和修复代理服务故障)，从而尽快修复代理侧异常。

如图9所示，若确定聚合支付平台和支付机构之间的网络代理发生异常(故障)，则可以切换到备用网络代理(备用代理)。同理，若确定聚合支付平台和商户之间的网络代理发生异常(故障)，则可以切换到备用网络代理(备用代理)。

在对异常订单的处理过程中，基于智能运维平台完备的Case库可以保障对异常订单的根因自动识别并实现异常链路自动修复和/或智能告警，可以节省运维/开发人员的对异常订单进行分析定位的工作量，保障运维人员能够第一时间感知异常，并做出响应，打破了网络层屏障，保障异常订单处理的自动闭环。

804、通过备用代理重新去支付机构查询当前订单的支付状态。

如图9所示，聚合支付平台可以通过备用网络代理去支付机构查询当前订单的支付状态。

805、根据支付机构返回的查询结果判断订单是否已经支付成功。

806、若查询状态为支付成功，则刷新聚合支付平台的订单状态。

807、向商户发送支付成功的通知。

808、商户接到通知之后更新商户的订单状态。

步骤805-808可以参考步骤308-311的相关描述，在此不做赘述。

基于本申请实施例提供的方法，针对支付链路上出现的代理异常场景可以快速的识别异常根因，并进行智能修复以及智能告警，可以节约运维成本，提升处理异常订单的效率。

在聚合支付系统中，因诸如网络延迟、支付机构/商户异常、代理异常、程序本身、并发等原因而造成的如支付不成功、支付成功而商城未收到发货通知、甚至重复支付等支付异常问题。传统处理异常支付的方法有以原子级的事务回滚自动取消订单、提供异常支付查询入口+人工处理、请求重试等，无论哪种都极大的降低了用户的支付体验，且需要消耗大量的运维人力来保障。

相比传统的异常处理方法，本申请采用了静默(用户不感知)的查补(处理异常订单)方式，更好的保障了用户支付体验。通过分级管理策略合理的规划了服务资源，实现最低运维成本和最优服务质量的均衡。通过完备的智能策略，可以更快的识别支付异常问题(诸如网络延迟、支付机构/商户异常、代理异常、程序本身、并发等原因而造成的如支付不成功、支付成功而商城未收到发货通知、甚至重复支付等支付异常问题)，并匹配最优解决方案，快速实现闭环支付异常。

本申请实施例还提供一种芯片系统，如图10所示，该芯片系统包括至少一个处理器1001和至少一个接口电路1002。处理器1001和接口电路1002可通过线路互联。例如，接口电路1002可用于从其它装置(例如，电子设备的存储器)接收信号。又例如，接口电路1002可用于向其它装置(例如处理器1001)发送信号。

例如，接口电路1002可读取电子设备中存储器中存储的指令，并将该指令发送给处理器1001。当所述指令被处理器1001执行时，可使得电子设备(如图2B所示的服务器200)执行上述实施例中的各个步骤。

当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当所述计算机指令在电子设备(如图2B所示的服务器200)上运行时，使得服务器200执行上述方法实施例中服务器执行的各个功能或者步骤。

本申请实施例还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述方法实施例中服务器执行的各个功能或者步骤。

本申请实施例还提供了一种处理装置，所述处理装置可以按照功能划分为不同的逻辑单元或模块，各单元或模块执行不同的功能，以使得所述处理装置执行上述方法实施例中服务器执行的各个功能或者步骤。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。