CN117333276A - 一种交易处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请实施例提供了一种交易处理方法、装置、设备及存储介质，涉及数据处理技术领域，包括：银行系统接收提供方系统发送的交易处理请求；若交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对交易处理请求的审批消息；若接收到多个共管方系统发送的针对交易处理请求的审批同意消息，则向提供方系统发送再次确认请求；若接收到提供方系统返回的再次确认消息，则基于目标资源量调整接收方账户的资源量；将交易处理成功消息返回给提供方系统。本申请实施例满足了监管主体多元化的需求，大大降低了对交易处理进行多方监管过程中的人工成本，有效提高了监管效率。

Description

一种交易处理方法、装置、设备及存储介质

技术领域

本申请实施例涉及数据处理技术领域，尤其涉及一种交易处理方法、装置、设备及存储介质。

背景技术

现有银行资金监管产品，在监管合约签约方面，大多由银行员工介入签约，即银行员工接收资料，召集相关方签订纸质合约，约定权责义务，银行员工再通过内部员工操作界面做签约的系统录入；在监管资金划转方面，大多由银行作为监管方，资金提供方和资金接收方为相关方，相关方都同意后，银行接收指令审核后，完成监管资金的划转。

但是，在一些业务场景下，除银行和资金提供方具有监管能力外，资金提供方的上级单位或者同级单位也需要具备监管能力。例如，在一些重点大型项目中，为确保项目资金的转款专用，项目业主(此为高级共管权)往往会对项目资金拨付的全流程进行监控，不仅要确保专项资金按照合同拨付至施工总包(资金提供方)，同时对施工总包的资金使用情况进行监控，以确保项目顺利推进。

然而，相关技术通过人工方式实现多方共同监管交易的执行，其成本高、监管效率低。

发明内容

本申请实施例提供了一种交易处理方法、装置、设备及存储介质，降低了对交易处理进行多方监管过程中的人工成本，有效提高了监管效率。

第一方面，本申请实施例提供了一种交易处理方法，应用于银行系统，包括：

接收提供方系统发送的交易处理请求；

若所述交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对所述交易处理请求的审批消息；

若接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息，则向所述提供方系统发送再次确认请求；

若接收到所述提供方系统返回的再次确认消息，则基于所述目标资源量调整接收方账户的资源量；

将交易处理成功消息返回给所述提供方系统。

本申请实施例通过提供方系统、银行系统和多个共管方系统交互执行，实现了交易处理监管纯线上化，降低了对交易处理进行多方监管过程中的人工成本，而且满足了监管主体多元化需求，有效提高了监管效率。

一种可选实施方式中，接收提供方系统发送的签约请求，所述签约请求包括：共管方信息、共管方权限和共管方审批顺序；

基于所述共管方信息、所述共管方权限和所述共管方审批顺序生成监管合约，并依次向关联的多个共管方系统发送携带所述监管合约的合约确认请求；

若接收到所述多个共管方系统发送的针对所述监管合约的合约确认消息，则确定签约完成。

本申请实施例通过提供方系统、银行系统和多个共管方系统交互执行，实现了监管合约签约过程纯线上化，降低了对交易处理进行多方监管过程中的人工成本，而且满足了监管主体多元化需求，有效提高了监管效率。

一种可选实施方式中，接收提供方系统发送的重置申请，所述重置申请包括：与所述监管合约关联的共管方调整信息和审批顺序调整信息；

基于所述共管方调整信息和所述审批顺序调整信息生成针对所述监管合约的重置协议，并依次向关联的多个共管方系统发送携带所述重置协议的审批确认请求；

若接收到所述多个共管方系统发送的针对所述重置协议的审批确认消息，则基于所述重置协议重置所述监管合约，获得更新后的监管合约；

若接收到至少一个共管方系统发送的针对所述重置协议的审批拒绝消息，则向提供方系统返回审核不通过的消息。

本申请实施例通过提供方系统、银行系统和多个共管方系统交互执行，实现了监管合约重置过程的纯线上化，降低了对交易处理进行多方监管过程中的人工成本，而且满足了监管主体多元化需求，有效提高了监管效率。

一种可选实施方式中，若所述交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对所述交易处理请求的审批消息；

若接收到至少一个共管方系统发送的针对所述交易处理请求的审批拒绝消息，则向提供方系统返回审核不通过的消息。

一种可选实施方式中，若接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息，则向所述提供方系统发送再次确认请求；

若接收到所述提供方系统发送的拒绝确认消息，则依次向多个共管方系统发送针对所述拒绝确认消息的审批请求；

