CN111222872A - 基于支付渠道的用户进件方法、装置及系统 - Google Patents

Abstract

本发明实施例公开了一种基于支付渠道的用户进件方法、装置及系统，涉及电子信息领域，包括：基于支付渠道的用户进件方法，包括：响应于接收到的用户进件请求，生成与所述用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录；分别向各个子流水记录所对应的支付渠道发送进件审核请求，根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息；汇总各个子流水记录的状态信息，根据汇总结果更新所述主流水记录的状态信息；根据所述主流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。该方式提升了支付系统的健壮性，确保了支付功能的正常运行。

Description

基于支付渠道的用户进件方法、装置及系统

技术领域

本发明实施例涉及电子信息领域，具体涉及一种基于支付渠道的用户进件方法、装置及系统。

背景技术

目前，在支付系统中，支付用户为了使用支付业务功能，需要预先接入支付渠道。在接入过程中，需要向支付渠道提供用户相关资料，以供支付渠道审核，并在审核通过后方可接入。其中，支付用户向支付渠道提供相关资料以接入支付渠道的过程称作用户进件。通过用户进件，支付渠道能够预先获取各个支付用户的相关资料，诸如银行卡、用户名称等相关内容，从而能够基于已获取的进件资料实现后续的支付业务功能。

但是，发明人在实现本发明的过程中发现，现有技术中的上述方式至少存在如下缺陷：在常规的用户进件方式中，同一支付用户只能接入单一支付渠道，一旦该支付渠道出现业务异常状态则会导致该支付用户无法成功支付，从而影响该用户的支付业务功能。由此可见，现有的单渠道进件方式存在着支付功能容易出现故障，系统鲁棒性差等技术问题。

发明内容

鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种基于支付渠道的用户进件方法、装置及系统。

根据本发明实施例的一个方面，提供了一种基于支付渠道的用户进件方法，包括：

基于支付渠道的用户进件方法，包括：

响应于接收到的用户进件请求，生成与所述用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录；

分别向各个子流水记录所对应的支付渠道发送进件审核请求，根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息；

汇总各个子流水记录的状态信息，根据汇总结果更新所述主流水记录的状态信息；

根据所述主流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

可选的，所述生成与所述用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录包括：

获取各个支付渠道的渠道校验规范，生成适用于各个支付渠道的通用校验规范；

按照所述通用校验规范，对所述用户进件请求中包含的进件资料数据进行校验；

当校验通过时，生成所述主流水记录以及多个分别对应于不同支付渠道的子流水记录。

可选的，所述分别向各个子流水记录所对应的支付渠道发送进件审核请求包括：

分别针对各个子流水记录，获取该子流水记录所对应的支付渠道的渠道接入规范；

将所述用户进件请求中包含的进件资料数据转换为与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据；

向该子流水记录所对应的支付渠道发送包含与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据的进件审核请求。

可选的，所述根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息包括：

分别向各个支付渠道发送轮询请求，根据轮询结果更新对应的子流水记录的状态信息；

其中，当轮询结果为进件失败时，将对应的子流水记录的状态信息从审核状态更新为失败状态；当轮询结果为进件成功时，将对应的子流水记录的状态信息从审核状态更新为成功状态。

可选的，所述汇总各个子流水记录的状态信息，根据汇总结果更新所述主流水记录的状态信息包括：

判断是否存在至少一个状态信息为成功状态的子流水记录；

若是，将主流水记录的状态信息更新为成功状态；若否，将主流水记录的状态信息更新为失败状态。

可选的，所述根据所述主流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录包括：

当主流水记录的状态信息为成功状态时，获取各个处于成功状态的子流水记录所对应的支付渠道的渠道信息；

根据各个处于成功状态的子流水记录所对应的支付渠道的渠道信息，生成与所述用户进件请求相对应的用户进件数据记录。

可选的，用户进件数据记录包括：用户描述信息、各个处于成功状态的子流水记录所对应的支付渠道的渠道信息、各个处于成功状态的子流水记录所对应的支付渠道的支付平台信息。

可选的，所述方法进一步包括：

响应于接收到的进度查询请求，根据主流水记录的状态信息返回进度查询结果。

根据本发明实施例的又一个方面，提供了一种基于支付渠道的用户进件方法，包括：

获取通过资料提交入口提交的用户资料初始数据；

根据所述用户资料初始数据，生成用户进件请求；

