CN110717756A - 基于合约的支付数据处理装置及方法 - Google Patents

Abstract

本发明公开了一种基于合约的支付数据处理装置及方法。其中装置包括：进件系统，适于针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统；合约系统，适于分别管理多个业务协议，其中每个业务协议中存储对应业务的支付参数；响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数；支付系统，适于根据用户端的业务支付请求，向合约系统发送支付参数查询请求；根据合约系统返回的支付参数对业务进行支付逻辑处理。基于本发明提供的方案，实现了高内聚低耦合的软件架构方案，降低了平台的维护成本，提高了支付链路的可靠性，有效降低了电商平台的复杂性，提高了电商平台的扩展能力。

Description

基于合约的支付数据处理装置及方法

技术领域

本发明涉及互联网技术领域，具体涉及一种基于合约的支付数据处理装置及方法。

背景技术

传统的支付处理方案是：当商户端有多套支付参数时，商户端进件的时候必须选择其中一套支付参数，将所选择的支付参数作为商户端的属性存在数据库里。交易行为发生的时候，根据商户端获取对应的支付参数，完成支付。该方案存在如下两个方面的明显缺陷：1.如果商户有多个业务需要支付时，维护这些支付参数非常繁杂；2.多业务之间由于无法做到隔离，使得支付时可能会产生相互干扰。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的基于合约的支付数据处理装置及方法。

根据本发明的一个方面，提供了一种基于合约的支付数据处理装置，包括：进件系统、合约系统及支付系统；

进件系统，适于针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统；

合约系统，适于分别管理多个业务协议，其中每个业务协议中存储对应业务的支付参数；响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数；

支付系统，适于根据用户端的业务支付请求，向合约系统发送支付参数查询请求；根据合约系统返回的支付参数对业务进行支付逻辑处理。

可选地，进件系统进一步适于：若监测到商户端的业务支付需求发生变化或渠道状态变更为不可用状态，更新业务对应的支付参数，将更新的支付参数动态同步至合约系统。

可选地，合约系统还适于：管理与多个业务协议关联的框架协议，若接收到进件系统同步的支付参数，通过框架协议校验业务类型对应的业务协议是否存在；

若是，则将业务协议中存储的支付参数更新覆盖为本次同步的支付参数；

若否，则依据业务类型创建对应的业务协议，并将业务对应的支付参数存储至业务协议中。

可选地，支付参数查询请求包含：业务类型；

合约系统进一步适于：查询与业务类型相匹配的业务协议，得到业务对应的支付参数。

可选地，支付参数包含：渠道标识、商户端标识、费率信息。

根据本发明的另一方面，提供了一种基于合约的支付数据处理方法，方法基于上述的基于合约的支付数据处理装置而实现，方法包括：

针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统；

将多业务的支付参数存储至各业务对应的业务协议中；

根据用户端的业务支付请求，向合约系统发送支付参数查询请求；

由合约系统响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数；

根据合约系统返回的支付参数对业务进行支付逻辑处理。

可选地，方法还包括：若监测到商户端的业务支付需求发生变化或渠道状态变更为不可用状态，更新业务对应的支付参数，将更新的支付参数动态同步至合约系统。

可选地，将多业务的支付参数存储至各业务对应的业务协议中进一步包括：

通过与多个业务协议关联的框架协议校验业务类型对应的业务协议是否存在；

若是，则将业务协议中存储的支付参数更新覆盖为本次同步的支付参数；

若否，则依据业务类型创建对应的业务协议，并将业务对应的支付参数存储至业务协议中。

可选地，支付参数查询请求包含：业务类型；

由合约系统响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数进一步包括：

由合约系统查询与业务类型相匹配的业务协议，得到业务对应的支付参数，向支付系统返回对应业务的支付参数。

可选地，支付参数包含：渠道标识、商户端标识、费率信息。

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

存储器用于存放至少一可执行指令，可执行指令使处理器执行上述基于合约的支付数据处理方法对应的操作。

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