若接收到所述多个共管方系统发送的针对所述审批请求的审批同意消息，则将结束本次交易处理请求，并返回结束交易消息给所述提供方系统；

若接收到至少一个共管方系统发送的针对所述审批请求的审批拒绝消息，则基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统。

第二方面，本申请实施例提供了一种交易处理方法，应用于提供方系统，包括：

向银行系统发送交易处理请求，以使所述银行系统在确定所述交易处理请求关联的目标资源量满足预设条件，依次向多个共管方系统发送针对所述交易处理请求的审批消息；并且，接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息时，向所述提供方系统发送再次确认请求；

向银行系统返回再次确认消息，以使所述银行系统基于所述目标资源量调整接收方账户的资源量；以及将交易处理成功消息返回给所述提供方系统。

一种可选实施方式中，向银行系统发送签约请求，以使所述银行系统基于所述签约请求生成监管合约，并依次向关联的多个共管方系统发送携带所述监管合约的合约确认请求；并且，接收到所述多个共管方系统发送的针对所述监管合约的合约确认消息时，确定签约完成；其中，所述签约请求包括：共管方信息、共管方权限和共管方审批顺序。

一种可选实施方式中，向银行系统发送重置申请，以使所述银行系统基于所述重置申请生成针对所述监管合约的重置协议，并依次向关联的多个共管方系统发送携带所述重置协议的审批确认请求；并且，若接收到所述多个共管方系统发送的针对所述重置协议的审批确认消息，则基于所述重置协议重置所述监管合约，获得更新后的监管合约；若接收到至少一个共管方系统发送的针对所述重置协议的审批拒绝消息，则向所述提供方系统返回审核不通过的消息；

接收所述银行系统返回的所述更新后的监管合约，或者返回的所述审核不通过的消息。

一种可选实施方式中，接收银行系统发送的再次确认请求之后，向银行系统发送拒绝确认消息，以使所述银行系统依次向多个共管方系统发送针对所述拒绝确认消息的审批请求；并且，接收到所述多个共管方系统发送的针对所述审批请求的审批同意消息时，结束本次交易处理请求，并返回结束交易消息给所述提供方系统；或者，接收到至少一个共管方系统发送的针对所述审批请求的审批拒绝消息时，基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统；

接收所述银行系统返回的结束交易消息，或者所述银行系统返回的交易处理成功消息。

第三方面，本申请实施例提供了一种交易处理方法，应用于多个共管方系统中的每个共管方系统，包括：

接收银行系统发送的针对交易处理请求的审批消息，其中，所述审批消息是所述银行系统确定所述交易处理请求关联的目标资源量满足预设条件时发送的，所述交易处理请求是提供方系统发送给所述银行系统的；

向所述银行系统发送针对所述交易处理请求的审批同意消息，以使所述银行系统接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息时，向所述提供方系统发送再次确认请求；并且，接收到所述提供方系统返回的再次确认消息时，基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统；或者，

向银行系统发送针对所述交易处理请求的审批拒绝消息，以使所述银行系统向提供方系统返回审核不通过的消息。

一种可选实施方式中，还包括：

接收所述银行系统发送的携带监管合约的合约确认请求，所述监管合约是所述银行系统基于提供方系统发送的签约请求生成的，所述签约请求包括：共管方信息、共管方权限和共管方审批顺序；

发送针对所述监管合约的合约确认消息至所述银行系统，以使所述银行系统在接收到所述多个共管方系统发送的针对所述监管合约的合约确认消息时，确定签约完成。

一种可选实施方式中，还包括：

接收所述银行系统发送的携带重置协议的审批确认请求，所述重置协议是所述银行系统基于提供方系统发送的重置申请生成的，所述重置申请包括：与所述监管合约关联的共管方调整信息和审批顺序调整信息；

向所述银行系统发送针对所述重置协议的审批确认消息，以使所述银行系统基于所述重置协议重置所述监管合约，获得更新后的监管合约；或者，

向银行系统发送针对所述重置协议的审批拒绝消息，以使所述银行系统向提供方系统返回审核不通过的消息。

一种可选实施方式中，还包括：

接收所述银行系统发送的针对拒绝确认消息的审批请求，所述拒绝确认消息是所述提供方系统接收到所述再次确认请求时发送至所述银行系统的；

向银行系统发送针对所述审批请求的审批同意消息，以使所述银行系统接收到所述多个共管方系统发送的针对所述审批请求的审批同意消息时，结束本次交易处理请求，并返回结束交易消息给所述提供方系统；或者，

向银行系统发送针对所述审批请求的审批拒绝消息，以使所述银行系统基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统。