将所述用户进件请求发送给服务器，以供所述服务器生成主流水记录以及多个分别对应于不同支付渠道的子流水记录，并根据各个子流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

可选的，所述将所述用户进件请求发送给服务器之后，进一步包括：

向所述服务器发送进度查询请求，接收并展示所述服务器查询主流水记录的状态信息后返回的进度查询结果。

可选的，所述根据所述用户资料初始数据，生成用户进件请求包括：

针对所述用户资料初始数据进行数据校验；当校验通过时，生成用户进件请求。

根据本发明实施例的又一个方面，提供了一种基于支付渠道的用户进件装置，包括：

生成模块，适于响应于接收到的用户进件请求，生成与所述用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录；

子流水更新模块，适于分别向各个子流水记录所对应的支付渠道发送进件审核请求，根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息；

主流水更新模块，适于汇总各个子流水记录的状态信息，根据汇总结果更新所述主流水记录的状态信息；

进件模块，适于根据所述主流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

可选的，所述生成模块具体适于：

获取各个支付渠道的渠道校验规范，生成适用于各个支付渠道的通用校验规范；

按照所述通用校验规范，对所述用户进件请求中包含的进件资料数据进行校验；

当校验通过时，生成所述主流水记录以及多个分别对应于不同支付渠道的子流水记录。

可选的，所述子流水更新模块具体适于：

分别针对各个子流水记录，获取该子流水记录所对应的支付渠道的渠道接入规范；

将所述用户进件请求中包含的进件资料数据转换为与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据；

向该子流水记录所对应的支付渠道发送包含与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据的进件审核请求。

可选的，所述子流水更新模块具体适于：

分别向各个支付渠道发送轮询请求，根据轮询结果更新对应的子流水记录的状态信息；

其中，当轮询结果为进件失败时，将对应的子流水记录的状态信息从审核状态更新为失败状态；当轮询结果为进件成功时，将对应的子流水记录的状态信息从审核状态更新为成功状态。

可选的，所述主流水更新模块具体适于：

判断是否存在至少一个状态信息为成功状态的子流水记录；

若是，将主流水记录的状态信息更新为成功状态；若否，将主流水记录的状态信息更新为失败状态。

可选的，所述进件模块具体适于：

当主流水记录的状态信息为成功状态时，获取各个处于成功状态的子流水记录所对应的支付渠道的渠道信息；

根据各个处于成功状态的子流水记录所对应的支付渠道的渠道信息，生成与所述用户进件请求相对应的用户进件数据记录。

可选的，用户进件数据记录包括：用户描述信息、各个处于成功状态的子流水记录所对应的支付渠道的渠道信息、各个处于成功状态的子流水记录所对应的支付渠道的支付平台信息。

可选的，所述装置进一步包括：

查询模块，适于响应于接收到的进度查询请求，根据主流水记录的状态信息返回进度查询结果。

根据本发明实施例的又一个方面，提供了一种基于支付渠道的用户进件装置，包括：

获取模块，适于获取通过资料提交入口提交的用户资料初始数据；

进件请求生成模块，适于根据所述用户资料初始数据，生成用户进件请求；

发送模块，适于将所述用户进件请求发送给服务器，以供所述服务器生成主流水记录以及多个分别对应于不同支付渠道的子流水记录，并根据各个子流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

可选的，所述发送模块进一步适于：

向所述服务器发送进度查询请求，接收并展示所述服务器查询主流水记录的状态信息后返回的进度查询结果。

可选的，所述进件请求生成模块具体适于：

针对所述用户资料初始数据进行数据校验；当校验通过时，生成用户进件请求。

根据本发明实施例的又一个方面，提供了一种基于支付渠道的用户进件系统，包括：上述的基于支付渠道的用户进件装置、以及上述的基于支付渠道的用户进件装置。

依据本发明实施例的再一方面，提供了一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如上述的基于支付渠道的用户进件方法对应的操作。

依据本发明实施例的再一方面，提供了一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如上述的基于支付渠道的用户进件方法对应的操作。

在本发明实施例提供的基于支付渠道的用户进件方法、装置及系统中，能够生成与用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录，从而分别向各个子流水记录所对应的支付渠道发送进件审核请求，并根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息，通过汇总各个子流水记录的状态信息更新主流水记录的状态信息，从而生成与所述用户进件请求相对应的用户进件数据记录。由此可见，该方式能够通过多个子流水记录以并行方式实现多渠道进件处理，从而避免了单渠道进件方式固有的支付功能容易出现故障、鲁棒性差等技术问题，提升了支付系统的健壮性，确保了支付功能的正常运行。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例一提供的一种基于支付渠道的用户进件方法的流程图；

