CN110728501A - 进件处理方法及进件系统 - Google Patents

Abstract

本发明公开了一种进件处理方法及进件系统，其中，方法包括：接收商户端发起的携带业务列表的进件请求；为商户端匹配出业务列表中每个业务的至少一个支付渠道，作为匹配结果；调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。本发明方案，针对商家端选定的业务进行支付渠道匹配以及通过调度进件任务进行进件处理，利于针对业务进行进件；同时，商户端无需理解业务最终进件到的支付渠道，收单系统无需感知进件请求针对的业务，使得进件处理的过程更加顺畅。

Description

进件处理方法及进件系统

技术领域

本发明涉及互联网技术领域，具体涉及一种进件处理方法及进件系统。

背景技术

通常情况下，商户会支持多种业务，以满足用户多样的需求，其中，业务之间相互独立。例如，支持点餐、当面付等业务。若业务期望发生线上的交易支付行为，则必须接入第三方收单系统(例如，网商银行等)，为此必须要以公司的身份申请相应的支付渠道，从而获取在该支付渠道下的支付能力。与此同时，为获取这种支付能力，商户必须提交对应的商户信息给收单系统进行处理以获得支付参数，实际中，将该提交商户信息并进行处理的过程称之为进件。在申请公布号为CN109636386A的中国专利申请中，收单机构端用来进件商户，并为商户生成付款码，其中，收单机构端采集商户的商户信息，并针对该商户信息进行进件处理，添加进件成功的商户；根据进件成功的商户的商户信息和收单机构的基本信息生成付款码，并将所述付款码发送至商户端，其中，商户信息包括：商户的创建时间；商户名称；所属收单机构：进件了该商户的全部收单机构；商户类别；商户所在城市；商户状态等信息。在该申请中，商户通过提交反映其属性的商户信息给收单机构进行进件，而收单机构在审核完成后将支付参数分配给业务。

然而，在上述现有的进件方案中，进件发生在确定适用业务之前，而无法针对特定的业务进行进件处理；以及，商户与收单机构存在能力割裂，商户不理解最终会进件到的支付渠道，收单机构不理解业务，这种能力的割裂使得商户和收单机构之间的协调性差，不利于进件的顺利进行。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的进件处理方法及进件系统。

根据本发明的一个方面，提供了一种进件处理方法，包括：

接收商户端发起的携带业务列表的进件请求；

为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道，作为匹配结果；

调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询所述进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。

可选的，在所述为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道之后，所述方法还包括：向商户端返回正在处理的通知。

可选的，所述调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询所述进件任务，查询收单系统返回的进件结果，根据所述进件结果向商户端反馈进件请求的处理结果进一步包括：

步骤S10，根据匹配结果，提取未处理的进件任务，一个进件任务用于处理一个业务进件到一个支付渠道；

步骤S11，调度向收单系统发起的所述未处理的进件任务；

步骤S12，定时轮询所述进件任务，查询收单系统返回的进件结果；

步骤S13，若所述进件结果为进件成功，则跳转步骤S10，直至所有的进件任务处理完成，执行步骤S14；若所述进件结果为进件失败，则执行步骤S14；

步骤S14，根据进件结果向商户端反馈进件请求的处理结果。

可选的，所述步骤S14进一步包括：当所有的进件任务的进件结果为进件成功时，则向商户端反馈进件成功的处理结果；或者，

若所述进件结果为进件失败，则根据用于处理当前业务的进件任务中进件成功的次数向商户端反馈进件请求的处理结果。

可选的，在所述步骤S12之后，所述方法还包括：若所述进件结果为进件处理中，则跳转步骤S12。

可选的，若在所述进件请求之前商户端未接收到过进件成功的处理结果，则所述进件请求中还携带有商户端的审核信息；

所述步骤S11进一步包括：判断是否存在已进件成功的进件任务；若否，则调度未处理的进件任务向收单系统的第一指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息以及审核信息；若是，则调度向收单系统的第二指定接口发起的所述未处理的进件任务，所述未处理的进件任务中携带一个支付渠道的渠道信息。

可选的，若在所述进件请求之前商户端接收到过进件成功的处理结果，所述步骤S11进一步包括：

调度向收单系统的第二指定接口发起的所述未处理的进件任务，所述未处理的进件任务中携带一个支付渠道的渠道信息。

可选的，所述方法还包括：向收单系统申请得到多个支付渠道；

所述为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道具体为：从所述多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道。

可选的，所述从所述多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道进一步包括：

查询各个支付渠道的业务配置；针对所述业务列表中的每个业务，将该业务的业务信息与各个支付渠道的业务配置进行匹配，将匹配一致的支付渠道确定为该业务的支付渠道。

可选的，在所述从所述多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道之后，所述方法还包括：

