一种支付失败原因的确定方法及装置

摘要

公开了一种支付失败原因的确定方法及装置一种支付失败原因的确定方法，该方法包括：针对包括多个处理环节的支付流程，监听所述支付流程的每个处理环节的处理状态；当确定监听的当前处理环节的处理状态满足预设的条件时，获取当前处理环节之前的处理环节的处理状态，并将当前处理环节的处理状态与当前处理环节之前的处理环节的处理状态进行关联；所述当前处理环节为所述支付流程包括的任一处理环节；根据经过关联之后的当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态，确定支付失败的原因。

说明书

技术领域

本说明书实施例涉及电子商务技术领域，尤其涉及一种支付失败原因的确定方法及装置。

背景技术

随着移动终端的不断普及，移动支付逐渐发展成为现今越来越重要的电子支付方式，极大的便利了人们的日常生活。然而，受限于移动网络和电子支付系统的稳定性，支付失败的问题仍时常发生，例如，由于网络波动服务端接收不到客户端发送的支付请求，进而导致支付失败。与此同时用户的个人资金可能受损，涉及到后续的退款操作，例如用户在客户端进行支付的过程中，提示用户支付失败，然而实际在服务端已经完成付款操作，用户个人资金受损。因而当前需要分析出具体的支付失败原因，以便于进行相应的处理，进而可以为后续的电子支付系统的改造升级提供支持。

当前支付系统结构越来越复杂，因此大多采用分布式的部署结构来规避支付系统的复杂度，即由分布在不同设备上的子系统共同来组成支付系统。对于一个完整的支付流程而言，需要不同设备上的子系统来相互配合，对于子系统而言，可能包括支付流程的一个或多个处理环节。

目前当支付失败的问题发生时，只能事后人工查找并分析分布在不同设备上的支付系统的运行日志，定位支付失败的具体原因，根据支付失败的具体原因进行相应的处理。由于运行日志分布在不同的设备上，人工查找并分析支付失败的具体原因需要耗费较多的时间和精力，如此一来并不能及时对支付失败进行处理。

发明内容

针对上述技术问题，本说明书实施例提供一种支付失败处理方法及装置，技术方案如下：

一种支付失败原因的确定方法，该方法包括：

针对包括多个处理环节的支付流程，监听所述支付流程的每个处理环节的处理状态；

当确定监听的当前处理环节的处理状态满足预设的条件时，获取当前处理环节之前的处理环节的处理状态，并将当前处理环节的处理状态与当前处理环节之前的处理环节的处理状态进行关联；所述当前处理环节为所述支付流程包括的任一处理环节；

根据经过关联之后的当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态，确定支付失败的原因。

一种支付失败原因的确定装置，该装置包括：

状态监听模块，用于针对包括多个处理环节的支付流程，监听所述支付流程的每个处理环节的处理状态；

状态关联模块，用于当确定监听的当前处理环节的处理状态满足预设的条件时，获取当前处理环节之前的处理环节的处理状态，并将当前处理环节的处理状态与当前处理环节之前的处理环节的处理状态进行关联；所述当前处理环节为所述支付流程包括的任一处理环节；

原因确定模块，用于根据经过关联之后的当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态，确定支付失败的原因。

本说明书实施例所提供的技术方案，通过在支付流程的多个处理环节中，实时监听支付流程在每个环节的处理状态，当确定监听的当前处理环节的处理状态满足预设的条件时，获取当前处理环节之前的处理环节的处理状态，并将当前处理环节的处理状态与当前处理环节之前的处理环节的处理状态进行关联，可以快速确定支付失败的原因。进一步的，还可以为支付失败设置对应的处理方式，对于运营维护人员而言，可以按照所设置的处理方式对支付失败进行处理，由此避免了人工查找并分析分布在不同设备上的支付系统的运行日志，节省了运行维护人员的时间和精力，且可以及时对支付失败进行处理。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书实施例。

此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书实施例中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是本说明书实施例的支付失败处理方法的流程示意图；

图2是本说明书实施例的客户端与服务端之间的支付交互流程的示意图；

图3是本说明书实施例的支付失败处理方法的优选流程示意图；

图4是本说明书实施例的支付失败处理装置的结构示意图；

图5是用于配置本说明书实施例装置的一种设备的结构示意图。

具体实施方式