图2示出了本发明实施例二提供的一种基于支付渠道的用户进件方法的流程图；

图3示出了本发明实施例三提供的一种基于支付渠道的用户进件装置的结构图；

图4示出了本发明实施例五提供的一种电子设备的结构示意图；

图5示出了本发明又一实施例提供的一种基于支付渠道的用户进件装置的结构图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

实施例一

图1示出了本发明实施例一提供的一种基于支付渠道的用户进件方法的流程图。如图1所示，该方法包括：

步骤S110：响应于接收到的用户进件请求，生成与用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录。

其中，用户进件请求通常由收银用户触发，具体包含收银用户的相关资料数据，如用于收银的用户账号、用户个人信息等相关内容。当接收到用户进件请求后，分别生成与用户进件请求相对应的主流水记录以及子流水记录。其中，主流水记录的数量为一个，用于记录本次用户进件操作的执行进度信息。子流水记录的数量为多个，分别对应于不同的支付渠道。由此可见，子流水记录的数量取决于支付渠道的数量，并且，子流水记录的数量至少为两个，以实现并行向至少两个支付渠道进件的目的。

步骤S120：分别向各个子流水记录所对应的支付渠道发送进件审核请求，根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息。

具体地，以并行方式分别向各个子流水记录所对应的支付渠道发送进件审核请求。以子流水记录的数量为两个为例而言，一方面，需要向第一子流水记录所对应的支付渠道A发送进件审核请求；另一方面，需要向第二子流水记录所对应的支付渠道B发送进件审核请求。其中，需要分别根据各个支付渠道的渠道接入规范生成对应的进件审核请求。

另外，在根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息时，可以通过轮询方式获取各个支付渠道返回的进件审核结果，或者，也可以由各个支付渠道在审核结果发生变化时主动返回审核结果信息，本发明对具体细节不做限定。

步骤S130：汇总各个子流水记录的状态信息，根据汇总结果更新主流水记录的状态信息。

具体地，通过汇总各个子流水记录的状态信息来更新主流水记录的状态信息。例如，当各个子流水记录的状态均为成功状态时，说明各个支付渠道的进件过程均已成功，此时，可以将主流水记录的状态更新为成功；又如，当至少一个子流水记录的状态为成功状态，其他子流水记录的状态为审核中时，主流水记录的状态保持为审核中；再如，当至少一个子流水记录的状态为成功状态，其他子流水记录的状态为审核失败或审核超时等异常状态时，主流水记录的状态更新为成功。总之，只要有一个子流水记录对应的支付渠道进件成功，则主流水记录的状态为成功。

步骤S140：根据主流水记录的状态信息生成与用户进件请求相对应的用户进件数据记录。

具体地，当主流水记录的状态信息为成功时，需要根据各个进件成功的子流水记录生成与用户进件请求相对应的用户进件数据记录。其中，用户进件数据记录用于实现本次进件操作结果的持久化存储，具体包括：用于描述收银用户的用户描述信息、各个处于成功状态的子流水记录所对应的支付渠道的渠道信息、各个处于成功状态的子流水记录所对应的支付渠道的支付平台信息等内容。

由此可见，该方式能够通过多个子流水记录以并行方式实现多渠道进件处理，从而避免了单渠道进件方式固有的支付功能容易出现故障、鲁棒性差等技术问题，提升了支付系统的健壮性，确保了支付功能的正常运行。

实施例二、

图2示出了本发明实施例二提供的一种基于支付渠道的用户进件方法的流程图。如图2所示，该方法包括：

步骤S210：获取通过资料提交入口提交的用户资料初始数据，根据用户资料初始数据，生成用户进件请求，将该用户进件请求发送给服务器。

本步骤的执行主体可以为收银用户(如商户用户)对应的收银客户端(也叫进件客户端)。具体地，在收银客户端的应用界面上提供有资料提交入口，收银用户通过该资料提交入口能够提交用户资料初始数据。该用户资料初始数据主要包括两部分内容，第一部分内容为收银用户的用户描述内容，如收银用户对应的商户资料，如营业执照信息、身份证信息、店内照片信息等；第二部分内容为收银用户的收银账号信息，也叫结算信息，如银行卡卡号、户名、开户行、银行卡照片等。当用户上传上述用户资料初始数据并通过资料提交入口点击提交后，收银客户端获取到上述用户资料初始数据，并根据用户资料初始数据生成用户进件请求。