监测多个支付渠道的状态信息；其中，所述状态信息包括故障状态、下线状态、新上线状态和/或业务更改状态；根据所述状态信息确定多个可用的支付渠道作为更新后的多个支付渠道；

从所述更新后的多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道，并调用向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务以进行进件处理。

根据本发明的另一方面，提供了一种进件系统，包括：

接收模块，适于接收商户端发起的携带业务列表的进件请求；

匹配模块，适于为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道，作为匹配结果；

进件模块，适于调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询所述进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。

可选的，所述系统还包括：通知模块，适于向商户端返回正在处理的通知。

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

根据匹配结果，提取未处理的进件任务，一个进件任务用于处理一个业务进件到一个支付渠道；

调度向收单系统发起的所述未处理的进件任务；

定时轮询所述进件任务，查询收单系统返回的进件结果；

若所述进件结果为进件成功，则跳转执行根据匹配结果，提取未处理的进件任务，直至所有的进件任务处理完成，则根据进件结果向商户端反馈进件请求的处理结果；若所述进件结果为进件失败，则根据进件结果向商户端反馈进件请求的处理结果。

可选的，所述进件模块进一步适于：当所有的进件任务的进件结果为进件成功时，则向商户端反馈进件成功的处理结果；或者，

若所述进件结果为进件失败，则根据用于处理当前业务的进件任务中进件成功的次数向商户端反馈进件请求的处理结果。

可选的，所述进件模块进一步适于：若所述进件结果为进件处理中，则跳转执行定时轮询所述进件任务，查询收单系统返回的进件结果。

可选的，若在所述进件请求之前商户端未接收到过进件成功的处理结果，则所述进件请求中还携带有商户端的审核信息；

所述进件模块进一步适于：判断是否存在已进件成功的进件任务；若否，则调度未处理的进件任务向收单系统的第一指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息以及审核信息；若是，则调度向收单系统的第二指定接口发起的所述未处理的进件任务，所述未处理的进件任务中携带一个支付渠道的渠道信息。

可选的，若在所述进件请求之前商户端接收到过进件成功的处理结果，所述进件模块进一步适于：

调度向收单系统的第二指定接口发起的所述未处理的进件任务，所述未处理的进件任务中携带一个支付渠道的渠道信息。

可选的，所述系统还包括：申请模块，适于向收单系统申请得到多个支付渠道；

所述匹配模块进一步适于：从所述多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道。

可选的，所述匹配模块进一步适于：

查询各个支付渠道的业务配置；针对所述业务列表中的每个业务，将该业务的业务信息与各个支付渠道的业务配置进行匹配，将匹配一致的支付渠道确定为该业务的支付渠道。

可选的，所述匹配模块进一步适于：

监测模块，适于监测多个支付渠道的状态信息；其中，所述状态信息包括故障状态、下线状态、新上线状态和/或业务更改状态；根据所述状态信息确定多个可用的支付渠道作为更新后的多个支付渠道；

从所述更新后的多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道；

进件模块进一步适于：调用向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务以进行进件处理。

根据本发明的又一方面，提供了一种服务器，包括：处理器、存储器、通信接口和通信总线，所述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；

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

根据本发明的再一方面，提供了一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如上述进件处理方法对应的操作。

根据本发明的进件处理方法及进件系统，在进行进件之前，可由商户端指定进件适用的业务，然后由进件系统针对该业务进行进件处理，为该业务匹配出至少一个支付渠道以及调度进件任务进行进件到每个支付渠道的处理，使得进件处理的全过程与业务相适应，同时可便于商户端明确业务的进件情况；以及，由进件系统在商户端和收单系统之间进行进件过程中的协调处理，将接收到的商户端选定的任务，经过渠道匹配后，通过调度进件任务而向收单系统指定进件到的支付渠道，该过程也即将商户端关注的业务转换为收单系统关注的支付渠道并提供给收单系统，且该过程对于商户端和收单系统完全透明，商户端无需理解业务最终进件到的支付渠道，收单系统无需感知进件请求针对的业务，使得商户端和收单系统之间的能力割裂达成协调，有利于进件处理的顺畅进行。

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

附图说明

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

图1示出了根据本发明一个实施例的进件处理方法的流程图；

图2示出了根据本发明另一个实施例的进件处理方法的流程图；

图3示出了本发明一个具体实施例中商户-进件系统-收单系统三端交互的示意图；

图4示出了根据本发明一个实施例的进件系统的功能框图；

图5示出了根据本发明实施例的一种服务器的结构示意图。

具体实施方式

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

图1示出了根据本发明一个实施例的进件处理方法的流程图。如图1所示，该方法包括：

步骤S110：接收商户端发起的携带业务列表的进件请求。