移动支付就是允许用户使用其移动终端(通常是手机)对所消费的商品或服务进行账务支付的一种服务方式。单位或个人通过移动设备、互联网或者近距离传感直接或间接向银行等金融机构发送支付指令，产生货币支付与资金转移的行为，从而实现移动支付功能。移动支付将终端设备、互联网、应用提供商以及金融机构相融合，为用户提供货币支付、缴费等金融业务。

然而，受限于移动网络和电子支付系统的稳定性，支付失败的问题仍时常发生。例如，由于网络波动，导致服务端接收不到客户端发送的支付请求，进而导致支付失败，于此同时用户的个人资金可能受损，例如用户在客户端进行支付的过程中，在服务端已经完成付款操作，服务端将付款结果返回给客户端，但是由于网络波动，客户端未接收到服务端返回的付款结果，这时在客户端会提示用户支付失败，用户再次进行支付，实际的情况是在服务端已完成付款操作，用户个人资金受损，涉及到后续的退款操作。因此在支付失败的情况下，急需分析出导致支付失败的具体原因，针对支付失败的具体原因采取不同的处理方式对支付失败进行处理，而且后续可以为电子支付系统的改造升级提供支持。

由上述背景技术所述内容可知，目前当支付失败的问题发生时，只能事后人工查找并分析分布在不同设备上的支付系统的运行日志，定位支付失败的具体原因，根据支付失败的具体原因，针对支付失败采取对应的处理方式进行处理。由于运行日志分布在不同的设备上，人工查找并分析支付失败的具体原因需要耗费较多的时间和精力，因而并不能及时针对支付失败采取对应的处理方式进行处理。

针对上述问题，本说明书实施例提供一种技术方案，可以在用户支付的过程中即刻定位到支付失败的具体原因，根据支付失败的具体原因所属的分类，针对支付失败设置对应的处理方式，并显示支付失败的具体原因，以使运营人员按照所设置的处理方式对支付失败进行处理，由此避免了人工查找并分析分布在不同设备上的支付系统的运行日志，节省了运行维护人员的时间和精力，且可以及时对支付失败进行处理。

具体的，本说明书实施例提供的技术方案如下：

对于支付流程包括的多个处理环节，监听支付流程在每个处理环节的处理状态；当监听到当前处理环节的处理状态满足预设的条件时，将当前处理环节的处理状态与当前处理环节之前的处理环节的处理状态进行关联，所述当前处理环节为所述支付流程包括的任一处理环节；根据经过关联之后的当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态确定支付失败的原因；确定所述支付失败的原因所属的分类；根据所述支付失败的原因所属的分类为支付失败设置对应的处理方式，以使运维人员按照所设置的处理方式对支付失败进行处理。

为了使本领域技术人员更好地理解本说明书实施例中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本说明书的一部分实施例，而不是全部的实施例。基于本说明书中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于保护的范围。

如图1所示，为本说明书实施例提供的一种支付失败处理方法的实施流程图，该方法具体可以包括以下步骤：

S101，对于支付流程包括的多个处理环节，监听支付流程在每个处理环节的处理状态；

支付流程包括多个处理环节，对于比较常见的支付流程，例如客户端与服务端之间的支付交互流程，如图2所示，可以包括：用户在客户端发起支付操作，如在支付宝客户端发起支付操作；在客户端生成支付请求；客户端将支付请求发送至服务端，如支付宝支付服务器；服务端接收客户端所发送的支付请求；服务端对支付请求进行处理，这里的处理可以是生成订单、付款等；服务端将对支付请求的处理结果返回至客户端；客户端接收服务端返回的对支付请求的处理结果。

本说明书实施例在上述所说的支付流程的各个处理环节设置监听器，可以依据支付标识监听支付流程在每个处理环节的处理状态，对于每笔交易，都会生成与其对应的支付流水号，可以依据支付流水号监听支付流程在每个处理环节针对该笔交易的处理状态。例如依据支付流水号监听在客户端是否正常生成支付请求，监听客户端是否将支付请求发出，监听服务端是否接收到支付请求等等。意味着对于支付流程包括的多个处理环节，都可以依据支付流水号监听到每笔交易在每个处理环节的处理状态。值得注意的是这里的处理状态在每个处理环节所代表的意义可能不同，例如在生成支付请求环节，处理状态可以是生成支付请求成功或者生成支付请求失败，在支付请求的处理环节，处理状态可以是处理成功或者处理失败。