可选的，为了防止用户上传数据出错，在本步骤中，收银客户端能够针对接收到的用户资料初始数据进行数据校验；当校验通过时，生成用户进件请求。具体地，需要根据数据格式规范进行校验，例如，校验手机号或身份证号码的位数是否正确；还需要结合多项关联信息进行关联校验，例如，判断营业执照中的用户信息与身份证号中的用户信息是否一致等。若校验通过，则生成用户进件请求，并将该用户进件请求发送给后台服务器。可选的，当校验通过时，还可以生成并显示受理成功通知消息，以提示用户进件请求受理成功。若校验失败，则生成失败提示消息，以提示用户重新上传有效数据。其中，用户进件请求中包含根据校验通过的用户资料初始数据生成的进件资料数据。该进件资料数据通常包括校验通过的用户描述信息以及用户结算信息。

步骤S220：响应于接收到的用户进件请求，服务器针对用户进件请求中包含的进件资料数据进行校验。

具体地，本步骤由后台服务器实施。当后台服务器接收到客户端发送的用户进件请求后，针对该用户进件请求进行解析，以获取其中包含的进件资料数据。为了提升进件操作的成功率，防止因数据有误导致的进件失败问题，在本实施例中，服务器针对用户进件请求中包含的进件资料数据进行校验，并仅在校验通过时执行后续步骤，若校验失败则提示用户数据异常等错误信息。

具体实施时，为了提升校验效率，结合各个待接入的支付渠道的渠道校验规范进行校验。首先，获取各个支付渠道的渠道校验规范，生成适用于各个支付渠道的通用校验规范；然后，按照通用校验规范，对用户进件请求中包含的进件资料数据进行校验。其中，不同的支付渠道具有不同的渠道校验规范，该渠道校验规范用于限定待校验的具体字段内容，校验方式等。通用校验规范通常为通用于各个支付渠道的校验规范。例如，分析各个支付渠道的渠道校验规范，提取渠道校验规范中包含的相同部分，即：获取各个支付渠道的渠道校验规范的交集内容，根据该交集内容确定通用校验规范。或者，也可以获取各个支付渠道的渠道校验规范的并集内容，根据该并集内容确定通用校验规范，本发明对此不做限定。总之，根据各个支付渠道的渠道校验规范生成通用校验规范的方式有助于提升各个支付渠道校验成功的概率。

具体地，在确定通用校验规范时，需要预先确定待接入的支付渠道的数量和名称。为此，在后台服务器中预先存储支付渠道配置表，该支付渠道配置表用于存储可供接入的各个支付渠道的渠道信息。具体实施时，可以默认将各个用户进件请求均接入到支付渠道配置表中包含的全部支付渠道中。或者，也可以预先配置收银用户与支付渠道之间的映射关系，例如，根据收银用户的用户类型(如经营类目、地域范围等)，确定对应的待接入的支付渠道的数量和名称。相应地，当接收到用户进件请求并根据解析结果获取到其中包含的进件资料数据后，进一步根据进件资料数据中包含的用户描述信息确定收银用户的用户类型，如经营类型或地域类型等，然后，查询与该用户类型相匹配的支付渠道的数量和名称，从而根据查询结果确定待接入的支付渠道，进而确定与待接入的支付渠道匹配的通用校验规范。

步骤S230：当校验通过时，服务器生成与用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录。

具体地，服务器根据进件资料数据生成对应的主流水记录以及子流水记录。其中，主流水记录用于通过汇总各个子流水记录的实时状态确定本次进件操作的实时进度，以便向客户端返回进度查询结果。子流水记录的数量为多个，用于以并行方式同时向多个支付渠道申请进件。

其中，子流水记录的数量与待进件的支付渠道的数量相同，每个子流水记录分别对应于唯一的支付渠道。例如，在一个具体的示例中，与用户类型相匹配的支付渠道的数量为两个，分别为渠道1以及渠道2，相应地，生成两条子流水记录，分别为子流水记录1以及子流水记录2。其中，子流水记录1包含的渠道信息为渠道1，子流水记录2包含的渠道信息为渠道2。

另外，在生成主流水记录之后，主流水记录以及各个子流水记录的初始状态为审核状态。相应地，可以向客户端返回启动审核响应消息，以通知客户端当前已进入审核状态。