在本发明中，由进件系统执行该进件处理方法，该进件系统用于在商户端和收单系统之间进行进件协调，使进件处理的过程更为顺畅；其中，该进件系统可以为一个独立设置的系统，或者为本地生活服务应用对应的服务器的组成部分，以使本地生活服务应用在提供商户端支持的多种业务的同时，支持进件处理。

以及，在本发明中，收单系统是指具备银行清算资质的服务系统，其提供支付接口以让其它公司具有使用微信或者支付宝进行线上支付的支付能力，例如，收单系统为网商银行。进件是指处理商户端请求以使其具备线上支付能力的过程。

具体地，当商户支持的业务中存在线上交易的需求时，则通过商户端选择有需求的业务构成业务列表，并向进件系统发起携带该业务列表的进件请求。其中，该业务列表中包括至少一种业务。例如，商户期望实现点餐在线支付，则选择点餐业务，并通过触发“进件”控件而发起进件请求。

在本步骤中，商户端在发起进件请求时即可选择业务列表，使进件系统可针对选定的业务进行进件处理。

步骤S120：为商户端匹配出业务列表中每个业务的至少一个支付渠道，作为匹配结果。

其中，支付渠道是指具备资质的第三方支付渠道，用于连接收单系统和微信或支付宝，如银联或者平安付等。

具体地，收单系统在接收到进件请求后，则获取到业务列表。针对业务列表中的每个业务，为其匹配出至少一个支付渠道作为匹配结果，则在匹配结果中，包括业务及其至少一个支付渠道的对应关系。需要在此说明的，在本发明中不对具体的匹配方式进行限定，可选的，可根据预设的支付渠道的业务配置进行匹配，例如，将适用于a业务的支付渠道确定为a业务的至少一个支付渠道；和/或，根据支付渠道的状态信息进行匹配，例如，将状态信息显示可用的支付渠道中的一个或多个确定为选定业务的至少一个支付渠道。

步骤S130：调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。

其中，一个进件任务用于处理一个业务进件到一个支付渠道，以及，当业务列表中包含多个业务和/或匹配出多个支付渠道时，则对应有多个进件任务，并且多个进件任务被串行调度执行。例如，点餐业务的至少一个支付渠道为支付渠道b以及支付渠道c，则针对该点餐业务的进件任务为进件任务1和进件任务2共两个，其中进件任务1用于处理点餐业务进件到支付渠道b，进件任务2用于处理点餐业务进件到支付渠道c。

具体地，依次调度进件任务，每调度一个向收单系统发起进件的进件任务，则相当于向收单系统发起了进件到某一支付渠道的进件，收单系统可依据进件任务明确此次进件的支付渠道，则可进行进件处理，该过程中无需收单系统理解进件适用的业务；然后，定时轮询收单系统针对该进件任务的进件结果，其中，进件成功表明成功进件到某一支付渠道(该某一支付渠道为进件任务处理的一个支付渠道，下同)，进件失败表明未成功进件到某一支付渠道，基于此，根据一个或多个进件任务的进件结果，确定各个业务的处理结果，而后向商户端反馈进件请求的处理结果。在本发明中，不限定确定各个业务的处理结果的具体方式，可选的，可在处理该业务的所有进件任务的进件结果为进件成功时，确定该业务进件成功；或者，在处理该业务的所有进件任务中存在一个进件结果为进件成功的进件任务时，确定该业务进件成功。

仍以上述进件任务1和进件任务2举例来说，首先进件系统调度向收单系统发起进件的进件任务1，此时收单系统明确需进件到支付渠道b并进行进件处理，进件系统轮询得到收单系统返回的进件任务1的进件结果为进件成功，则表明进件到支付渠道b成功，然后进件系统调度向收单系统发起进件的进件任务2，此时收单系统明确需进件到支付渠道c并进行进件处理，进件系统轮询得到收单系统返回的进件任务2的进件结果为进件失败，则表明进件到支付渠道c失败，进件任务1和进件任务2中有一个进件任务的进件结果为进件成功，则确定点餐业务的处理结果为进件成功。

根据本实施例提供的进件处理方法，在进行进件之前，可由商户端指定进件适用的业务，然后由进件系统针对该业务进行进件处理，为该业务匹配出至少一个支付渠道以及调度进件任务进行进件到每个支付渠道的处理，使得进件处理的全过程与业务相适应，同时可便于商户端明确业务的进件情况，例如，明确业务的资金与收款账户的对应关系；以及，由进件系统在商户端和收单系统之间进行进件过程中的协调处理，将接收到的商户端选定的任务，经过渠道匹配后，通过调度进件任务而向收单系统指定进件到的支付渠道，该过程也即将商户端关注的业务转换为收单系统关注的支付渠道并提供给收单系统，且该过程对于商户端和收单系统完全透明，商户端无需理解业务最终进件到的支付渠道，收单系统无需感知进件请求针对的业务，使得商户端和收单系统之间的能力割裂达成协调，有利于进件处理的顺畅进行。