根据本发明提供的方案，进件系统，适于针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统；合约系统，适于分别管理多个业务协议，其中每个业务协议中存储对应业务的支付参数；响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数；支付系统，适于根据用户端的业务支付请求，向合约系统发送支付参数查询请求；根据合约系统返回的支付参数对业务进行支付逻辑处理。基于本发明提供的方案，引入了合约系统，明确了进件系统、合约系统、支付系统三者的职责，实现了高内聚低耦合的软件架构方案，降低了平台的维护成本，提高了支付链路的可靠性，有效降低了电商平台的复杂性，提高了电商平台的扩展能力，使得商户端仅关心业务即可，无需直接面对商户端属性，导致由于商户端不理解这些属性而对商户端属性本身以及支付链路的影响等问题；对于有多个业务的商户端而言，商户端的多个业务之间是完全隔离的，不会互相产生干扰。

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

附图说明

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

图1示出了根据本发明一个实施例的基于合约的支付数据处理装置的结构示意图；

图2示出了根据本发明一个实施例的基于合约的支付数据处理方法的流程示意图；

图3示出了根据本发明另一个实施例的基于合约的支付数据处理方法的流程示意图；

图4示出了根据本发明一个实施例的计算设备的结构示意图。

具体实施方式

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

图1示出了根据本发明一个实施例的基于合约的支付数据处理装置的结构示意图。如图1所示，该装置包括：进件系统101、合约系统102及支付系统103。

进件系统101，适于针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统。

在实际生活中，商户端的业务是多种多样的，以餐饮为例，商户端的业务可能包含：点餐业务、线下收单业务，当然这里仅是举例说明，不具有任何限定作用。

本实施例中的渠道指具备资质的第三方支付渠道，该渠道用于连接收单机构和具有支付能力的应用，例如，支付宝，比如，银联或者平安付等，所谓的收单机构指具备银行清算资质的服务商，比如，网商银行，其中，收单机构对外提供支付接口以让其它公司方便地使用支付宝的支付能力。这里的其它公司是商户端接入的电商平台，本实施例中的基于合约的支付数据处理装置是电商平台中的一部分。电商平台作为提供支付能力的服务商，以公司身份向收单机构申请渠道。在实际生活中存在由于政策或者其它原因导致渠道不可用从而使得渠道不稳定的情况出现，为了应对这种情况，电商平台会申请多个渠道以互为主备。

支付参数指具备支付能力的商户端发起交易时的一套参数，该套支付参数用于完成正常的交易行为，实现调拨账户的资金，其中，支付参数包含：渠道标识、商户端标识、费率信息，这里仅是举例说明，不具有任何限定作用，在实际支付数据处理时，可能还涉及其它的支付参数，此处不再一一列举。

具体地，商户端为了能够具有相应的支付能力，需要选择业务提交待审核资料至进件系统，进件系统受理后提交给收单机构审核，例如，身份证、营业执照等，收单机构负责进行审核，审核通过之后，向进件系统返回支付参数，并由进件系统通过异步方式将对应的支付参数返回给商户端，这样该商户端就具备了支付能力。

在一些场景下商户端希望做到业务隔离，即业务A使用支付参数A，业务B使用支付参数B，二者的资金流向最终的银行卡也不尽相同，因此，进件系统需要针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，使得后续用户端在支付时能够针对不同的业务，使用该业务对应的支付参数进行支付逻辑处理。其中，进件系统可以根据具体的业务场景及业务规则决策出每一业务对应的支付参数，例如，商户端要求业务A选择费率最低的渠道，从而决策出业务A对应的一套支付参数；商户端要求所有业务都使用同一套支付参数，可以依据该业务规则，为每个业务决策出对应的支付参数，只不过此时多个业务对应的支付参数相同。

在决策出每一业务对应的支付参数后，进件系统将多业务的支付参数同步给合约系统，由合约系统负责存储业务对应的支付参数，而不再是将支付参数作为商户端的一个属性存储至进件系统或配置到支付系统中，从而解决了多业务的支付参数作为一个大字符串存储时支付参数维护复杂问题，降低了支付参数维护成本。

合约系统102，适于分别管理多个业务协议，其中每个业务协议中存储对应业务的支付参数；响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数。