步骤S240：分别向各个子流水记录所对应的支付渠道发送进件审核请求，根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息。

具体地，分别针对各个子流水记录，获取该子流水记录所对应的支付渠道的渠道接入规范；将用户进件请求中包含的进件资料数据转换为与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据；向该子流水记录所对应的支付渠道发送包含与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据的进件审核请求。其中，由于不同的支付渠道具有不同的渠道接入规范，因此，需要根据各个待接入渠道的接入规范对进件资料数据进行转换处理。

具体实施时，可以分别针对每个子流水记录配置一个用于维护该子流水记录的进件操作的子流水操作进程，由各个子流水操作进程获取对应的子流水记录的支付渠道信息，从而根据支付渠道的渠道接入规范对进件资料数据进行转换，得到渠道资料数据。其中，渠道资料数据是指经转换处理后得到的符合对应支付渠道的接入规范的数据。例如，需要根据渠道接入规范将各个用户资料数据填入规定的字段内，并且，需要针对用户资料数据中的各个业务类目进行类目映射转换处理，针对地区码进行码字转换处理等。

当各个子流水操作进程将各个子流水记录对应的渠道资料数据通过网关设备提交至对应的支付渠道后，各个支付渠道针对接收到的进件审核请求进行解析，以获取其中包含的渠道资料数据。具体地，各个支付渠道针对渠道资料数据进行进件审核操作，具体包括初始和复审，其中，初审和复审可以分别通过不同的审核规则实现。若支付渠道审核通过，则返回渠道审核通知消息，并且，支付渠道进一步根据审核通过的渠道资料数据生成平台进件请求，将该平台进件请求发送给指定的支付平台，该支付平台用于提供支付业务功能，具体可以为各类支付平台。支付平台根据收到的平台进件请求进行进件审核处理，若审核成功，则向支付渠道返回审核成功通知消息，反之，则返回审核失败通知消息。由此可见，渠道资料数据需经过支付渠道以及支付平台的双重审核，只有在双重审核均成功的情况下，子流水记录的状态才更新为成功，若其中一重审核失败，则子流水记录的状态为失败。

为了便于维护各个子流水记录的状态信息，分别针对各个子流水记录设置对应的子流水状态进程，该子流水状态进程用于根据获取到的进件审核结果更新对应的子流水记录的状态信息。具体地，在获取进件审核结果时，可以由各个支付渠道在审核结果发生更新时主动将更新后的审核结果发送给对应的子流水状态进程，也可以由各个子流水状态进程主动轮询审核结果。例如，分别向各个支付渠道发送轮询请求，根据轮询结果更新对应的子流水记录的状态信息；其中，当轮询结果为进件失败时，将对应的子流水记录的状态信息从审核状态更新为失败状态；当轮询结果为进件成功时，将对应的子流水记录的状态信息从审核状态更新为成功状态。具体地，可以每隔固定时间间隔轮询一次子流水记录的进件审核结果，若审核成功，则子流水记录推进到成功状态；若审核失败，则子流水记录推进到失败状态；若为审核中，则不作处理，继续等待下一次轮询。

步骤S250：汇总各个子流水记录的状态信息，根据汇总结果更新主流水记录的状态信息。

具体地，当所有子流水记录都轮询到审核结果后，汇总各个子流水记录的状态信息，以更新主流水记录的状态信息。其中，子流水记录轮询到的审核结果可能为审核成功、或审核失败。另外，为了避免在网络异常时导致的无休止等待，可以针对预设时长后仍未轮询到明确审核结果的子流水记录进行异常报错处理，进而将异常报错的子流水记录设置为失败状态。

具体实施时，判断是否存在至少一个状态信息为成功状态的子流水记录；若是，将主流水记录的状态信息更新为成功状态；若否，将主流水记录的状态信息更新为失败状态。由此可见，只要有一个子流水记录为成功状态，主流水记录就推进到成功，反之，主流水记录推进到失败。

步骤S260：根据主流水记录的状态信息生成与用户进件请求相对应的用户进件数据记录。

具体地，当主流水记录的状态信息为成功状态时，获取各个处于成功状态的子流水记录所对应的支付渠道的渠道信息；根据各个处于成功状态的子流水记录所对应的支付渠道的渠道信息，生成与用户进件请求相对应的用户进件数据记录。其中，用户进件数据记录包括：用户描述信息、各个处于成功状态的子流水记录所对应的支付渠道的渠道信息、各个处于成功状态的子流水记录所对应的支付渠道的支付平台信息。