图2示出了根据本发明另一个实施例的进件处理方法的流程图。如图2所示，该方法包括：

步骤S210：接收商户端发起的携带业务列表的进件请求。

具体地，进件请求中携带的信息因请求时机的不同而不同，其中，若在进件请求之前商户端未接收到过进件成功的处理结果，则进件请求中还携带有商户端的审核信息；若在进件请求之前商户端已接收到过进件成功的处理结果，则进件请求中不再携带商户端的审核信息。进件系统可根据该不同的信息调用收单系统的相应接口进行进件，而无需针对每个进件请求进行审核信息的重复处理，该处理具体是指针对审核信息的识别、判断的处理，例如，是否身份信息是否有效。其中，审核信息是指反映商户资质、属性的信息，例如，身份证、营业执照等。

相应的，在商户端侧，若检测到商户端已接收到过进件成功的处理结果，则仅在请求界面中提供业务选择入口，以供商户进行业务选择而确定业务列表；若检测到商户端未接收到过进件成功的处理结果，则在请求界面中提供审核信息的输入入口以及业务选择入口。通过这种方式，使在不同的请求时机，向进件系统发起的进件请求中携带的信息不同。

步骤S220：从多个支付渠道中为商户端匹配出业务列表中每个业务的至少一个支付渠道，作为匹配结果。

在本实施例中，进件系统可分配的支付渠道有多个，进件系统需从该多个支付渠道中进行匹配。其中，通过向收单系统申请得到该多个支付渠道。

具体地，在匹配支付渠道的过程中，可根据预设的支付渠道的业务配置进行匹配，和/或，根据支付渠道的状态信息进行匹配，通过这种方式，可使匹配出的支付渠道与该支付渠道实时适用的业务和/或实时的状态相匹配，使得匹配出的支付渠道对于当前业务而言准确且可用。

其中，对于根据预设的支付渠道的业务配置进行匹配的方式，首先查询各个支付渠道的业务配置，其中，业务配置是指支付渠道适用的业务的业务信息，例如，设置支付渠道b用于当面付业务，则支付渠道b的业务配置为1111(当面付业务的业务标识)；针对业务列表中的每个业务，将该业务的业务信息与各个支付渠道的业务配置进行匹配，将匹配一致的支付渠道确定为该业务的支付渠道。然后，将业务与支付渠道的对应关系作为匹配结果，例如，匹配出当面付业务的支付渠道为支付渠道b，则匹配结果中包含业务标识1111和支付渠道b的对应关系。

在本发明的一些可选的实施例中，在得到匹配结果后，根据多个支付渠道的状态变化情况，对匹配结果进行更新，并在更新后通过调度进件任务进行进件处理，以保障支付的稳定可用。具体地，监测多个支付渠道的状态信息；其中，状态信息包括故障状态、下线状态、新上线状态和/或业务更改状态，其中，故障状态指支付渠道由可用变为不可用，下线状态是指支付渠道不再使用，新上线状态是指申请得到新的可用的支付渠道，业务更改状态是指支付渠道的业务配置发生改变，出现上述一种或多种状态变化情况，均可导致与业务相匹配的至少一个支付渠道的改变，则需更新匹配结果，例如，支付渠道故障，则进件到该支付渠道的业务显然不能成功完成线上支付，此时则需对匹配结果进行更新；根据状态信息确定多个可用的支付渠道作为更新后的多个支付渠道，从多个支付渠道中删除故障状态、和/或下线状态的支付渠道，以及，将新上线状态的支付渠道添加到多个支付渠道中，得到更新后的多个支付渠道；并且，对于业务更改状态的支付渠道，则更新其业务配置。从更新后的多个支付渠道中为商户端匹配出业务列表中每个业务的至少一个支付渠道，可选的，从更新后的多个支付渠道中选择可用的、和/或业务配置与业务信息相匹配的支付渠道作为更新后的匹配结果。在这些可选的实施例中，在支付渠道的状态发生改变后，可动态的进行支付渠道的匹配，并实时生效，而无需依赖于商户端的请求进行匹配，进而实现在商户端无感知的情况下完成匹配结果的更新，并可进一步通过步骤S240进行支付渠道更新后的进件处理，生成新的支付参数以保障支付能力，该过程中，商户端感知不到渠道以及渠道更新，可专注于业务的选择。

举例来说，在匹配出当面付业务的支付渠道为支付渠道b后，监测到支付渠道b的状态信息更新为下线状态，以及新上线支付渠道c，且设置该支付渠道c适用于当面付业务，此时，则匹配出当面付业务的支付渠道为支付渠道c，然后对匹配结果进行更新。