合约系统负责管理多个业务协议，每个业务协议对应一种业务，例如，多业务分别为业务A、业务B、业务C，那么合约系统分别管理有业务协议A、业务协议B、业务协议C。进件系统将多业务的支付参数同步至合约系统之后，合约系统将业务对应的支付参数存储至该业务对应的业务协议中，举例说明，业务A对应的支付参数A存储至业务协议A中，业务B对应的支付参数B存储至业务协议B中，业务C对应的支付参数C存储至业务协议C中。

在本实施例中，合约系统通过管理多个业务协议，实现了对于有多个业务的商户端而言，商户端的多个业务之间是完全隔离的，不会互相产生干扰。

在本实施例中，进件系统针对每个业务决策出业务对应的支付参数，因此，合约系统针对一个业务存储唯一的一套支付参数，从而合约系统在接收到支付系统的支付参数查询请求后，可以唯一确定业务对应的支付参数，并响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数。

支付系统103，适于根据用户端的业务支付请求，向合约系统发送支付参数查询请求；根据合约系统返回的支付参数对业务进行支付逻辑处理。

用户端在商户端下发起交易行为时，用户端向支付系统发送业务支付请求，该业务支付请求表明用户端针对相应的业务向商户端进行付款，支付系统在收到用户端发送的业务支付请求后，根据用户端的业务支付请求，向合约系统发送支付参数查询请求，请求查询业务对应的支付参数。合约系统在查询到对应业务的支付参数后，会将业务对应的支付参数返回给支付系统，支付系统接收合约系统返回的支付参数，然后，根据所返回的支付参数对业务进行处理，主要是完成支付逻辑处理，在处理完成后，用户端即完成了相应的业务的付款过程，用户便可以使用相应的业务。

在本实施例中引入了合约系统，明确了进件系统、合约系统、支付系统三者的职责，实现了高内聚低耦合的软件架构方案，降低了平台的维护成本，提高了支付链路的可靠性，有效降低了电商平台的复杂性，提高了电商平台的扩展能力。

在本发明一种可选实施方式中，可能存在商户端的支付需求发生变化或者渠道状态发生变更的情况，对于上述情况，该可选实施方式能够动态调整业务对应的支付参数，具体地，进件系统101若监测到商户端的业务支付需求发生变化或渠道状态变更为不可用状态，可以重新决策业务对应的支付参数，即，更新业务对应的支付参数，然后，将更新的支付参数动态同步至合约系统，以实现替换掉当前业务原有的支付参数。从而大大方便了电商平台的灵活性，同时有效应对了渠道不可用等极端情况，保证了电商平台的高可用，而且商户不需要理解商户端属性，避免了因商户端不理解商户端属性，而造成修改过程繁琐，耗费商户端大量时间的问题。

在本发明一种可选实施方式中，合约系统102还适于：管理与多个业务协议关联的框架协议，若接收到进件系统同步的支付参数，通过框架协议校验业务类型对应的业务协议是否存在；若是，则将业务协议中存储的支付参数更新覆盖为本次同步的支付参数；若否，则依据业务类型创建对应的业务协议，并将业务对应的支付参数存储至业务协议中。

在该可选实施方式中，合约系统还管理有与多个业务协议关联的框架协议，其中，框架协议与业务协议为一对多的关系，框架协议负责管控业务协议，例如，校验业务协议是否存在，但是，框架协议并不负责管控业务协议中的支付参数。

具体地，进件系统将业务对应的支付参数同步给合约系统后，合约系统会通过框架协议校验是否存在该业务所属业务类型对应的业务协议，若校验存在相应的业务协议，则利用本次同步的支付参数来更新覆盖业务协议中原先存储的支付参数，从而使业务协议存储最新的支付参数；若检验不存在相应的业务协议，则可以依据业务类型创建对应的业务协议，并将业务对应的支付参数存储至业务协议中。不论是更新业务协议中存储的支付参数，还是创建业务协议存储支付参数，都保证了合约系统中只存储有一个业务所需的一套支付参数。