由此可见，用户进件数据记录用于实现进件操作结果的持久化存储，以便于后续在支付过程中使用。其中，用户描述信息用于描述商户的相关属性，具体包括以下中的至少一个：主流水ID、子流水ID、操作来源(即用户名称)、进件维度(如商户或门店等)、进件维度值(如商户ID或门店ID)等。各个处于成功状态的子流水记录所对应的支付渠道的渠道信息用于描述已接入的支付渠道的相关信息，具体包括：渠道号、渠道子商户号、渠道类型、渠道名称等。各个处于成功状态的子流水记录所对应的支付渠道的支付平台信息用于描述与支付渠道对接的支付平台的信息，如平台类型、平台名称等。由此可见，用户进件数据记录主要包含以下几部分信息：用于描述与主流水以及子流水相关内容的操作流水信息、用于描述进件商户的商户属性信息的进件元数据信息、用于描述进件渠道的渠道信息(具体包含支付渠道及其对应的支付平台信息)。

步骤S270：响应于接收到的进度查询请求，根据主流水记录的状态信息返回进度查询结果。

具体地，客户端在将用户进件请求发送给服务器之后，能够随时向服务器发送进度查询请求，从而接收并展示服务器查询主流水记录的状态信息后返回的进度查询结果。当然，后台服务器也可以在审核状态发生改变时，主动向客户端反馈进度信息，本发明对具体细节不做限定。总之，在本实施例中，由主流水记录的状态信息来标识进件操作的进度信息，从而能够根据主流水记录的状态信息向客户端返回进件进度结果，以使用户在无感知的情况下实现多渠道进件。对用户而言，无需知晓接入的支付渠道的数量以及名称，也无需感知各个支付渠道的进件进度，因而能够在不增加用户进件操作的繁琐度的前提下实现多个支付渠道的并行进件处理。

在本实施例中，需要通过多个子流水状态进程以及主流水状态进程轮询并维护各个流水记录的实时状态，一方面，能够根据子流水记录的实时状态更新主流水记录的状态；另一方面，能够根据主流水记录的状态返回进度查询结果，以供客户端知晓进件进度信息。

其中，支付渠道可以为用于提供间联支付功能的间联支付渠道，相应地，收银用户通过接入间联支付渠道的方式，通过间联支付渠道间接对接支付平台，获取支付能力。进件是指：将用户资料提交至第三方机构(即支付渠道)进行审核，完成支付渠道的接入，是获取间联支付能力的前提条件。本实施例通过多渠道进件的方式，能够同时将一份用户资料提交到多家第三方机构，从而完成同一用户在多渠道的接入操作，大幅提升了接入效率，避免了因单一支付渠道故障所导致的支付问题。

并且，该方式还有利于实现多种支付平台的聚合支付功能。相应地，每一个支付渠道可以分别接入至少两个支付平台，相应地，在用户进件数据记录中需要分别存储当前用户已接入的各个支付渠道以及与各个支付渠道相对应的各个支付平台。其中，聚合支付：也称“融合支付”，是指从事“支付、结算、清算”服务之外的“支付服务”，依托银行、非银机构或清算组织，借助银行、非银机构或清算组织的支付通道与清结算能力，利用自身的技术与服务集成能力，将一个以上的银行、非银机构或清算组织的支付服务，整合到一起，为商户提供包括但不限于“支付通道服务”、“集合对账服务”、“技术对接服务”、“差错处理服务”、“金融服务引导”、“会员账户服务”、“作业流程软件服务”、“运行维护服务”、“终端提供与维护”等服务内容，以此减少商户接入、维护支付结算服务时面临的成本支出，提高商户支付结算系统运行效率，并收取增值收益的支付服务。

综上可知，在本实施例中，能够通过多个子流水记录以并行方式实现多渠道进件处理，从而避免了单渠道进件方式固有的支付功能容易出现故障、鲁棒性差等技术问题，提升了支付系统的健壮性，确保了支付功能的正常运行。该方式能够分别针对不同支付渠道的要求进行数据转换处理以及校验处理，从而灵活适配不同支付渠道的业务规范。而且，该方式能够通过汇总各个子流水的状态来更新主流水的状态，并根据主流水的状态向客户端返回查询结果，从而使用户在无感知的情况下完成多渠道进件，提升了进件操作的效率。

实施例三