步骤S230：向商户端返回正在处理的通知。

在得到匹配结果后，及时告知商户端进件请求正在处理中，以使商户端明确进件进展。

需要在此说明的是，在根据状态改变情况对匹配结果进行更新的可选实施例中，该更新并不是根据商户端的请求而执行的，针对这种情况，在进行匹配结果的更新后，跳过该步骤S230而直接执行步骤S240，以实现进件渠道以及支付参数更新全过程的商户端无感知。

步骤S240：调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。

其中，在得到匹配结果或对匹配结果进行更新后均需执行该步骤S240，以完成进件处理，需要注意的是，对于匹配结果更新的情况，不仅需要进行进件处理，还需关闭历史匹配出的、而更新后不存在的支付渠道的支付参数的使用，避免支付出错。

具体地，当业务列表中包含多个业务和/或针对某一个或多个业务匹配出多个支付渠道时，则进件任务有多个。此时，步骤S240进一步包括，步骤S241，根据匹配结果，提取未处理的进件任务，一个进件任务用于处理一个业务进件到一个支付渠道，其中，可将处理同一业务的进件任务依次连续提取，以便按业务有序的完成进件处理，例如，共涉及点餐和当面付两种业务，且每个业务均匹配出两个支付渠道，则可第一、二次分别提取出处理点餐业务的两个进件任务，第三、四次分别提取出处理当面付业务的两个进件任务。步骤S242，调度向收单系统发起的未处理的进件任务，调度当前提取出的未处理的进件任务，向收单系统发起进件，收单系统针对该未处理的进件任务进行进件处理。步骤S243，定时轮询进件任务，查询收单系统返回的进件结果，每当调度一个进件任务向收单系统发起进件后，进件系统则定时轮询该进件任务，以确定该次进件是否完成以及确定进件结果。步骤S244，若进件结果为进件成功，则表明进件到某一个支付渠道，此时则跳转至步骤S241，以提取下一个未处理的进件任务并发起进件，依次类推，直至所有的进件任务处理完成，并且，在所有的进件任务处理完成后，根据进件结果向商户端反馈进件请求的处理结果。或者，若进件结果为进件失败，则表明未成功进件到某一个支付渠道，此时进件处理的过程结束，不再继续进行剩余的未处理的进件任务的进件，而根据进件结果向商户端反馈进件请求的处理结果。需要在此说明的是，当业务列表中包含多个业务时，则向商户端反馈的处理结果包含多个业务的处理结果，以使商户明确各个业务的处理结果。

进一步的，在步骤S243之后，若进件结果为进件处理中，则表明收单系统的进件处理过程还未完成，此时，则重复执行步骤S243，直至查询到进件成功或进件失败的进件结果。

在一些可选的实施方式中，根据进件结果向商户端反馈进件请求的处理结果的过程具体如下：当所有的进件任务的进件结果为进件成功时，则向商户端反馈进件成功的处理结果；或者，当对于当前提取的未处理的进件任务，其进件结果为进件失败，则根据用于处理当前业务的进件任务中进件成功的次数向商户端反馈进件请求的处理结果，其中，当前业务是指当前提取的未处理订单所处理的业务，可选的，当用于处理当前业务的进件任务中存在至少一个进件成功的进件任务时，则向商户端反馈当前业务进件成功。

在本实施例中，在同步受理商户端的进件请求后，一旦得到匹配结果，则向商户端返回正在处理的通知；以及，通过异步处理来向收单系统发起进件，最终再异步告知商户端处理结果，这种进件处理的方式，可使得商户端的进件流程更自然，交互更加友好。

另外，针对步骤S210中提到的两种不同的进件请求的时机，由于存在是否有过进件成功的处理结果的区别，在向收单系统发起进件时，提供给收单系统进行进件处理的信息也不同，同时，通过调用收单系统不同的接口来发起进件，以使收单系统可采用不同的方式进行进件处理，进而提高进件效率。

其一，针对在进件请求之前商户端未接收到过进件成功的处理结果的情况，在这种情况中，进件请求中携带有审核信息和业务列表，在每次提取出未处理的进件任务并向收单系统发起进件之前，判断是否存在已进件成功的进件任务，若不存在进件成功的进件任务，则调度未处理的进件任务向收单系统的第一指定接口发起进件，其中，第一指定接口为收单系统用于根据审核信息进行进件的接口，此时，未处理的进件任务中携带一个支付渠道的渠道信息以及审核信息，该渠道信息即为进件任务处理的一个支付渠道的渠道信息(具体可为渠道标识)，收单系统在接收到第一指定接口的调用之后，对携带的审核信息进行处理，以及分配对应该一个支付渠道的支付参数；若存在进件成功的任务，则调度未处理的进件任务向收单系统的第二指定接口发起进件，其中，第二指定接口为收单系统用于仅根据支付渠道的渠道信息进行进件的接口，此时，未处理的进件任务中携带一个支付渠道的渠道信息，同样的，该渠道信息即为进件任务处理的一个支付渠道的渠道信息(具体可为渠道标识)，收单系统在接收到第二指定接口的调用之后，无需对审核信息进行处理，而只需分配对应该一个支付渠道的支付参数。通过该方式，即使在进件请求之前商户端未接收到过进件成功的处理结果，在进件的过程中，可根据进件任务实时的进件结果，在存在进件成功的进件任务时，则调用收单系统的第二指定接口进行进件，并且仅在进件任务中携带支付渠道的渠道信息，避免对审核信息的重复处理而导致进件效率低。