第四方面，本申请实施例提供了一种交易处理方法，包括：

获取交易处理请求；

若所述交易处理请求关联的目标资源量满足预设条件，则对所述交易处理请求进行多方审批，获得审批结果；

若所述审批结果为多方审批通过，则对所述审批结果执行再次确认操作，获得再次确认结果；

若所述再次确认结果结果为通过，则基于所述目标资源量调整接收方账户的资源量。

第五方面，本申请实施例提供了一种交易处理装置，应用于银行系统，包括：

第一接收模块，用于接收提供方系统发送的交易处理请求；

第一发送模块，用于若所述交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对所述交易处理请求的审批消息；

所述第一发送模块，还用于若接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息，则向所述提供方系统发送再次确认请求；

第一处理模块，用于若接收到所述提供方系统返回的再次确认消息，则基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统。

第六方面，本申请实施例提供了一种交易处理装置，应用于提供方系统，包括：

第二发送模块，用于向银行系统发送交易处理请求，以使所述银行系统在确定所述交易处理请求关联的目标资源量满足预设条件，依次向多个共管方系统发送针对所述交易处理请求的审批消息；并且，接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息时，向所述提供方系统发送再次确认请求；

第二处理模块，用于向银行系统返回再次确认消息，以使所述银行系统基于所述目标资源量调整接收方账户的资源量；以及将交易处理成功消息返回给所述提供方系统。

第七方面，本申请实施例提供了一种交易处理装置，应用于多个共管方系统中的每个共管方系统，包括：

第三接收模块，用于接收银行系统发送的针对交易处理请求的审批消息，其中，所述审批消息是所述银行系统确定所述交易处理请求关联的目标资源量满足预设条件时发送的，所述交易处理请求是提供方系统发送给所述银行系统的；

第三发送模块，用于向所述银行系统发送针对所述交易处理请求的审批同意消息，以使所述银行系统接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息时，向所述提供方系统发送再次确认请求；并且，接收到所述提供方系统返回的再次确认消息时，基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统；或者，

所述第三发送模块，还用于向银行系统发送针对所述交易处理请求的审批拒绝消息，以使所述银行系统向提供方系统返回审核不通过的消息。

第八方面，本申请实施例提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述交易处理方法的步骤。

第九方面，本申请实施例提供了一种计算机可读存储介质，其存储有可由计算机设备执行的计算机程序，当所述程序在计算机设备上运行时，使得所述计算机设备执行上述交易处理方法的步骤。

第十方面，本申请实施例提供了一种计算机程序产品，所述计算机程序产品包括存储在计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机设备执行时，使所述计算机设备执行上述交易处理方法的步骤。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种系统架构的结构示意图；

图2为本申请实施例提供的一种交易处理方法的流程示意图；

图3为本申请实施例提供的一种交易处理方法的流程示意图；

图4为本申请实施例提供的一种交易处理方法的流程示意图；

图5为本申请实施例提供的一种交易处理方法的流程示意图；

图6为本申请实施例提供的一种交易处理方法的流程示意图；

图7为本申请实施例提供的一种交易处理方法的流程示意图；

图8为本申请实施例提供的一种交易处理装置的结构示意图；

图9为本申请实施例提供的一种交易处理装置的结构示意图；

图10为本申请实施例提供的一种交易处理装置的结构示意图；

图11为本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

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

需要说明的是，本申请技术方案中对数据的获取、存储、使用、处理等均符合国家法律法规的相关规定，后续不再赘述。

参见图1，其为本申请实施例适用的一种系统架构图，该系统架构至少包括银行系统101、提供方系统102和多个共管方系统103，提供方系统和共管方系统可以是终端设备，终端设备中预先安装应用(比如网银应用)，其中，应用是客户端应用、网页版应用、小程序应用等。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此。

银行系统101是应用的后台服务器，银行系统101可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，简称CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。提供方系统102和多个共管方系统103分别与银行系统101可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

需说明的是，本申请提供的交易处理方法的应用场景包括：资金支付、资金退回、施工总包资金监管等应用场景。

基于图1所示的系统架构图，本申请实施例提供了一种交易处理方法的流程，如图2所示，该方法的流程由银行系统、提供方系统和多个共管方系统中的每个共管方系统交互执行，包括以下步骤：

步骤201，银行系统接收提供方系统发送的交易处理请求。

一种可选实施方式中，交易处理请求可以是：资金支付请求、资金退回请求等。

步骤202，若交易处理请求关联的目标资源量满足预设条件，则银行系统依次向多个共管方系统发送针对交易处理请求的审批消息。