例如，对于商户端的业务支付需求发生变化或渠道状态变更为不可用状态的情况，合约系统中已经存在了业务类型对应的业务协议，此时，合约系统通过框架协议校验出业务对应的业务协议已经存在，就可以直接利用进件系统重新决策出的业务对应的支付参数替换原有的支付参数，从而实现了商户端无感知的情况下的快速切换，提高了电商平台的支付能力稳定性，能够避免因渠道不可用导致支付链路不可用，而影响用户端及商户端的使用。

通过引入合约系统，将支付参数存储到合约系统中，而不是作为商户端的属性存储，从而能够在有新的渠道接入或者渠道修改时，大大降低商户端的理解成本及操作成本，避免了商户端直接面对商户端属性，导致由于商户端不理解这些属性而对商户端属性本身以及支付链路的影响等问题。

在本发明一种可选实施方式中，支付系统在接收到用户端发送的业务支付请求后，从该业务支付请求中提取出相应的业务类型，然后，向合约系统发送支付参数查询请求，该支付参数查询请求中包含：业务类型，这样，合约系统在接收到支付参数查询请求后，从中提取出业务类型，然后，合约系统102查询与业务类型相匹配的业务协议，得到业务对应的支付参数。

对于合约系统管理有与多个业务协议关联的框架协议的情况，可以通过框架协议查询确定与业务类型相匹配的业务协议，从业务协议中提取出该业务对应的支付参数。然后，由合约系统将查询到的业务对应的支付参数返回给支付系统。

本实施例以一个商户端为例进行介绍，对于多个商户端的支付数据处理同样适用，这里不再详细赘述。

根据本发明上述实施例提供的装置，进件系统，适于针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统；合约系统，适于分别管理多个业务协议，其中每个业务协议中存储对应业务的支付参数；响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数；支付系统，适于根据用户端的业务支付请求，向合约系统发送支付参数查询请求；根据合约系统返回的支付参数对业务进行支付逻辑处理。基于本发明提供的方案，引入了合约系统，明确了进件系统、合约系统、支付系统三者的职责，实现了高内聚低耦合的软件架构方案，降低了平台的维护成本，提高了支付链路的可靠性，有效降低了电商平台的复杂性，提高了电商平台的扩展能力，使得商户端仅关心业务即可，无需直接面对商户端属性，导致由于商户端不理解这些属性而对商户端属性本身以及支付链路的影响等问题；对于有多个业务的商户端而言，商户端的多个业务之间是完全隔离的，不会互相产生干扰。

图2示出了根据本发明一个实施例的基于合约的支付数据处理方法的流程示意图。该方法基于上述的基于合约的支付数据处理装置而实现，如图2所示，该方法包括以下步骤：

步骤S201，针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统。

在实际生活中，商户端的业务是多种多样的，以餐饮为例，商户端的业务可能包含：点餐业务、线下收单业务，当然这里仅是举例说明，不具有任何限定作用。

本实施例中的渠道指具备资质的第三方支付渠道，该渠道用于连接收单机构和微信或支付宝，比如，银联或者平安付等，所谓的收单机构指具备银行清算资质的服务商，比如，网商银行，其中，收单机构对外提供支付接口以让其它公司方便地使用微信或者支付宝的支付能力。这里的其它公司是商户端接入的电商平台，本实施例中的基于合约的支付数据处理装置是电商平台中的一部分。电商平台作为提供支付能力的服务商，以公司身份向收单机构申请渠道。在实际生活中存在由于政策或者其它原因导致渠道不可用使得渠道不稳定，为了应对这种情况，电商平台会申请多个渠道以互为主备。

支付参数指具备支付能力的商户端发起交易时的一套参数，该套支付参数用于完成正常的交易行为，实现调拨账户的资金，其中，支付参数包含：渠道标识、商户端标识、费率信息，这里仅是举例说明，不具有任何限定作用，在实际支付数据处理时，可能还涉及其它的支付参数，此处不再一一列举。

具体地，商户端为了能够具有相应的支付能力，需要选择业务提交待审核资料至进件系统，进件系统受理后提交给收单机构审核，例如，身份证、营业执照等，收单机构负责进行审核，审核通过之后，向进件系统返回支付参数，并由进件系统通过异步方式将对应的支付参数返回给商户端，这样该商户端就具备了支付能力。