上述这种方式的一种典型情形为商户端首次发起进件请求。具体地，针对一个商户端，在首次发起进件请求且调度第一个进件任务时，此时不存在进件成功的进件任务，则通过第一指定接口发起进件；若该第一个进件任务进件成功，则在该首次发起进件请求后的后续调度中，通过第二指定接口发起进件。

其二，针对在进件请求之前商户端接收到过进件成功的处理结果的情况，在这种情况中，则认为审核信息已处理通过，在每次向收单系统发起进件时，调度未处理的进件任务向收单系统的第二指定接口发起进件，其中，未处理的进件任务中携带一个支付渠道的渠道信息。该方式与前一种情况中存在进件成功的进件任务的进件方式相同，具体可参见上文中的说明，此处不再赘述。通过该方式，在进件请求之前商户端接收到过进件成功的处理结果，则所有的进件任务可向收单系统的第二指定接口发起进件，且进件任务中不携带审核信息，避免重复处理，使收单系统可快速进行进件处理，提高处理效率。

上述这种方式的一种典型情形为商户端针对新的业务发起进件请求，同时期望该新的业务与此前的进件请求针对的业务之间交易隔离。具体地，在商户端通过选择该新的业务并发起进件请求，而由于之前已针对其它业务完成过进件，则可通过第二指定接口向收单系统发起进件，以快速完成对该新的业务的进件处理，而无需商户端再次提供审核信息，也无需收单系统对审核信息进行重复处理。可见，利用这种方式，当有新的业务需要再次发起进件时，只需要选择该业务并发起进件请求即可，极大的提升了商户端的进件体验。

最后，为了便于对本实施例方案的理解，下面以一个完整的示例来说明进件处理方案的具体过程。图3示出了本发明一个具体实施例中进件处理过程中商户-进件系统-收单系统三端交互的示意图。如图3所示，商户端在发起进件请求前，主要是决定本次发起进件的适用业务(在未接收到过进件成功的处理结果的情况下，例如首次发起进件请求时，还需准备审核信息)，而完全无需理解业务最终进件到的支付渠道；同时，对于收单系统，无需感知到进件请求适用的业务。基于此，所有复杂的逻辑都在进件系统中进行处理，对于商户端和收单系统完全透明。由进件系统匹配商户端选择的业务最终可以进件到哪些支付渠道，该匹配过程是动态配置且实时生效的，便于发生异常或调整时，进件系统侧快速调整策略，开放或关闭某些渠道，或者可针对不同的商户端进行特殊处理。以及，当匹配出渠道列表后，则立即返回商户端告知正在处理，极大提升了进件体验；然后依靠调度任务，根据收单系统提供的不同接口，完成所有渠道的进件，最终告知商户端针对选定的业务的处理结果。

根据本实施例提供的进件处理方法，可通过在商户端选择业务向进件系统发起进件请求，然后由进件系统针对该业务进行进件处理，为该业务匹配出至少一个支付渠道以及调度进件任务进行进件到每个支付渠道的处理，使得进件处理的全过程与业务相适应，同时可便于商户端明确业务的进件情况，例如，明确业务的资金与收款账户的对应关系；其中，进件系统可从多个支付渠道中动态的为业务匹配出支付渠道，便于进件系统对支付渠道的管理与调整，同时可在商户端无感知的情况下完成匹配；以及，由进件系统在商户端和收单系统之间进行进件过程中的协调处理，包括渠道匹配、任务调度及查询等，上述过程对于商户端和收单系统完全透明，使得商户端无需理解业务最终进件到的支付渠道，收单系统无需感知进件请求针对的业务，有机协调了商户端和收单系统之间的能力割裂，使得进件处理的过程更加顺畅；并且，在通过调度进件任务向收单系统发起进件时，根据是否存在进件成功的进件任务，调用收单系统的不同接口发起进件，避免重复处理，提高收单系统的进件处理效率。由此可见，本实施例提供了一种可将任意业务进件到多个支付渠道中的至少一个支付渠道的方案，有利于商户端通过选定业务进行针对业务的进件；并且，至少一个支付渠道可以动态配置、实时生效，无需商户端感知到支付渠道以及支付渠道的调整，以及无需进行重复请求，方便了商户端的操作，同时便于多业务、多支付渠道的进件管理。