具体地，目标资源量指：目标资金金额等；预设条件可以是：最低审批资金金额等。

银行系统接收提供方系统发送的交易处理请求，若交易处理请求关联的目标资金金额高于最低审批资金金额，则依次向多个共管方系统发送针对交易处理请求的审批消息。

步骤203，银行系统接收到多个共管方系统发送的针对交易处理请求的审批同意消息。

步骤204，银行系统向提供方系统发送再次确认请求。

一种可选实施方式中，银行系统若接收到至少一个共管方系统发送的针对交易处理请求的审批拒绝消息，则向提供方系统返回审核不通过的消息。

步骤205，银行系统接收到提供方系统返回的再次确认消息。

步骤206，银行系统基于目标资源量调整接收方账户的资源量。

具体地，以资金支付为例，银行系统向资金接收方支付目标资金金额。

步骤207，银行系统将交易处理成功消息返回给提供方系统。

一种可选实施方式中，银行系统接收到提供方系统发送的拒绝确认消息，则依次向多个共管方系统发送针对拒绝确认消息的审批请求；

若接收到多个共管方系统发送的针对审批请求的审批同意消息，银行系统则将结束本次交易处理请求，并返回结束交易消息给提供方系统；

若接收到至少一个共管方系统发送的针对审批请求的审批拒绝消息，银行系统则基于目标资源量调整接收方账户的资源量；将交易处理成功消息返回给提供方系统。

为了更好的解释本申请实施例，以资金支付申请审批为例进行说明，参见图3。提供方系统向银行系统发送资金支付申请，若申请支付的资金金额低于最低审批金额，则无需审批；若申请支付的资金金额高于最低审批金额，银行系统按照监管合约中约定的审批顺序依次向多个共管方系统(共管方系统1、共管方系统2和共管方系统3)发送针对资金支付申请的审批消息，多个共管方系统中的每个共管方系统可以确认或者拒绝。当多个共管方系统都审核通过，银行系统向提供方系统发送再次确认消息，由提供方系统再次确认支付，若银行系统接收到提供方系统返回的再次确认消息，则向接收方系统B支付目标审批金额；当至少一个共管方系统审核不通过，银行系统则结束本次交易任务。

在整个过程中，资金提供方可以通过提供方系统，且共管方可以通过共管方系统查询本次或者历史支付审批的流程实例信息。此外，本申请实施例提供的交易处理方法支持单笔交易，也支持批量交易，本申请对此不做限制。

本申请实施例通过提供方系统、银行系统和多个共管方系统交互执行，实现了交易处理监管纯线上化，大大降低了对交易处理进行多方监管过程中的人工成本，而且满足了监管主体多元化需求，有效提高了监管效率。

一种可选实施方式中，在对交易处理之前，需要签署监管合约，参见图4，本申请实施例提供了一种监管合约的签约流程，包括以下步骤：

步骤401，银行系统接收提供方系统发送的签约请求。

一种可选实施方式中，签约请求包括：共管方信息、共管方权限和共管方审批顺序。

具体地，共管方信息可以是：共管方的电子银行账户等；共管方权限可以是查询权限、支付审批权限等，不同的共管方可以设置不同的权限；共管方审批顺序可以是交易查询的审批顺序，也可以是支付审批的顺序等，本申请对此不作限制。

步骤402，银行系统基于签约请求生成监管合约，并依次向关联的多个共管方系统发送携带监管合约的合约确认请求。

步骤403，银行系统接收到多个共管方系统发送的针对监管合约的合约确认消息，则确定签约完成。

为了更好的解释本申请实施例，参见图5，以银行资金监管合约签约场景为例，提供方系统向银行系统发送签约申请，银行系统通过提供方系统录入的共管方信息、共管方权限和共管方审批顺序生成监管合约，此时，监管合约为预签约状态，银行系统依次向关联的多个共管方系统(共管方系统1、共管方系统2和共管方系统3)发送携带监管合约的合约确认请求，当银行系统接收到多个共管方系统发送的针对监管合约的合约确认消息，合约状态转为已签约状态，则签约完成，提供方和共管方后续可以通过银行系统查询监管合约信息。

本申请实施例通过提供方系统、银行系统和多个共管方系统交互执行，实现了监管合约签约过程纯线上化，大大降低了对交易处理进行多方监管过程中的人工成本，而且满足了监管主体多元化需求，有效提高了监管效率。

在监管合约签署完成之后，参见图6，本申请实施例还提供了一种监管合约的重置流程，包括以下步骤：