S102，当监听到当前处理环节的处理状态满足预设的条件时，将当前处理环节的处理状态与当前处理环节之前的处理环节的处理状态进行关联，所述当前处理环节为所述支付流程包括的任一处理环节；

通过上述S101中的步骤，在支付处理阶段，监听各个处理环节的处理状态，当监听到当前处理环节的处理状态满足预设的条件时，触发支付失败处理机制。这里预设的条件与支付流程的处理环节有关，例如当前处理环节为支付请求的处理环节，则预设的条件可以是处理失败，例如当前处理环节为支付请求的处理结果返回至客户端环节，则预设的条件可以是返回失败。

触发支付失败处理机制之后，将当前处理环节的处理状态与当前处理环节之前的处理环节对应的处理状态进行关联。通过关联当前处理环节的处理状态与当前处理环节之前的处理环节对应的处理状态，来刻画完整的支付失败场景。

其中，当监听到当前处理环节的处理状态满足预设的条件时，根据当前处理环节的支付标识将当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态进行关联。这里的支付标识可以是支付流水号，意味着根据支付流水号可以将支付流程当前处理环节的处理状态与之前处理环节的处理状态串联起来，为后续确定支付失败的原因奠定基础。

S103，根据经过关联之后的当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态确定支付失败的原因；

针对S102中的关联结果，可以依据当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态确定支付失败的原因。

例如，在上述图2所示的支付流程中，在将支付请求的处理结果返回至客户端的处理环节(处理结果返回环节)中，服务端将支付请求的处理结果返回至客户端的结果为返回成功，在客户端接收支付请求的处理结果的处理环节(接收处理结果环节)中，客户端未接收到服务端返回的支付请求的处理结果，则根据接收处理结果环节的处理状态以及处理结果返回环节的处理状态，可以确定支付失败的原因为客户端未接收到服务端返回的支付请求的处理结果，造成这个结果的因素可能是网络波动。

S104，确定所述支付失败的原因所属的分类；

针对S103中确定的支付失败的原因，确定支付失败的原因所属的分类，其中确定支付失败的原因所属的分类具体的方式为：在预设的支付失败原因分类表中，在每类中查找该支付失败的原因以确定该支付失败的原因所属的分类，其中可以根据预设的分类规则对支付失败的原因进行分类生成该预设的支付失败原因分类表。

其中根据预设的分类规则对支付失败的原因进行分类生成该预设的支付失败原因分类表，例如如图2所示的支付流程，可以将存在的支付失败的原因分为3大类，其中可以将服务端返回支付请求的处理结果失败、客户端未接收到支付请求的处理结果分为C类，服务端处理支付请求失败分为B类，其余前面的环节分为A类，另外支付流程涉及到调用外部服务(银行侧)，调用失败分为D类，可以将存在的支付失败的原因分为4大类。

在预设的支付失败原因分类表中，在每类中查找该支付失败的原因以确定该支付失败的原因所属的分类。例如，支付失败的原因为客户端未接收到支付请求的处理结果，则可以依次在上述A类、B类、C类中查找该支付失败的原因，确定该支付失败的原因属于C类。

S105，根据所述支付失败的原因所属的分类为支付失败设置对应的处理方式，以使运维人员按照所设置的处理方式对支付失败进行处理。

针对S104中所确定的支付失败的原因所属的分类，确定支付失败的原因所属的分类对应的处理方式，为支付失败设置对应的处理方式，以使运维人员按照所设置的处理方式对支付失败进行处理。

例如，确定该支付失败的原因属于C类，C类对应的处理方式为退款操作，C类中包含服务端返回支付请求的处理结果失败、客户端未接收到支付请求的处理结果，但是实际在支付请求处理环节已经发生扣款操作，由于C类中的原因导致支付失败，因此C类对应的处理方式为退款操作，相应的为支付失败设置退款操作，以使运维人员后续执行退款操作。

又例如，确定该支付失败的原因属于D类，D类对应的处理方式为外部服务的调用链路检测操作，相应的为支付失败设置外部服务的调用链路检测操作，以使运维人员后续执行外部服务的调用链路检测操作。

在上述方法的基础之上，如图3所示，本说明书实施例提供的技术方案可以进一步包括：

S106，展示所述支付失败的原因以及为支付失败设置的对应的处理方式。

对于支付失败的原因以及为支付失败设置的对应的处理方式，可以实时展示出来，后续可以为客服提供解释数据，解释支付失败的具体原因以及对应的处理措施，相应的也可以实时向用户反应真实的支付失败原因，使用户真正的了解到真实的支付失败的原因，可以提升用户的支付体验。