图4示出了根据本发明一个实施例的进件系统的功能框图。如图4所示，该系统包括：

接收模块410，适于接收商户端发起的携带业务列表的进件请求；

匹配模块420，适于为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道，作为匹配结果；

进件模块430，适于调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询所述进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。

在一种可选的实施方式中，所述系统还包括：通知模块，适于向商户端返回正在处理的通知。

在一种可选的实施方式中，所述进件模块进一步适于：

根据匹配结果，提取未处理的进件任务，一个进件任务用于处理一个业务进件到一个支付渠道；

调度向收单系统发起的所述未处理的进件任务；

定时轮询所述进件任务，查询收单系统返回的进件结果；

若所述进件结果为进件成功，则跳转执行根据匹配结果，提取未处理的进件任务，直至所有的进件任务处理完成，则根据进件结果向商户端反馈进件请求的处理结果；若所述进件结果为进件失败，则根据进件结果向商户端反馈进件请求的处理结果。

在一种可选的实施方式中，所述进件模块进一步适于：当所有的进件任务的进件结果为进件成功时，则向商户端反馈进件成功的处理结果；或者，

若所述进件结果为进件失败，则根据用于处理当前业务的进件任务中进件成功的次数向商户端反馈进件请求的处理结果。

在一种可选的实施方式中，所述进件模块进一步适于：若所述进件结果为进件处理中，则跳转执行定时轮询所述进件任务，查询收单系统返回的进件结果。

在一种可选的实施方式中，若在所述进件请求之前商户端未接收到过进件成功的处理结果，则所述进件请求中还携带有商户端的审核信息；

所述进件模块进一步适于：判断是否存在已进件成功的进件任务；若否，则调度未处理的进件任务向收单系统的第一指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息以及审核信息；若是，则调度未处理的进件任务向收单系统的第二指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息。

在一种可选的实施方式中，若在所述进件请求之前商户端接收到过进件成功的处理结果，所述进件模块进一步适于：

调度未处理的进件任务向收单系统的第二指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息。

在一种可选的实施方式中，所述系统还包括：申请模块，适于向收单系统申请得到多个支付渠道；

所述匹配模块进一步适于：从所述多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道。

在一种可选的实施方式中，所述匹配模块进一步适于：

查询各个支付渠道的业务配置；针对所述业务列表中的每个业务，将该业务的业务信息与各个支付渠道的业务配置进行匹配，将匹配一致的支付渠道确定为该业务的支付渠道。

在一种可选的实施方式中，所述匹配模块进一步适于：

监测模块，适于监测多个支付渠道的状态信息；其中，所述状态信息包括故障状态、下线状态、新上线状态和/或业务更改状态；根据所述状态信息确定多个可用的支付渠道作为更新后的多个支付渠道；

从所述更新后的多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道；

进件模块进一步适于：调用向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务以进行进件处理。

本申请实施例提供了一种非易失性计算机存储介质，所述计算机存储介质存储有至少一可执行指令，该计算机可执行指令可执行上述任意方法实施例中的进件处理方法。

图5示出了根据本发明实施例的一种服务器的结构示意图，本发明具体实施例并不对服务器的具体实现做限定。

如图5所示，该服务器可以包括：处理器(processor)502、通信接口(Communications Interface)504、存储器(memory)506、以及通信总线508。

其中：

处理器502、通信接口504、以及存储器506通过通信总线508完成相互间的通信。

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

处理器502，用于执行程序510，具体可以执行上述进件处理方法实施例中的相关步骤。

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

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

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

程序510具体可以用于使得处理器502执行以下操作：

接收商户端发起的携带业务列表的进件请求；

为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道，作为匹配结果；

调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询所述进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。

在一种可选的实施方式中，程序510具体可以进一步用于使得处理器502执行以下操作：向商户端返回正在处理的通知。

在一种可选的实施方式中，程序510具体可以进一步用于使得处理器502执行以下操作：步骤S10，根据匹配结果，提取未处理的进件任务，一个进件任务用于处理一个业务进件到一个支付渠道；

步骤S11，调度向收单系统发起的所述未处理的进件任务；

步骤S12，定时轮询所述进件任务，查询收单系统返回的进件结果；

步骤S13，若所述进件结果为进件成功，则跳转步骤S10，直至所有的进件任务处理完成，执行步骤S14；若所述进件结果为进件失败，则执行步骤S14；

步骤S14，根据进件结果向商户端反馈进件请求的处理结果。