步骤601，银行系统接收提供方系统发送的重置申请。

一种可选实施方式中，重置申请包括：与监管合约关联的共管方调整信息和审批顺序调整信息。

具体地，与监管合约关联的共管方调整信息指：重置前的共管方信息和重置后的共管方信息；与监管合约关联的审批顺序调整信息指：重置前的审批顺序和重置后的审批顺序。

步骤602，银行系统基于重置申请生成针对监管合约的重置协议，并依次向关联的多个共管方系统发送携带重置协议的审批确认请求。

步骤603，银行系统接收到多个共管方系统发送的针对重置协议的审批确认消息，则基于重置协议重置监管合约，获得更新后的监管合约。

一种可选实施方式中，银行系统接收到至少一个共管方系统发送的针对重置协议的审批拒绝消息，则向提供方系统返回审核不通过的消息。

为了更好的解释本申请实施例，参见图7，监管合约签署完成之后，后续一旦需要变更共管方或者变更交易审核流程，需要提供方系统向银行系统发起重置申请，银行系统基于重置申请生成针对监管合约的重置协议，并依次向变更前关联的多个共管方系统(共管方系统1、共管方系统2和共管方系统3)发送携带重置协议的审批确认请求，重置协议状态为待确认状态，当银行系统接收到多个共管方系统发送的针对重置协议的审批确认消息，则重置协议生效，银行系统基于重置协议重置监管合约，获得更新后的监管合约；当银行系统接收到至少一个共管方系统发送的针对重置协议的审批拒绝消息，则向提供方系统返回审核不通过的消息，即本次重置失败。

本申请实施例通过提供方系统、银行系统和多个共管方系统交互执行，实现了监管合约重置过程的纯线上化，大大降低了对交易处理进行多方监管过程中的人工成本，而且满足了监管主体多元化需求，有效提高了监管效率。

基于相同的技术构思，本申请实施例提供了一种交易处理装置，参见图8，包括：

第一接收模块801，用于接收提供方系统发送的交易处理请求；

第一发送模块802，用于若交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对交易处理请求的审批消息；

若接收到多个共管方系统发送的针对交易处理请求的审批同意消息，则向提供方系统发送再次确认请求；

第一处理模块803，用于若接收到提供方系统返回的再次确认消息，则基于目标资源量调整接收方账户的资源量；将交易处理成功消息返回给提供方系统。

一种可选实施方式中，第一接收模块801还用于：

接收提供方系统发送的签约请求，签约请求包括：共管方信息、共管方权限和共管方审批顺序。

第一发送模块802还用于：

基于共管方信息、共管方权限和共管方审批顺序生成监管合约，并依次向关联的多个共管方系统发送携带监管合约的合约确认请求。

第一处理模块803还用于：

接收到多个共管方系统发送的针对监管合约的合约确认消息，则确定签约完成。

一种可选实施方式中，第一接收模块801还用于接收提供方系统发送的重置申请，重置申请包括：与监管合约关联的共管方调整信息和审批顺序调整信息。

第一发送模块802还用于：

基于共管方调整信息和审批顺序调整信息生成针对监管合约的重置协议，并依次向关联的多个共管方系统发送携带重置协议的审批确认请求。

第一处理模块803还用于：

若接收到多个共管方系统发送的针对重置协议的审批确认消息，则基于重置协议重置监管合约，获得更新后的监管合约；若接收到至少一个共管方系统发送的针对重置协议的审批拒绝消息，则向提供方系统返回审核不通过的消息。

一种可选实施方式中，第一发送模块802还用于：

若交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对交易处理请求的审批消息；

若接收到至少一个共管方系统发送的针对交易处理请求的审批拒绝消息，则向提供方系统返回审核不通过的消息。

一种可选实施方式中，第一处理模块803还用于：

若接收到提供方系统发送的拒绝确认消息，则依次向多个共管方系统发送针对拒绝确认消息的审批请求；

若接收到多个共管方系统发送的针对审批请求的审批同意消息，则将结束本次交易处理请求，并返回结束交易消息给提供方系统；

若接收到至少一个共管方系统发送的针对审批请求的审批拒绝消息，则基于目标资源量调整接收方账户的资源量；将交易处理成功消息返回给提供方系统。

基于相同的技术构思，本申请实施例提供了一种交易处理装置，参见图9，包括：

第二发送模块901，用于向银行系统发送交易处理请求，以使银行系统在确定交易处理请求关联的目标资源量满足预设条件，依次向多个共管方系统发送针对交易处理请求的审批消息；并且，接收到多个共管方系统发送的针对交易处理请求的审批同意消息时，向提供方系统发送再次确认请求；