图3示出了本发明实施例三提供的一种基于支付渠道的用户进件装置的结构示意图，该装置可以为后台服务器，包括：

生成模块31，适于响应于接收到的用户进件请求，生成与所述用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录；

子流水更新模块32，适于分别向各个子流水记录所对应的支付渠道发送进件审核请求，根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息；

主流水更新模块33，适于汇总各个子流水记录的状态信息，根据汇总结果更新所述主流水记录的状态信息；

进件模块34，适于根据所述主流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

可选的，所述生成模块具体适于：

获取各个支付渠道的渠道校验规范，生成适用于各个支付渠道的通用校验规范；

按照所述通用校验规范，对所述用户进件请求中包含的进件资料数据进行校验；

当校验通过时，生成所述主流水记录以及多个分别对应于不同支付渠道的子流水记录。

可选的，所述子流水更新模块具体适于：

分别针对各个子流水记录，获取该子流水记录所对应的支付渠道的渠道接入规范；

将所述用户进件请求中包含的进件资料数据转换为与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据；

向该子流水记录所对应的支付渠道发送包含与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据的进件审核请求。

可选的，所述子流水更新模块具体适于：

分别向各个支付渠道发送轮询请求，根据轮询结果更新对应的子流水记录的状态信息；

其中，当轮询结果为进件失败时，将对应的子流水记录的状态信息从审核状态更新为失败状态；当轮询结果为进件成功时，将对应的子流水记录的状态信息从审核状态更新为成功状态。

可选的，所述主流水更新模块具体适于：

判断是否存在至少一个状态信息为成功状态的子流水记录；

若是，将主流水记录的状态信息更新为成功状态；若否，将主流水记录的状态信息更新为失败状态。

可选的，所述进件模块具体适于：

当主流水记录的状态信息为成功状态时，获取各个处于成功状态的子流水记录所对应的支付渠道的渠道信息；

根据各个处于成功状态的子流水记录所对应的支付渠道的渠道信息，生成与所述用户进件请求相对应的用户进件数据记录。

可选的，用户进件数据记录包括：用户描述信息、各个处于成功状态的子流水记录所对应的支付渠道的渠道信息、各个处于成功状态的子流水记录所对应的支付渠道的支付平台信息。

可选的，所述装置进一步包括：

查询模块，适于响应于接收到的进度查询请求，根据主流水记录的状态信息返回进度查询结果。

由此可见，该方式能够通过多个子流水记录以并行方式实现多渠道进件处理，从而避免了单渠道进件方式固有的支付功能容易出现故障、鲁棒性差等技术问题，提升了支付系统的健壮性，确保了支付功能的正常运行。

图5示出了本发明又一实施例提供的一种基于支付渠道的用户进件装置的结构示意图，该装置可以为客户端，包括：

获取模块51，适于获取通过资料提交入口提交的用户资料初始数据；

进件请求生成模块52，适于根据所述用户资料初始数据，生成用户进件请求；

发送模块53，适于将所述用户进件请求发送给服务器，以供所述服务器生成主流水记录以及多个分别对应于不同支付渠道的子流水记录，并根据各个子流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

可选的，所述发送模块进一步适于：

向所述服务器发送进度查询请求，接收并展示所述服务器查询主流水记录的状态信息后返回的进度查询结果。

可选的，所述进件请求生成模块具体适于：

针对所述用户资料初始数据进行数据校验；当校验通过时，生成用户进件请求。

由此可见，该方式能够通过多个子流水记录以并行方式实现多渠道进件处理，从而避免了单渠道进件方式固有的支付功能容易出现故障、鲁棒性差等技术问题，提升了支付系统的健壮性，确保了支付功能的正常运行。

另外，本发明实施例还提供了一种基于支付渠道的用户进件系统，包括图3所示的基于支付渠道的用户进件装置以及图5所示的基于支付渠道的用户进件装置。该系统能够通过多个子流水记录以并行方式实现多渠道进件处理，从而避免了单渠道进件方式固有的支付功能容易出现故障、鲁棒性差等技术问题，提升了支付系统的健壮性，确保了支付功能的正常运行。

实施例四

本申请实施例四提供了一种非易失性计算机存储介质，所述计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的基于支付渠道的用户进件方法。可执行指令具体可以用于使得处理器执行上述方法实施例中对应的各个操作。

实施例五

图4示出了根据本发明实施例五的一种电子设备的结构示意图，本发明具体实施例并不对电子设备的具体实现做限定。