在一些场景下商户端希望做到业务隔离，即业务A使用支付参数A，业务B使用支付参数B，二者的资金流向最终的银行卡也不尽相同，因此，进件系统需要针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，使得后续用户端在支付时能够针对不同的业务，使用该业务对应的支付参数进行支付逻辑处理。其中，进件系统可以根据具体的业务场景及业务规则决策出每一业务对应的支付参数，例如，商户端要求业务A选择费率最低的渠道，从而决策出业务A对应的一套支付参数。商户端要求所有业务都使用同一套支付参数，可以依据该业务规则，为每个业务决策出对应的支付参数，只不过此时多个业务对应的支付参数相同。

在决策出每一业务对应的支付参数后，进件系统将多业务的支付参数同步给合约系统，由合约系统负责存储业务对应的支付参数，而不再是将支付参数作为商户端的一个属性存储至进件系统或配置到支付系统中，从而解决了多业务的支付参数作为一个大字符串存储时支付参数维护复杂问题，降低了支付参数维护成本。

步骤S202，将多业务的支付参数存储至各业务对应的业务协议中。

合约系统负责管理多个业务协议，每个业务协议对应一种业务，例如，多业务分别为业务A、业务B、业务C，那么合约系统分别管理有业务协议A、业务协议B、业务协议C。进件系统将多业务的支付参数同步至合约系统之后，合约系统将业务对应的支付参数存储至该业务对应的业务协议中，举例说明，业务A对应的支付参数A存储至业务协议A中，业务B对应的支付参数B存储至业务协议B中，业务C对应的支付参数C存储至业务协议C中。

在本实施例中，合约系统通过管理多个业务协议，实现了对于有多个业务的商户端而言，商户端的多个业务之间是完全隔离的，不会互相产生干扰。

步骤S203，根据用户端的业务支付请求，向合约系统发送支付参数查询请求。

用户端在商户端下发起交易行为时，用户端向支付系统发送业务支付请求，该业务支付请求表明用户端针对相应的业务向商户端进行付款，支付系统在收到用户端发送的业务支付请求后，根据用户端的业务支付请求，向合约系统发送支付参数查询请求，请求查询业务对应的支付参数。

步骤S204，由合约系统响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数。

本实施例中，进件系统针对每个业务决策出业务对应的支付参数，因此，合约系统针对一个业务存储唯一的一套支付参数，从而合约系统在接收到支付系统的支付参数查询请求后，可以唯一确定业务对应的支付参数，并响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数。

步骤S205，根据合约系统返回的支付参数对业务进行支付逻辑处理。

合约系统在查询到对应业务的支付参数后，会将业务对应的支付参数返回给支付系统，支付系统接收合约系统返回的支付参数，然后，根据所返回的支付参数对业务进行处理，主要是完成支付逻辑处理，在处理完成后，用户端即完成了相应的业务的付款过程，用户便可以使用相应的业务。

根据本发明上述实施例提供的方法，针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统；将多业务的支付参数存储至各业务对应的业务协议中；根据用户端的业务支付请求，向合约系统发送支付参数查询请求；由合约系统响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数；根据所述合约系统返回的支付参数对业务进行支付逻辑处理。基于本发明提供的方案，通过将支付参数存储至合约系统的业务协议中，实现了商户端的多个业务之间是完全隔离的，不会互相产生干扰；明确进件系统、合约系统、支付系统三者的职责，实现了高内聚低耦合的软件架构方案，降低了平台的维护成本，提高了支付链路的可靠性，有效降低了电商平台的复杂性，提高了电商平台的扩展能力，使得商户端仅关心业务即可，无需直接面对商户端属性，导致由于商户端不理解这些属性而对商户端属性本身以及支付链路的影响等问题；对于有多个业务的商户端而言。

图3示出了根据本发明另一个实施例的基于合约的支付数据处理方法的流程示意图。该方法基于上述的基于合约的支付数据处理装置而实现，如图3所示，该方法包括以下步骤：

步骤S301，针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统。

图3所示实施例中的步骤S301与图2所示实施例中的步骤S201类似，这里不再赘述。

步骤S302，通过与多个业务协议关联的框架协议校验业务类型对应的业务协议是否存在，若是，则执行步骤S303；若否，则执行步骤S304。