第二处理模块902，用于向银行系统返回再次确认消息，以使银行系统基于目标资源量调整接收方账户的资源量；以及将交易处理成功消息返回给提供方系统。

一种可选实施方式中，第二发送模块901还用于：

向银行系统发送签约请求，以使银行系统基于签约请求生成监管合约，并依次向关联的多个共管方系统发送携带监管合约的合约确认请求；并且，接收到多个共管方系统发送的针对监管合约的合约确认消息时，确定签约完成；其中，签约请求包括：共管方信息、共管方权限和共管方审批顺序。

一种可选实施方式中，第二发送模块901还用于：

向银行系统发送重置申请，以使银行系统基于重置申请生成针对监管合约的重置协议，并依次向关联的多个共管方系统发送携带重置协议的审批确认请求；并且，若接收到多个共管方系统发送的针对重置协议的审批确认消息，则基于重置协议重置监管合约，获得更新后的监管合约；若接收到至少一个共管方系统发送的针对重置协议的审批拒绝消息，则向提供方系统返回审核不通过的消息。

一种可选实施方式中，还包括第二接收模块903；

第二接收模块903具体用于：

接收银行系统返回的交易处理成功消息、结束交易消息、更新后的监管合约，或者银行系统返回的审核不通过的消息。

一种可选实施方式中，第二处理模块902还用于：

接收银行系统发送的再次确认请求之后，向银行系统发送拒绝确认消息，以使银行系统依次向多个共管方系统发送针对拒绝确认消息的审批请求；并且，接收到多个共管方系统发送的针对审批请求的审批同意消息时，结束本次交易处理请求，并返回结束交易消息给提供方系统；或者，接收到至少一个共管方系统发送的针对审批请求的审批拒绝消息时，基于目标资源量调整接收方账户的资源量；将交易处理成功消息返回给提供方系统。

基于相同的技术构思，本申请实施例提供了一种交易处理装置，参见图10，包括：

第三接收模块1001，用于接收银行系统发送的针对交易处理请求的审批消息，其中，审批消息是银行系统确定交易处理请求关联的目标资源量满足预设条件时发送的，交易处理请求是提供方系统发送给银行系统的；

第三发送模块1002，用于向银行系统发送针对交易处理请求的审批同意消息，以使银行系统接收到多个共管方系统发送的针对交易处理请求的审批同意消息时，向提供方系统发送再次确认请求；并且，接收到提供方系统返回的再次确认消息时，基于目标资源量调整接收方账户的资源量；将交易处理成功消息返回给提供方系统；或者，

向银行系统发送针对交易处理请求的审批拒绝消息，以使银行系统向提供方系统返回审核不通过的消息。

一种可选实施方式中，第三接收模块1001还用于：

接收银行系统发送的携带监管合约的合约确认请求，监管合约是银行系统基于提供方系统发送的签约请求生成的，签约请求包括：共管方信息、共管方权限和共管方审批顺序。

第三发送模块1002还用于发送针对监管合约的合约确认消息至银行系统，以使银行系统在接收到多个共管方系统发送的针对监管合约的合约确认消息时，确定签约完成。

一种可选实施方式中，第三接收模块1001还用于：

接收银行系统发送的携带重置协议的审批确认请求，重置协议是银行系统基于提供方系统发送的重置申请生成的，重置申请包括：与监管合约关联的共管方调整信息和审批顺序调整信息。

第三发送模块1002还用于向银行系统发送针对重置协议的审批确认消息，以使银行系统基于重置协议重置监管合约，获得更新后的监管合约；或者，

向银行系统发送针对重置协议的审批拒绝消息，以使银行系统向提供方系统返回审核不通过的消息。

一种可选实施方式中，第三接收模块1001还用于：接收银行系统发送的针对拒绝确认消息的审批请求，拒绝确认消息是提供方系统接收到再次确认请求时发送至银行系统的。

第三发送模块1002还用于：

向银行系统发送针对审批请求的审批同意消息，以使银行系统接收到多个共管方系统发送的针对审批请求的审批同意消息时，结束本次交易处理请求，并返回结束交易消息给提供方系统；或者，

向银行系统发送针对审批请求的审批拒绝消息，以使银行系统基于目标资源量调整接收方账户的资源量；将交易处理成功消息返回给提供方系统。

本申请实施例通过提供方系统、银行系统和多个共管方系统交互执行，实现了交易处理监管纯线上化，大大减少了人工成本，而且满足了监管主体多元化需求，有效提高了监管效率。