通过上述对本说明书实施例提供的技术方案的描述，可以在用户支付的过程中即刻定位到支付失败的具体原因，根据支付失败的具体原因所属的分类，针对支付失败设置对应的处理方式，并显示支付失败的具体原因，以使运营人员按照所设置的处理方式对支付失败进行处理，由此避免了人工查找并分析分布在不同设备上的支付系统的运行日志，节省了运行维护人员的时间和精力，且可以及时对支付失败进行处理。

相对于上述方法实施例，本说明书实施例还提供了一种支付失败处理装置，如图4所示，可以包括：状态监听模块410、状态关联模块420、原因确定模块430、分类确定模块440、设置模块450。

状态监听模块410，用于对于支付流程包括的多个处理环节，监听支付流程在每个处理环节的处理状态；

状态关联模块420，用于当监听到当前处理环节的处理状态满足预设的条件时，将当前处理环节的处理状态与当前处理环节之前的处理环节的处理状态进行关联，所述当前处理环节为所述支付流程包括的任一处理环节；

原因确定模块430，用于根据经过关联之后的当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态确定支付失败的原因；

分类确定模块440，用于确定所述支付失败的原因所属的分类；

设置模块450，用于根据所述支付失败的原因所属的分类为支付失败设置对应的处理方式，以使运维人员按照所设置的处理方式对支付失败进行处理。

根据本说明书提供的一种具体实施方式，所述状态关联模块420具体用于：

当监听到当前处理环节的处理状态满足预设的条件时，根据当前处理环节的支付标识将当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态进行关联。

根据本说明书提供的一种具体实施方式，所述分类确定模块440具体用于：

在预设的支付失败原因分类表中，在每类中查找所述支付失败的原因以确定所述支付失败的原因所属的分类，其中根据预设的分类规则对支付失败的原因进行分类生成所述预设的支付失败原因分类表。

根据本说明书提供的一种具体实施方式，所述设置模块450具体用于：

确定所述支付失败的原因所属的分类对应的处理方式；

为支付失败设置所述对应的处理方式，以使运维人员按照所设置的处理方式对支付失败进行处理。

根据本说明书提供的一种具体实施方式，所述装置还包括：

展示模块460，用于展示所述支付失败的原因以及为支付失败设置的对应的处理方式。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

通过上述对本说明书实施例提供的技术方案的描述，可以在用户支付的过程中即刻定位到支付失败的具体原因，根据支付失败的具体原因所属的分类，针对支付失败设置对应的处理方式，并显示支付失败的具体原因，以使运营人员按照所设置的处理方式对支付失败进行处理，由此避免了人工查找并分析分布在不同设备上的支付系统的运行日志，节省了运行维护人员的时间和精力，且可以及时对支付失败进行处理。

本说明书实施例还提供一种计算机设备，如图5所示，该设备可以包括：处理器510、存储器520、输入/输出接口530、通信接口540和总线550。其中处理器510、存储器520、输入/输出接口530和通信接口540通过总线550实现彼此之间在设备内部的通信连接。

处理器510可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器520可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器520可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器520中，并由处理器510来调用执行。

输入/输出接口530用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口540用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线550包括一通路，在设备的各个组件(例如处理器510、存储器520、输入/输出接口530和通信接口540)之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器510、存储器520、输入/输出接口530、通信接口540以及总线550，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前述的支付失败处理方法。该方法至少包括：

一种支付失败处理方法，该方法包括：

对于支付流程包括的多个处理环节，监听支付流程在每个处理环节的处理状态；

当监听到当前处理环节的处理状态满足预设的条件时，将当前处理环节的处理状态与当前处理环节之前的处理环节的处理状态进行关联，所述当前处理环节为所述支付流程包括的任一处理环节；

根据经过关联之后的当前处理环节的处理状态以及当前处理环节之前的处理环节的处理状态确定支付失败的原因；

确定所述支付失败的原因所属的分类；

根据所述支付失败的原因所属的分类为支付失败设置对应的处理方式，以使运维人员按照所设置的处理方式对支付失败进行处理。

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

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本说明书实施例可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本说明书实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本说明书实施例各个实施例或者实施例的某些部分所述的方法。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本说明书实施例方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本说明书实施例的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本说明书实施例原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本说明书实施例的保护范围。