合约系统管理有与多个业务协议关联的框架协议，其中，框架协议与业务协议为一对多的关系，框架协议负责管控业务协议，例如，校验业务协议是否存在，但是，框架协议并不负责管控业务协议中的支付参数。

具体地，进件系统将业务对应的支付参数同步给合约系统后，合约系统会通过框架协议校验是否存在该业务所属业务类型对应的业务协议，这里校验业务协议是否存在是为了确定后续是执行支付参数更新操作，还是先执行业务协议创建操作，再执行支付参数存储操作。

步骤S303，将业务协议中存储的支付参数更新覆盖为本次同步的支付参数。

若校验存在相应的业务协议，则利用本次同步的支付参数来更新覆盖业务协议中原先存储的支付参数，从而使业务协议存储最新的支付参数，例如，对于商户端的业务支付需求发生变化或渠道状态变更为不可用状态的情况，合约系统中已经存在了业务类型对应的业务协议，此时，合约系统通过框架协议校验出业务对应的业务协议已经存在，就可以直接利用进件系统重新决策出的业务对应的支付参数替换原有的支付参数，从而实现了商户端无感知的情况下的快速切换，提高了电商平台的支付能力稳定性，能够避免因渠道不可用导致支付链路不可用，而影响用户端及商户端的使用。

步骤S304，依据业务类型创建对应的业务协议，并将业务对应的支付参数存储至业务协议中。

若检验不存在相应的业务协议，则可以依据业务类型创建对应的业务协议，并将业务对应的支付参数存储至业务协议中。不论是更新业务协议中存储的支付参数，还是创建业务协议存储支付参数，都保证了合约系统中只存储有一个业务所需的一套支付参数。

通过引入合约系统，将支付参数存储到合约系统中，而不是作为商户端的属性存储，从而能够在有新的渠道接入或者渠道修改时，大大降低商户端的理解成本及操作成本，避免了商户端直接面对商户端属性，导致由于商户端不理解这些属性而对商户端属性本身以及支付链路的影响等问题。

步骤S305，根据用户端的业务支付请求，向合约系统发送支付参数查询请求。

图3所示实施例中的步骤S305与图2所示实施例中的步骤S203类似，这里不再赘述。

步骤S306，由合约系统查询与业务类型相匹配的业务协议，得到业务对应的支付参数，向支付系统返回对应业务的支付参数。

在接收到用户端发送的业务支付请求后，从该业务支付请求中提取出相应的业务类型，然后，向合约系统发送支付参数查询请求，该支付参数查询请求中包含：业务类型，这样，合约系统在接收到支付参数查询请求后，从中提取出业务类型，然后，由合约系统查询与业务类型相匹配的业务协议，得到业务对应的支付参数。

对于合约系统管理有与多个业务协议关联的框架协议的情况，可以通过框架协议查询确定与业务类型相匹配的业务协议，从业务协议中提取出该业务对应的支付参数。然后，由合约系统将查询到的业务对应的支付参数返回给支付系统。

步骤S307，根据合约系统返回的支付参数对业务进行支付逻辑处理。

图3所示实施例中的步骤S307与图2所示实施例中的步骤S205类似，这里不再赘述。

在本发明一种可选实施方式中，可能存在商户端的支付需求发生变化或者渠道状态发生变更的情况，对于上述情况，该可选实施方式能够动态调整业务对应的支付参数，具体地，该方法还包括：若监测到商户端的业务支付需求发生变化或渠道状态变更为不可用状态，可以重新决策业务对应的支付参数，即，更新业务对应的支付参数，然后，将更新的支付参数动态同步至合约系统，以实现替换掉当前业务原有的支付参数。从而大大方便了电商平台的灵活性，同时有效应对了渠道不可用等极端情况，保证了电商平台的高可用，而且商户不需要理解商户端属性，避免了因商户端不理解商户端属性，而造成修改过程繁琐，耗费商户端大量时间的问题。