基于相同的技术构思，本申请实施例提供了一种计算机设备，该计算机设备可以是图1所示的银行系统和/或提供方系统和/或多个共管方系统，如图11所示，包括至少一个处理器1101，以及与至少一个处理器连接的存储器1102，本申请实施例中不限定处理器1101与存储器1102之间的具体连接介质，图11中处理器1101和存储器1102之间通过总线连接为例。总线可以分为地址总线、数据总线、控制总线等。

在本申请实施例中，存储器1102存储有可被至少一个处理器1101执行的指令，至少一个处理器1101通过执行存储器1102存储的指令，可以执行上述交易处理方法的步骤。

其中，处理器1101是计算机设备的控制中心，可以利用各种接口和线路连接计算机设备的各个部分，通过运行或执行存储在存储器1102内的指令以及调用存储在存储器1102内的数据，从而实现交易处理。可选的，处理器1101可包括一个或多个处理单元，处理器1101可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1101中。在一些实施例中，处理器1101和存储器1102可以在同一芯片上实现，在一些实施例中，它们也可以在独立的芯片上分别实现。

处理器1101可以是通用处理器，例如中央处理器(CPU)、数字信号处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请实施例中公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。

存储器1102作为一种非易失性计算机可读存储介质，可用于存储非易失性软件程序、非易失性计算机可执行程序以及模块。存储器1102可以包括至少一种类型的存储介质，例如可以包括闪存、硬盘、多媒体卡、卡型存储器、随机访问存储器(Random AccessMemory，RAM)、静态随机访问存储器(Static Random Access Memory，SRAM)、可编程只读存储器(Programmable Read Only Memory，PROM)、只读存储器(Read Only Memory，ROM)、带电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性存储器、磁盘、光盘等等。存储器1102是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机设备存取的任何其他介质，但不限于此。本申请实施例中的存储器1102还可以是电路或者其它任意能够实现存储功能的装置，用于存储程序指令和/或数据。

基于同一发明构思，本申请实施例提供了一种计算机可读存储介质，其存储有可由计算机设备执行的计算机程序，当程序在计算机设备上运行时，使得计算机设备执行上述交易处理方法的步骤。

基于同一发明构思，本申请实施例提供了一种计算机程序产品，所述计算机程序产品包括存储在计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机设备执行时，使所述计算机设备执行上述交易处理方法的步骤。

本领域内的技术人员应明白，本发明的实施例可提供为方法、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机设备或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机设备或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机设备或其他可编程数据处理设备上，使得在计算机设备或其他可编程设备上执行一系列操作步骤以产生计算机设备实现的处理，从而在计算机设备或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (14)

1.一种交易处理方法，应用于银行系统，其特征在于，包括：

接收提供方系统发送的交易处理请求；

若所述交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对所述交易处理请求的审批消息；

若接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息，则向所述提供方系统发送再次确认请求；

若接收到所述提供方系统返回的再次确认消息，则基于所述目标资源量调整接收方账户的资源量；

将交易处理成功消息返回给所述提供方系统。

2.如权利要求1所述的方法，其特征在于，所述接收提供方系统发送的交易处理请求之前，包括：

接收提供方系统发送的签约请求，所述签约请求包括：共管方信息、共管方权限和共管方审批顺序；

基于所述共管方信息、所述共管方权限和所述共管方审批顺序生成监管合约，并依次向关联的多个共管方系统发送携带所述监管合约的合约确认请求；

若接收到所述多个共管方系统发送的针对所述监管合约的合约确认消息，则确定签约完成。

3.如权利要求2所述的方法，其特征在于，所述若接收到所述多个共管方系统发送的针对所述监管合约的合约确认消息，则确定签约完成之后，还包括：

接收提供方系统发送的重置申请，所述重置申请包括：与所述监管合约关联的共管方调整信息和审批顺序调整信息；

基于所述共管方调整信息和所述审批顺序调整信息生成针对所述监管合约的重置协议，并依次向关联的多个共管方系统发送携带所述重置协议的审批确认请求；

若接收到所述多个共管方系统发送的针对所述重置协议的审批确认消息，则基于所述重置协议重置所述监管合约，获得更新后的监管合约；

若接收到至少一个共管方系统发送的针对所述重置协议的审批拒绝消息，则向提供方系统返回审核不通过的消息。

4.如权利要求1所述的方法，其特征在于，所述若所述交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对所述交易处理请求的审批消息之后，还包括：

若接收到至少一个共管方系统发送的针对所述交易处理请求的审批拒绝消息，则向提供方系统返回审核不通过的消息。