在一种可选的实施方式中，程序510具体可以进一步用于使得处理器502执行以下操作：当所有的进件任务的进件结果为进件成功时，则向商户端反馈进件成功的处理结果；或者，若所述进件结果为进件失败，则根据用于处理当前业务的进件任务中进件成功的次数向商户端反馈进件请求的处理结果。

在一种可选的实施方式中，程序510具体可以进一步用于使得处理器502执行以下操作：若所述进件结果为进件处理中，则跳转步骤S12。

在一种可选的实施方式中，若在所述进件请求之前商户端未接收到过进件成功的处理结果，则所述进件请求中还携带有商户端的审核信息；程序510具体可以进一步用于使得处理器502执行以下操作：判断是否存在已进件成功的进件任务；若否，则调度未处理的进件任务向收单系统的第一指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息以及审核信息；若是，则调度未处理的进件任务向收单系统的第二指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息。

在一种可选的实施方式中，若在所述进件请求之前商户端接收到过进件成功的处理结果，程序510具体可以进一步用于使得处理器502执行以下操作：调度未处理的进件任务向收单系统的第二指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息。

在一种可选的实施方式中，程序510具体可以进一步用于使得处理器502执行以下操作：向收单系统申请得到多个支付渠道；

从所述多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道。

在一种可选的实施方式中，程序510具体可以进一步用于使得处理器502执行以下操作：查询各个支付渠道的业务配置；针对所述业务列表中的每个业务，将该业务的业务信息与各个支付渠道的业务配置进行匹配，将匹配一致的支付渠道确定为该业务的支付渠道。

在一种可选的实施方式中，程序510具体可以进一步用于使得处理器502执行以下操作：

监测多个支付渠道的状态信息；其中，所述状态信息包括故障状态、下线状态、新上线状态和/或业务更改状态；根据所述状态信息确定多个可用的支付渠道作为更新后的多个支付渠道；

从所述更新后的多个支付渠道中为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道，并调用向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务以进行进件处理。

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

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

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

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

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

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

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

Claims (10)

1.一种进件处理方法，包括：

接收商户端发起的携带业务列表的进件请求；

为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道，作为匹配结果；

调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询所述进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。

2.根据权利要求1所述的方法，其中，在所述为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道之后，所述方法还包括：向商户端返回正在处理的通知。

3.根据权利要求1或2所述的方法，其中，所述调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询所述进件任务，查询收单系统返回的进件结果，根据所述进件结果向商户端反馈进件请求的处理结果进一步包括：

步骤S10，根据匹配结果，提取未处理的进件任务，一个进件任务用于处理一个业务进件到一个支付渠道；

步骤S11，调度向收单系统发起的所述未处理的进件任务；

步骤S12，定时轮询所述进件任务，查询收单系统返回的进件结果；

步骤S13，若所述进件结果为进件成功，则跳转步骤S10，直至所有的进件任务处理完成，执行步骤S14；若所述进件结果为进件失败，则执行步骤S14；

步骤S14，根据进件结果向商户端反馈进件请求的处理结果。

4.根据权利要求3所述的方法，其中，所述步骤S14进一步包括：当所有的进件任务的进件结果为进件成功时，则向商户端反馈进件成功的处理结果；或者，

若所述进件结果为进件失败，则根据用于处理当前业务的进件任务中进件成功的次数向商户端反馈进件请求的处理结果。

5.根据权利要求3所述的方法，其中，在所述步骤S12之后，所述方法还包括：若所述进件结果为进件处理中，则跳转步骤S12。

6.根据权利要求3-5任一项所述的方法，其中，若在所述进件请求之前商户端未接收到过进件成功的处理结果，则所述进件请求中还携带有商户端的审核信息；

所述步骤S11进一步包括：判断是否存在已进件成功的进件任务；若否，则调度未处理的进件任务向收单系统的第一指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息以及审核信息；若是，则调度未处理的进件任务向收单系统的第二指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息。

7.根据权利要求3-5任一项所述的方法，其中，若在所述进件请求之前商户端接收到过进件成功的处理结果，所述步骤S11进一步包括：

调度未处理的进件任务向收单系统的第二指定接口发起进件，所述未处理的进件任务中携带一个支付渠道的渠道信息。

8.一种进件系统，包括：

接收模块，适于接收商户端发起的携带业务列表的进件请求；

匹配模块，适于为所述商户端匹配出所述业务列表中每个业务的至少一个支付渠道，作为匹配结果；

进件模块，适于调度向收单系统发起的用于处理一个业务进件到一个支付渠道的进件任务；定时轮询所述进件任务，查询收单系统返回的进件结果；根据进件结果向商户端反馈进件请求的处理结果。

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

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求1-7中任一项所述的进件处理方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求1-7中任一项所述的进件处理方法对应的操作。

Images