根据本发明上述实施例提供的方法，引入了合约系统，明确了进件系统、合约系统、支付系统三者的职责，实现了高内聚低耦合的软件架构方案，降低了平台的维护成本，提高了支付链路的可靠性，有效降低了电商平台的复杂性，提高了电商平台的扩展能力，使得商户端仅关心业务即可，无需直接面对商户端属性，导致由于商户端不理解这些属性而对商户端属性本身以及支付链路的影响等问题；对于有多个业务的商户端而言，商户端的多个业务之间是完全隔离的，不会互相产生干扰；若监测到商户端的业务支付需求发生变化或渠道状态变更为不可用状态，可以动态调整支付参数，从而大大方便了电商平台的灵活性，同时有效应对了渠道不可用等极端情况，保证了电商平台的高可用，而且商户不需要理解商户端属性，避免了因商户端不理解商户端属性，而造成修改过程繁琐，耗费商户端大量时间的问题。

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

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

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

其中：

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

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

处理器402，用于执行程序410，具体可以执行上述基于合约的支付数据处理方法实施例中的相关步骤。

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

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

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

程序410具体可以用于使得处理器402执行上述任意方法实施例中的基于合约的支付数据处理方法。程序410中各步骤的具体实现可以参见上述基于合约的支付数据处理实施例中的相应步骤和单元中对应的描述，在此不赘述。所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述方法实施例中的对应过程描述，在此不再赘述。

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

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

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

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

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

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

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

Claims (10)

1.一种基于合约的支付数据处理装置，包括：进件系统、合约系统及支付系统；

进件系统，适于针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统；

合约系统，适于分别管理多个业务协议，其中每个业务协议中存储对应业务的支付参数；响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数；

支付系统，适于根据用户端的业务支付请求，向所述合约系统发送支付参数查询请求；根据所述合约系统返回的支付参数对业务进行支付逻辑处理。

2.根据权利要求1所述的装置，其中，所述进件系统进一步适于：若监测到商户端的业务支付需求发生变化或渠道状态变更为不可用状态，更新业务对应的支付参数，将更新的支付参数动态同步至合约系统。

3.根据权利要求1或2所述的装置，其中，所述合约系统还适于：管理与多个业务协议关联的框架协议，若接收到所述进件系统同步的支付参数，通过框架协议校验业务类型对应的业务协议是否存在；

若是，则将业务协议中存储的支付参数更新覆盖为本次同步的支付参数；

若否，则依据业务类型创建对应的业务协议，并将业务对应的支付参数存储至所述业务协议中。

4.根据权利要求1-3中任一项所述的装置，其中，所述支付参数查询请求包含：业务类型；

所述合约系统进一步适于：查询与业务类型相匹配的业务协议，得到业务对应的支付参数。

5.根据权利要求1-4中任一项所述的装置，其中，所述支付参数包含：渠道标识、商户端标识、费率信息。

6.一种基于合约的支付数据处理方法，所述方法基于权利要求1-5中任一项所述的基于合约的支付数据处理装置而实现，所述方法包括：

针对商户端的多业务多渠道的业务支付需求，决策出每一业务的支付参数，将多业务的支付参数同步至合约系统；

将多业务的支付参数存储至各业务对应的业务协议中；

根据用户端的业务支付请求，向合约系统发送支付参数查询请求；

由合约系统响应支付系统的支付参数查询请求，向支付系统返回对应业务的支付参数；

根据所述合约系统返回的支付参数对业务进行支付逻辑处理。

7.根据权利要求6所述的方法，其中，所述方法还包括：若监测到商户端的业务支付需求发生变化或渠道状态变更为不可用状态，更新业务对应的支付参数，将更新的支付参数动态同步至合约系统。

8.根据权利要求6或7所述的方法，其中，将多业务的支付参数存储至各业务对应的业务协议中进一步包括：

通过与多个业务协议关联的框架协议校验业务类型对应的业务协议是否存在；

若是，则将业务协议中存储的支付参数更新覆盖为本次同步的支付参数；

若否，则依据业务类型创建对应的业务协议，并将业务对应的支付参数存储至所述业务协议中。

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

所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行如权利要求6-8中任一项所述的基于合约的支付数据处理方法对应的操作。

10.一种计算机存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行如权利要求6-8中任一项所述的基于合约的支付数据处理方法对应的操作。

Images