5.如权利要求1所述的方法，其特征在于，所述若接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息，则向所述提供方系统发送再次确认请求之后，还包括：

若接收到所述提供方系统发送的拒绝确认消息，则依次向多个共管方系统发送针对所述拒绝确认消息的审批请求；

若接收到所述多个共管方系统发送的针对所述审批请求的审批同意消息，则将结束本次交易处理请求，并返回结束交易消息给所述提供方系统；

若接收到至少一个共管方系统发送的针对所述审批请求的审批拒绝消息，则基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统。

6.一种交易处理方法，应用于提供方系统，其特征在于，包括：

向银行系统发送交易处理请求，以使所述银行系统在确定所述交易处理请求关联的目标资源量满足预设条件，依次向多个共管方系统发送针对所述交易处理请求的审批消息；并且，接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息时，向所述提供方系统发送再次确认请求；

向银行系统返回再次确认消息，以使所述银行系统基于所述目标资源量调整接收方账户的资源量；以及将交易处理成功消息返回给所述提供方系统。

7.一种交易处理方法，应用于多个共管方系统中的每个共管方系统，其特征在于，包括：

接收银行系统发送的针对交易处理请求的审批消息，其中，所述审批消息是所述银行系统确定所述交易处理请求关联的目标资源量满足预设条件时发送的，所述交易处理请求是提供方系统发送给所述银行系统的；

向所述银行系统发送针对所述交易处理请求的审批同意消息，以使所述银行系统接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息时，向所述提供方系统发送再次确认请求；并且，接收到所述提供方系统返回的再次确认消息时，基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统；或者，

向银行系统发送针对所述交易处理请求的审批拒绝消息，以使所述银行系统向提供方系统返回审核不通过的消息。

8.一种交易处理方法，其特征在于，包括：

获取交易处理请求；

若所述交易处理请求关联的目标资源量满足预设条件，则对所述交易处理请求进行多方审批，获得审批结果；

若所述审批结果为多方审批通过，则对所述审批结果执行再次确认操作，获得再次确认结果；

若所述再次确认结果结果为通过，则基于所述目标资源量调整接收方账户的资源量。

9.一种交易处理装置，应用于银行系统，其特征在于，包括：

第一接收模块，用于接收提供方系统发送的交易处理请求；

第一发送模块，用于若所述交易处理请求关联的目标资源量满足预设条件，则依次向多个共管方系统发送针对所述交易处理请求的审批消息；

所述第一发送模块，还用于若接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息，则向所述提供方系统发送再次确认请求；

第一处理模块，用于若接收到所述提供方系统返回的再次确认消息，则基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统。

10.一种交易处理装置，应用于提供方系统，其特征在于，包括：

第二发送模块，用于向银行系统发送交易处理请求，以使所述银行系统在确定所述交易处理请求关联的目标资源量满足预设条件，依次向多个共管方系统发送针对所述交易处理请求的审批消息；并且，接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息时，向所述提供方系统发送再次确认请求；

第二处理模块，用于向银行系统返回再次确认消息，以使所述银行系统基于所述目标资源量调整接收方账户的资源量；以及将交易处理成功消息返回给所述提供方系统。

11.一种交易处理装置，应用于多个共管方系统中的每个共管方系统，其特征在于，包括：

第三接收模块，用于接收银行系统发送的针对交易处理请求的审批消息，其中，所述审批消息是所述银行系统确定所述交易处理请求关联的目标资源量满足预设条件时发送的，所述交易处理请求是提供方系统发送给所述银行系统的；

第三发送模块，用于向所述银行系统发送针对所述交易处理请求的审批同意消息，以使所述银行系统接收到所述多个共管方系统发送的针对所述交易处理请求的审批同意消息时，向所述提供方系统发送再次确认请求；并且，接收到所述提供方系统返回的再次确认消息时，基于所述目标资源量调整接收方账户的资源量；将交易处理成功消息返回给所述提供方系统；或者，

向银行系统发送针对所述交易处理请求的审批拒绝消息，以使所述银行系统向提供方系统返回审核不通过的消息。

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

13.一种计算机可读存储介质，其特征在于，其存储有可由计算机设备执行的计算机程序，当所述程序在计算机设备上运行时，使得所述计算机设备执行权利要求1-8任一所述方法的步骤。

14.一种计算机程序产品，其特征在于，所述计算机程序产品包括存储在计算机可读存储介质上的计算机程序，所述计算机程序包括程序指令，当所述程序指令被计算机设备执行时，使所述计算机设备执行权利要求1-8任一项所述方法的步骤。