如图4所示，该电子设备可以包括：处理器(processor)402、通信接口(Communications Interface)406、存储器(memory)404、以及通信总线408。

其中：

处理器402、通信接口406、以及存储器404通过通信总线408完成相互间的通信。

通信接口406，用于与其它设备比如客户端或其它服务器等的网元通信。

处理器402，用于执行程序410，具体可以执行上述基于支付渠道的用户进件方法实施例中的相关步骤。

具体地，程序410可以包括程序代码，该程序代码包括计算机操作指令。

处理器402可能是中央处理器CPU，或者是特定集成电路ASIC(ApplicationSpecific Integrated Circuit)，或者是被配置成实施本发明实施例的一个或多个集成电路。电子设备包括的一个或多个处理器，可以是同一类型的处理器，如一个或多个CPU；也可以是不同类型的处理器，如一个或多个CPU以及一个或多个ASIC。

存储器404，用于存放程序410。存储器404可能包含高速RAM存储器，也可能还包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。

程序510具体可以用于使得处理器502执行上述方法实施例中对应的各个操作。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的基于语音输入信息的抽奖系统中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种基于支付渠道的用户进件方法，包括：

响应于接收到的用户进件请求，生成与所述用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录；

分别向各个子流水记录所对应的支付渠道发送进件审核请求，根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息；

汇总各个子流水记录的状态信息，根据汇总结果更新所述主流水记录的状态信息；

根据所述主流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

2.根据权利要求1所述的方法，其中，所述生成与所述用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录包括：

获取各个支付渠道的渠道校验规范，生成适用于各个支付渠道的通用校验规范；

按照所述通用校验规范，对所述用户进件请求中包含的进件资料数据进行校验；

当校验通过时，生成所述主流水记录以及多个分别对应于不同支付渠道的子流水记录。

3.根据权利要求1或2所述的方法，其中，所述分别向各个子流水记录所对应的支付渠道发送进件审核请求包括：

分别针对各个子流水记录，获取该子流水记录所对应的支付渠道的渠道接入规范；

将所述用户进件请求中包含的进件资料数据转换为与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据；

向该子流水记录所对应的支付渠道发送包含与该子流水记录所对应的支付渠道的渠道接入规范相匹配的渠道资料数据的进件审核请求。

4.根据权利要求1-3任一所述的方法，其中，所述根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息包括：

分别向各个支付渠道发送轮询请求，根据轮询结果更新对应的子流水记录的状态信息；

其中，当轮询结果为进件失败时，将对应的子流水记录的状态信息从审核状态更新为失败状态；当轮询结果为进件成功时，将对应的子流水记录的状态信息从审核状态更新为成功状态。

5.一种基于支付渠道的用户进件方法，包括：

获取通过资料提交入口提交的用户资料初始数据；

根据所述用户资料初始数据，生成用户进件请求；

将所述用户进件请求发送给服务器，以供所述服务器生成主流水记录以及多个分别对应于不同支付渠道的子流水记录，并根据各个子流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

6.一种基于支付渠道的用户进件装置，包括：

生成模块，适于响应于接收到的用户进件请求，生成与所述用户进件请求相对应的主流水记录以及多个分别对应于不同支付渠道的子流水记录；

子流水更新模块，适于分别向各个子流水记录所对应的支付渠道发送进件审核请求，根据各个支付渠道返回的进件审核结果更新对应的子流水记录的状态信息；

主流水更新模块，适于汇总各个子流水记录的状态信息，根据汇总结果更新所述主流水记录的状态信息；

进件模块，适于根据所述主流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

7.一种基于支付渠道的用户进件装置，包括：

获取模块，适于获取通过资料提交入口提交的用户资料初始数据；

进件请求生成模块，适于根据所述用户资料初始数据，生成用户进件请求；

发送模块，适于将所述用户进件请求发送给服务器，以供所述服务器生成主流水记录以及多个分别对应于不同支付渠道的子流水记录，并根据各个子流水记录的状态信息生成与所述用户进件请求相对应的用户进件数据记录。

8.一种基于支付渠道的用户进件系统，包括：权利要求12-19任一所述的基于支付渠道的用户进件装置、以及权利要求20-22任一所述的基于支付渠道的用户进件装置。

9.一种电子设备，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-4中任一项所述的基于支付渠道的用户进件装置对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-4中任一项所述的基于支付渠道的用户进件装置对应的操作。

Images