业务处理方法及装置、系统、电子设备、存储介质
技术领域
本说明书一个或多个实施例涉及区块链技术领域,尤其涉及一种业务处理方法及装置、系统、电子设备、存储介质。
背景技术
区块链技术,也被称之为分布式账本技术,是一种由若干台计算设备共同参与“记账”,共同维护一份完整的分布式数据库的新兴技术。由于区块链技术具有去中心化、公开透明、每台计算设备可以参与数据库记录、并且各计算设备之间可以快速的进行数据同步的特性,使得区块链技术已在众多的领域中广泛的进行应用。
发明内容
有鉴于此,本说明书一个或多个实施例提供一种业务处理方法及装置、系统、电子设备、存储介质。
为实现上述目的,本说明书一个或多个实施例提供技术方案如下:
根据本说明书一个或多个实施例的第一方面,提出了一种业务处理系统,包括:业务参与方客户端、业务请求方客户端和存储设备;
所述业务参与方客户端根据待处理业务的业务补充信息和业务参与方的身份标识生成业务图形码,所述业务参与方客户端与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至所述存储设备进行存储;
所述业务请求方客户端解析所述业务图形码得到所述身份标识,基于所述身份标识向所述存储设备发起针对所述业务参与方的查询请求,以使所述存储设备根据所述映射关系查找与所述查询请求中身份标识对应的候选业务基础信息;获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理。
根据本说明书一个或多个实施例的第二方面,提出了一种业务处理方法,应用于业务参与方客户端,所述方法包括:
根据待处理业务的业务补充信息和业务参与方的身份标识生成业务图形码以由业务请求方客户端解析,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储;
其中,当业务请求方客户端解析所述业务图形码得到所述身份标识时,所述身份标识由所述业务请求方客户端通过针对所述业务参与方客户端的查询请求提交至所述存储设备,以由所述存储设备根据所述映射关系查找与所述身份标识对应的候选业务基础信息,所述业务请求方客户端在基于解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理时所采用的业务基础信息,为所述候选业务基础信息中与所述业务请求方客户端相匹配的业务基础信息。
根据本说明书一个或多个实施例的第三方面,提出了一种业务处理方法,应用于业务请求方客户端,所述方法包括:
解析业务参与方客户端生成的业务图形码以得到所述业务图形码中包含的待处理业务的业务补充信息和业务参与方的身份标识,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储;
基于所述身份标识向所述存储设备发起针对所述业务参与方的查询请求,以使所述存储设备根据所述映射关系查找与所述查询请求中身份标识对应的候选业务基础信息;
获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理。
根据本说明书一个或多个实施例的第四方面,提出了一种业务处理方法,应用于区块链节点,所述方法包括:
接收业务请求方客户端发起的针对业务参与方的查询请求,所述查询请求中包含所述业务参与方的身份标识,所述身份标识由所述业务请求方客户端解析业务参与方客户端生成的业务图形码得到,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至所述存储设备进行存储;
根据所述映射关系查找与所述查询请求中包含的身份标识对应的候选业务基础信息,以由所述业务请求方客户端获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的待处理业务的业务补充信息对所述待处理业务进行处理。
根据本说明书一个或多个实施例的第五方面,提出了一种业务处理装置,应用于业务参与方客户端,所述装置包括:
生成单元,根据待处理业务的业务补充信息和业务参与方的身份标识生成业务图形码以由业务请求方客户端解析,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储;
其中,当业务请求方客户端解析所述业务图形码得到所述身份标识时,所述身份标识由所述业务请求方客户端通过针对所述业务参与方客户端的查询请求提交至所述存储设备,以由所述存储设备根据所述映射关系查找与所述身份标识对应的候选业务基础信息,所述业务请求方客户端在基于解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理时所采用的业务基础信息,为所述候选业务基础信息中与所述业务请求方客户端相匹配的业务基础信息。
根据本说明书一个或多个实施例的第六方面,提出了一种业务处理装置,应用于业务请求方客户端,所述装置包括:
解析单元,解析业务参与方客户端生成的业务图形码以得到所述业务图形码中包含的待处理业务的业务补充信息和业务参与方的身份标识,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储;
查询单元,基于所述身份标识向所述存储设备发起针对所述业务参与方的查询请求,以使所述存储设备根据所述映射关系查找与所述查询请求中身份标识对应的候选业务基础信息;
业务处理单元,获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理。
根据本说明书一个或多个实施例的第七方面,提出了一种业务处理装置,应用于区块链节点,所述装置包括:
第一接收单元,接收业务请求方客户端发起的针对业务参与方的查询请求,所述查询请求中包含所述业务参与方的身份标识,所述身份标识由所述业务请求方客户端解析业务参与方客户端生成的业务图形码得到,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至所述存储设备进行存储;
查询单元,根据所述映射关系查找与所述查询请求中包含的身份标识对应的候选业务基础信息,以由所述业务请求方客户端获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的待处理业务的业务补充信息对所述待处理业务进行处理。
根据本说明书一个或多个实施例的第八方面,提出了一种电子设备,包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器通过运行所述可执行指令以实现如上述第二方面中所述的业务处理方法。
根据本说明书一个或多个实施例的第九方面,提出了根据本说明书一个或多个实施例的第八方面,提出了一种电子设备,包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器通过运行所述可执行指令以实现如上述第三方面中所述的业务处理方法。
根据本说明书一个或多个实施例的第十方面,提出了一种电子设备,包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器通过运行所述可执行指令以实现如上述第四方面中所述的业务处理方法。
根据本说明书一个或多个实施例的第十一方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如上述第二方面中任一所述方法的步骤。
根据本说明书一个或多个实施例的第十二方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如上述第三方面中任一所述方法的步骤。
根据本说明书一个或多个实施例的第十三方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如上述第四方面任一所述方法的步骤。
附图说明
图1A是一示例性实施例提供的一种创建智能合约的示意图。
图1B是一示例性实施例提供的一种调用智能合约的示意图。
图2是一示例性实施例提供的一种业务处理系统的架构示意图。
图3是一示例性实施例提供的一种业务处理方法的流程图。
图4是一示例性实施例提供的另一种业务处理方法的流程图。
图5是一示例性实施例提供的另一种业务处理方法的流程图。
图6A是一示例性实施例提供的一种扫码支付的架构示意图。
图6B是一示例性实施例提供的另一种扫码支付的架构示意图。
图7是一示例性实施例提供的一种基于订单码进行支付的示意图。
图8是一示例性实施例提供的一种设备的结构示意图。
图9是一示例性实施例提供的一种业务处理装置的框图。
图10是一示例性实施例提供的另一种设备的结构示意图。
图11是一示例性实施例提供的另一种业务处理装置的框图。
图12是一示例性实施例提供的另一种设备的结构示意图。
图13是一示例性实施例提供的另一种业务处理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
区块链一般被划分为三种类型:公有链(Public Blockchain),私有链(PrivateBlockchain)和联盟链(Consortium Blockchain)。此外,还有多种类型的结合,比如私有链+联盟链、联盟链+公有链等不同组合形式。其中去中心化程度最高的是公有链。公有链以比特币、以太坊为代表,加入公有链的参与者可以读取链上的数据记录、参与交易以及竞争新区块的记账权等。而且,各参与者(即节点)可自由加入以及退出网络,并进行相关操作。私有链则相反,该网络的写入权限由某个组织或者机构控制,数据读取权限受组织规定。简单来说,私有链可以为一个弱中心化系统,参与节点具有严格限制且少。这种类型的区块链更适合于特定机构内部使用。联盟链则是介于公有链以及私有链之间的区块链,可实现“部分去中心化”。联盟链中各个节点通常有与之相对应的实体机构或者组织;参与者通过授权加入网络并组成利益相关联盟,共同维护区块链运行。
不论是公有链、私有链还是联盟链,都可能提供智能合约的功能。区块链上的智能合约是在区块链系统上可以被交易触发执行的合约。智能合约可以通过代码的形式定义。
以以太坊为例,支持用户在以太坊网络中创建并调用一些复杂的逻辑,这是以太坊区别于比特币区块链技术的最大挑战。以太坊作为一个可编程区块链的核心是以太坊虚拟机(EVM),每个以太坊节点都可以运行EVM。EVM是一个图灵完备的虚拟机,这意味着可以通过它实现各种复杂的逻辑。用户在以太坊中发布和调用智能合约就是在EVM上运行的。实际上,虚拟机直接运行的是虚拟机代码(虚拟机字节码,下简称“字节码”)。部署在区块链上的智能合约可以是字节码的形式。
例如图1A所示,Bob将一个包含创建智能合约信息的交易发送到以太坊网络后,节点1的EVM可以执行这个交易并生成对应的合约实例。图中1中的“0x6f8ae93…”代表了这个合约的地址,交易的data字段保存的可以是字节码,交易的to字段为空。节点间通过共识机制达成一致后,这个合约成功创建,并且可以在后续过程中被调用。合约创建后,区块链上出现一个与该智能合约对应的合约账户,并拥有一个特定的地址,合约代码将保存在该合约账户中。智能合约的行为由合约代码控制。换句话说,智能合约使得区块链上产生包含合约代码和账户存储(Storage)的虚拟账户。
如图1B所示,仍以以太坊为例,Bob将一个用于调用智能合约的交易发送到以太坊网络后,某一节点的EVM可以执行这个交易并生成对应的合约实例。图1B中中交易的from字段是交易发起方(即Bob)的账户的地址,to字段中的“0x6f8ae93…”代表了被调用的智能合约的地址,value字段在以太坊中是以太币的值,交易的data字段保存的调用智能合约的方法和参数。智能合约以规定的方式在区块链网络中每个节点独立的执行,所有执行记录和数据都保存在区块链上,所以当交易完成后,区块链上就保存了无法篡改、不会丢失的交易凭证。
区块链网络中的节点在执行Bob发起的交易后,会生成相应的收据(receipt)数据,以用于记录该交易相关的收据信息。这样,可以通过查询交易的收据来获得该交易执行结果的相关信息。以以太坊为例,节点执行交易所得的收据数据可以包括如下内容:
Result字段,表示交易的执行结果;
Gas used字段,表示交易消耗的gas值;
Logs字段,表示交易产生的日志,日志可以进一步包括From字段、To字段、Topic字段和Log data字段等,其中From字段表示调用的发起方的账户地址、To字段表示被调用对象(如智能合约)的账户地址、Topic字段表示日志的主题、Log data字段表示日志数据;
Output字段,表示交易的输出。
需要说明的是,接入区块链的用户在区块链上发起的请求的类型,具体可以是指传统的区块链中所采用的交易(transaction)。当然,接入区块链的用户在区块链上发起的请求的类型,具体也可以是交易以外的,其它形式的具有标准的数据结构的指令、消息等,本说明书一个或多个实施例并不进行特别限定。在以下的各实施例中,将以接入区块链的用户在区块链上发起的请求为交易为例进行说明。
在业务处理过程中,业务响应服务端可与业务参与方建立关联关系以向业务参与方提供相应的业务支持,并在建立关联关系后由业务响应服务端向业务参与方配置相应的业务基础信息以供在处理业务时使用。其中,当出现待处理业务时,由业务参与方提供针对该待处理业务的业务补充信息(与待处理业务相对应),再由业务请求方获取业务补充信息和业务基础信息,并基于获取到的信息(业务补充信息和业务基础信息)与业务响应服务端进行交互来完成该待处理业务的处理过程。在相关技术中,当业务请求方和业务参与方之间存在待处理业务时,业务参与方可通过业务参与方客户端将该待处理业务的业务补充信息和自身的业务基础信息以业务图形码的形式输出。比如,在通过业务参与方客户端生成业务图形码后,业务参与方可通过业务参与方客户端向业务请求方展示生成的业务图形码。那么,业务请求方可通过业务请求方客户端解析该图形码获得业务基础信息和业务补充信息,进而实施该待处理业务的业务处理过程。
在实际应用中,针对同一种业务,可能存在多个业务响应服务端可向业务参与方提供业务支持,即业务参与方可与多个业务响应服务端建立关联关系,而各个相关联的业务响应服务端针对该业务参与方客户端配置有相应的业务基础信息。同时,各个业务响应服务端分别有各自对应的业务请求方客户端,业务请求方客户端可通过与自身相匹配的业务响应服务端配置的业务基础信息来完成业务处理。在该情况下,可针对各个业务响应服务端配置的每一业务基础信息,以及业务参与方提供的业务补充信息分别生成相应的业务图形码(即这些业务图形码中的业务补充信息相同,但业务基础信息不同)。换言之,每个业务图形码与业务响应服务端一一对应。那么,业务请求方在需要发起与该业务参与方相关的业务处理时,可根据实际需求选取业务图形码,并采用与选取的业务图形码对应的业务请求方客户端进行扫描以完成业务处理。
然而,在上述场景下,当业务参与方与多个业务响应服务端建立关联关系时,针对每个业务响应服务端配置的业务基础信息都需要生成一个相应的业务图形码,导致成本较高,效率低下。
以商户订单码的应用场景为例,当用户(业务请求方)从商户(业务参与方)中选取所需购买的商品后,由商户通过商户客户端(业务参与方客户端)针对用户选取的商品生成待支付订单(待处理业务)的订单码(业务图形码;比如,为订单二维码,或者为订单条形码),该订单码中包含商户在相应支付平台(业务响应服务端)上的收单信息(业务基础信息)和待支付订单的订单信息(业务补充信息)。用户使用安装有移动支付App的支付客户端(比如手机,即业务请求方客户端)扫描商户展示的订单码,移动支付App通过解析订单码获取该商户的收单信息和订单信息,并展示在App界面上由用户进行确认,用户在确认商户的收单信息和订单信息无误后即可提交支付申请,以由移动支付App与支付平台对接来完成后续的支付流程。
同一家商户可能与多个不同的支付平台合作(比如,与支付宝、微信等支付平台合作),每个支付平台都会为该商户分配相应的收单信息(比如,向该商户分配的账户、标识号、支付平台名称、支付平台的访问地址等)。那么,当商户支持多个支付平台时,商户需要根据各个支付平台分配的收单信息以及自身生成的订单信息生成相应的订单码以供商户向用户展示。比如,商户可通过商户客户端向用户展示订单码以供用户扫码付款。由于移动支付App通常与支付平台相关联(即每个支付平台均开发有相应的移动支付App),用户需选择自身安装的移动支付App支持的订单码进行扫描来完成支付。
由此可见,当商户与多个支付平台对接时,针对每个支付平台配置的收单信息都需要生成一个相应的订单码以由商户向用户展示,导致支付过程中的成本较高,用户操作较为复杂,效率低下,不利于提升用户体验。
本说明书旨在提供一种基于图形码的业务处理方案,可以在上述同一业务参与方客户端与多个业务响应服务端建立关联关系的情况下,将对应于各个业务相应服务端的业务图形码合并至一个支持互通性的业务图形码中,使得各个业务请求方均可以通过扫描该支持互通性的业务图形码来实施与该业务参与方客户端相关的业务处理,从而降低成本,简化用户操作,提高业务处理效率。
图2是一示例性实施例提供的一种业务处理系统的架构示意图。如图2所示,该系统可以包括服务器22、网络22、若干电子设备,比如手机23、手机24、PC25和PC26。
服务器22可以为包含一独立主机的物理服务器,或者服务器22可以为主机集群承载的虚拟服务器。在运行过程中,服务器22作为存储设备,用于存证各个业务参与方的业务基础信息以供查询。在一实施例中,服务器22可以是针对业务基础信息的容器平台服务端,从而动态维护各个业务参与方客户端的业务基础信息。在另一实施例中,服务器22可以是区块链节点,从而将各个业务参与方客户端的业务基础信息发布至区块链进行存证。
手机23-24和PC25-26只是业务参与方或业务请求方可以使用的两种类型的电子设备。实际上,显然还可以使用诸如下述类型的电子设备:平板设备、笔记本电脑、掌上电脑(PDAs,Personal Digital Assistants)、可穿戴设备(如智能眼镜、智能手表等)等,本说明书一个或多个实施例并不对此进行限制。在运行过程中,该电子设备可作为业务参与方使用的业务参与方客户端,或业务请求方使用的业务请求方客户端。其中,业务响应服务端与业务参与方建立关联关系,并向业务参与方配置业务基础信息,以由业务请求方客户端(在与业务参与方之间存在待处理业务时)获取配置的业务基础信息并基于该业务基础信息和业务参与方客户端提供的业务补充信息完成业务处理。
而对于各个电子设备与服务器22之间进行交互的网络22,可以包括多种类型的有线或无线网络。在一实施例中,该网络22可以包括公共交换电话网络(Public SwitchedTelephone Network,PSTN)和因特网。同时,手机23-24和PC25-26等电子设备之间也可以通过该网络22进行通讯交互。
由上述架构可见,本说明书提供的业务处理系统包括:业务参与方客户端、业务请求方客户端和存储设备。
其中,所述业务参与方客户端根据待处理业务的业务补充信息和业务参与方的身份标识生成业务图形码,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储;
所述业务请求方客户端解析所述业务图形码得到所述身份标识,基于所述身份标识向存储设备发起针对所述业务参与方客户端的查询请求,以使所述存储设备根据所述映射关系查找与所述查询请求中身份标识对应的候选业务基础信息;获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理。
下面分别对业务处理系统中各个角色执行的操作进行说明。
请参见图3,图3是一示例性实施例提供的一种基于业务处理方法的流程图。如图3所示,该方法应用于业务参与方客户端,可以包括以下步骤:
步骤302,根据待处理业务的业务补充信息和业务参与方的身份标识生成业务图形码以由业务请求方客户端解析,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储。
在本实施例中,当业务请求方客户端解析所述业务图形码得到所述身份标识时,所述身份标识由所述业务请求方客户端通过针对所述业务参与方客户端的查询请求提交至存储设备,以由存储设备根据所述映射关系查找与所述身份标识对应的候选业务基础信息,所述业务请求方客户端在基于解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理时所采用的业务基础信息,为所述候选业务基础信息中与所述业务请求方客户端相匹配的业务基础信息。其中,上述业务处理的具体过程将在下文进行详细描述。
在本实施例中,以商户订单码的应用场景为例,所述业务参与方包括商户(即所述业务参与方客户端包括商户客户端),所述业务请求方包括支付方(所述业务请求方客户端包括支付客户端),所述待处理业务包括待支付订单,所述业务补充信息包括所述待支付订单的订单信息,与所述商户客户端相关联的业务响应服务端包括支付平台服务端,各个支付平台服务端针对所述商户配置的业务基础信息包括收单信息。比如,订单信息可以包括待支付订单的交易金额、交易时间、交易币种、交易明细等。
在本实施例中,存储设备为针对业务基础信息的容器平台服务端,从而动态维护各个业务参与方的业务基础信息。或者,存储设备为区块链节点,从而将各个业务参与方的业务基础信息发布至区块链进行存证;换言之,业务参与的业务基础信息和身份标识的映射关系被发布至区块链进行存证。在该情况下,存储设备存储的映射关系,可理解为区块链存证的映射关系。例如,可由业务参与方客户端或者与该业务参与方客户端相关联的业务响应服务端,作为与区块链节点对接的区块链客户端,将上述映射关系打包至一笔交易中,从而向区块链节点提交该交易,以由区块链节点存证上述映射关系。
请参见图4,图4是一示例性实施例提供的另一种基于业务处理方法的流程图。如图4所示,该方法应用于业务请求方客户端,可以包括以下步骤:
步骤402,解析业务参与方客户端生成的业务图形码以得到所述业务图形码中包含的待处理业务的业务补充信息和业务参与方的身份标识,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储。
在本实施例中,业务响应服务端向业务参与方提供某一类业务的支持,在业务参与方与业务响应服务端建立关联关系后,由业务响应服务端向业务参与方配置业务基础信息,该业务基础信息为实施该业务时所需使用的一部分信息。并且业务基础信息通常固定不变。那么,当业务请求方与业务参与方之间存在实施该类业务的需求时,该类业务的业务补充信息通常随业务的实际情况动态变化,需要由业务参与方实时提供。业务请求方可通过与该业务响应服务端相匹配的业务请求方客户端,基于该业务响应服务端配置的业务基础信息,以及业务参与方提供的业务补充信息实施业务处理。
例如,在上述商户订单码的应用场景中,业务请求方包括支付方(即业务请求方客户端包括支付客户端),业务图形码包括订单码,业务参与方客户端包括商户客户端,与商户客户端相关联的业务响应服务端包括支付平台服务端,各个支付平台服务端针对商户客户端配置有相应的收单信息(即业务基础信息;比如,商户客户端的账户信息)。
商户通过向支付平台注册以与支付平台建立关联关系。支付平台可向商户分配相应的账户、标识号等收单信息作为支付业务的业务基础信息。那么,用户从商户购买商品进而达成一笔订单时,由商户提供订单信息,用户可通过移动支付App(安装于用户的电子设备中),基于上述收单信息和订单信息与支付平台进行交互,从而完成向商户在支付平台上注册的账户中支付费用的业务。
在本实施例中,可通过存储设备来记录各个业务参与方的业务基础信息。其中,业务参与方可通过业务参与方客户端向存储设备进行注册以获得唯一的身份标识。那么,存储设备可存储业务参与方的身份标识与该业务参与方的业务基础信息之间的映射关系。
当存储设备为容器平台服务端时,业务参与方可使用业务参与方客户端向容器平台服务端进行注册以获得在容器平台中唯一的身份标识。那么,容器平台服务端可存储业务参与方的身份标识与该业务参与方的业务基础信息之间的映射关系。
当存储设备为区块链节点时,业务参与方可使用业务参与方客户端向区块链进行注册以获得唯一的身份标识。那么,区块链可用于存证业务参与方的身份标识与该业务参与方的业务基础信息之间的映射关系。那么,业务响应服务端在向业务参与方配置业务基础信息后,可打包一笔包含业务基础信息和该业务参与方的身份标识的交易,并向区块链节点发起该交易,以使得区块链节点将交易中包含的身份标识和业务基础信息的映射关系(通过共识后)存证至区块链上。
例如,在比特币的区块链模型中,业务参与方可使用业务参与方客户端向区块链进行注册以获得钱包地址作为自身的身份标识。那么,在存证与钱包地址对应的业务基础信息时,可将业务基础信息打包至区块中,并将该业务基础信息与钱包地址建立索引关系,以供后续区块链节点根据钱包地址查询该业务基础信息。
又如,在以太坊的区块链模型中,业务参与方可使用业务参与方客户端向区块链进行注册以获得账户地址作为自身的身份标识。那么,在存证与账户地址对应的业务基础信息时,可将业务基础信息存储至该账户地址对应的账户中,以供后续区块链节点根据账户地址查询该业务基础信息。
基于上述对存储设备的配置,业务参与方客户端的业务图形码并非如相关技术中一样,用于记录业务基础信息和业务补充信息,而是用于记录业务参与方的身份标识和业务补充信息。那么,业务请求方客户端便可通过扫描业务图形码进而解析得到业务参与方的身份标识,进而通过该身份标识向区块链查询业务参与方的业务基础信息,从而利用业务参与方的业务基础信息中自身支持的业务基础信息进行业务处理。
步骤404,基于所述身份标识向所述存储设备发起针对所述业务参与方的查询请求,以使所述存储设备根据所述映射关系查找与所述查询请求中身份标识对应的候选业务基础信息。
在本实施例中,业务参与方生成的业务图形码中还可记录用于访问存储设备的信息。当存储设备为区块链节点时,业务图形码中可记录至少一个区块链节点的地址以用于业务请求方客户端获取该地址进而与该区块链节点对接。或者,业务图形码中可记录与之对接的区块链的索引(比如,区块链的ID或其他任意索引信息),那么业务请求方客户端便可解析业务图形码得到索引,进而访问相应的区块链。当然,上述用于访问区块链的信息还可配置于与各个业务响应服务端对应的业务请求客户端中,比如可写入业务请求客户端的安装包中。
当存储设备为容器平台服务端时,一种情况下,容器平台服务端的访问地址可记录于业务图形码中;在另一种情况下,还可在与各个业务响应服务端对应的业务请求客户端中均配置容器平台服务端的访问地址,比如可写入业务请求客户端的安装包中。
步骤406,获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理。
在本实施例中,各个业务参与方的业务基础信息和相应身份标识的映射关系被上传至存储设备进行记录。因此,存储设备可根据记录的映射关系查找出与查询交易中包含的身份标识对应的业务基础信息作为候选业务基础信息。
在一种情况下,可由存储设备从候选业务基础信息中识别得到与业务请求方客户端相匹配的目标业务基础信息,并将识别得到的目标业务基础信息返回至查询请求的发送方(即业务请求方客户端),那么业务请求方客户端可接收存储设备返回的目标业务基础信息以实现对目标业务基础信息的获取。其中,在存储设备为区块链节点的情况下,识别目标业务基础信息的逻辑可固化到链代码中,从而由存储设备节点直接执行该逻辑。或者,可在存储设备上部署针对业务基础信息的识别智能合约,该识别智能合约中声明有识别目标业务基础信息的逻辑。那么,查询交易(此时查询请求属于区块链中的交易)的to字段中可记录识别智能合约的合约地址,进而使得存储设备节点调用识别智能合约执行逻辑以识别目标业务基础信息。
在另一种情况下,存储设备节点在查询得到候选业务基础信息后,可直接将候选业务基础信息返回至业务请求方客户端。那么,业务请求方客户端可接收存储设备返回的候选业务基础信息,并在候选业务基础信息中识别与自身相匹配的业务基础信息以作为目标业务基础信息。
而针对识别目标业务基础信息的逻辑,业务响应服务端在配置业务基础信息时,可在业务基础信息中记录自身的服务端标识。换言之,任一业务基础信息中记录有配置该任一业务基础信息的业务服务端的服务端标识。基于上述对业务基础信息的设定,可在候选业务基础信息中查找记录有目标服务端标识的业务基础信息,并将查找到的业务基础信息作为目标业务基础信息,目标服务端标识为与业务请求方客户端对应的业务响应服务端的服务端标识。其中,针对由存储设备识别目标业务基础信息的情况,可在查询请求中记录发送方(业务请求方客户端)的客户端标识,以用于确定与该客户端标识对应的服务端标识。
在本实施例中,业务参与方客户端在向业务请求方客户端提供业务补充信息时,可能存在业务补充信息被恶意篡改的可能。因此,可通过数字签名来验证业务补充信息。其中,业务参与方客户端的公钥与该业务参与方客户端的身份标识的映射关系被存储至存储设备中。该存储过程可参考上述存储业务基础信息和身份标识的映射关系的过程,在此不再赘述。
作为一示例性实施例,业务参与方客户端在生成业务图形码时,可对业务补充信息和身份标识进行哈希运算得到信息摘要,再通过自身的私钥对信息摘要进行签名得到数字签名,并将数字签名记录至业务图形码中。那么,在对待处理业务进行处理之前,可以接收存储设备节点返回的与查询请求中包含的身份标识对应的公钥,并通过该公钥对解析业务图形码得到的数字签名进行数字签名验证。同时,对解析业务图形码得到的业务补充信息和身份标识进行哈希运算得到验证摘要。当验证摘要与通过数字签名验证得到的信息摘要不一致时,说明业务补充信息可能被篡改,因此禁止执行对待处理业务进行处理的操作。
相应的,请参见图5,图5是一示例性实施例提供的一种基于图形码的业务处理方法的流程图。如图5所示,该方法应用于存储设备,可以包括以下步骤:
步骤502,接收业务请求方客户端发起的针对业务参与方的查询请求,所述查询请求中包含所述业务参与方的身份标识,所述身份标识由所述业务请求方客户端解析业务参与方客户端生成的业务图形码得到,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至所述存储设备进行存储。
在本实施例中,存储在存储设备上的业务基础信息属于业务参与方的隐私数据,可结合TEE(Trusted Execution Environment,可信执行环境)来保护业务参与方的隐私安全。TEE可以起到硬件中的黑箱作用,在TEE中执行的代码和数据操作系统层都无法偷窥,只有代码中预先定义的接口才能对其进行操作。在效率方面,由于TEE的黑箱性质,在TEE中进行运算的是明文数据,而不是同态加密中的复杂密码学运算,计算过程效率没有损失,因此与TEE相结合可以在性能损失较小的前提下很大程度上提升存储设备的安全性和隐私性。
作为一示例性实施例,可采用特定对称密钥对业务基础信息进行加密,进而将加密后的业务基础信息存储至存储设备上。那么,在确定出候选业务基础信息时,可获取该特定对称密钥,将候选业务基础信息读入TEE内,从而在TEE内采用该特定对称密钥对候选业务基础信息进行解密。
针对存储设备为区块链节点的情况,业务参与方客户端可先打包一笔包含待存证的业务基础信息的交易,采用特定对称密钥对该交易进行加密,再向区块链节点提交该交易,以使得区块链节点在该交易通过共识后将交易发布至区块链进行存证。由于存证在区块链上的交易为密文形式,从而可有效防止隐私泄露。相应的,区块链节点在查询到包含候选业务基础信息的交易(与查询交易中包含的身份标识相对应)时,可获取该特定对称密钥,将该交易读入TEE内,并采用获取到的特定对称密钥对该交易进行解密从而得到交易中包含的候选业务基础信息。举例而言,该特定对称密钥可以是业务参与方的对称密钥(也可以是其他对称密钥,比如为seal密钥)。业务参与方客户端通过业务参与方的对称密钥对包含业务基础信息的交易进行加密以保证业务基础信息的隐私安全。那么,区块链节点在查询出候选业务基础信息后,获取TEE内维护的对应于该业务参与方的对称密钥,在TEE内通过该对称密钥对包含候选业务基础信息的交易进行解密以得到候选业务基础信息。
其中,业务参与方客户端在生成用于加密的对称密钥后,可向区块链节点发送该对称密钥以供区块链节点在TEE内维护。而业务参与方客户端在向区块链节点发送对称密钥时,可通过数字信封的公钥对对称密钥进行加密。因此,区块链节点在接收到业务参与方客户端发送的对称密钥后,在TEE内通过数字信封的私钥对接收到的对称密钥进行解密,并将解密后的对称密钥保存至TEE内。
以Intel SGX技术为例,SGX提供了围圈,即内存中一个加密的可信执行区域,由CPU保护数据不被窃取。以区块链节点采用支持SGX的CPU为例,利用新增的处理器指令,在内存中可以分配一部分区域EPC(Enclave Page Cache,围圈页面缓存或飞地页面缓存),通过CPU内的加密引擎MEE(Memory Encryption Engine)对其中的数据进行加密。EPC中加密的内容只有进入CPU后才会被解密成明文。因此,在SGX中,用户可以不信任操作系统、VMM(Virtual Machine Monitor,虚拟机监控器)、甚至BIOS(Basic Input Output System,基本输入输出系统),只需要信任CPU便能确保隐私数据不会泄漏。因此,本说明书中的TEE可通过SGX架构建立。其中,在TEE通过密钥管理服务器发起的远程证明后,数字信封的公钥由密钥管理服务器发送至业务参与方客户端,数字信封的私钥由密钥管理服务器发送至区块链节点的围圈。针对存储设备为容器平台服务端的情况,业务参与方客户端可采用特定对称密钥对待存证的业务基础信息进行加密,再向容器平台服务端发送包含加密后的业务基础信息和自身身份标识的请求,以使得容器平台服务端存储身份标识和业务基础信息(被加密)的映射关系。由于存储在容器平台服务端上的交易为密文形式,从而可有效防止隐私泄露。相应的,容器平台服务端在查询到候选业务基础信息时,可获取该特定对称密钥,将候选业务基础信息读入TEE内,并采用获取到的特定对称密钥对候选业务基础信息进行解密。其中,特定对称密钥的具体形式与上述类似,在此不再赘述。
步骤504,根据所述映射关系查找与所述查询请求中包含的身份标识对应的候选业务基础信息,以由所述业务请求方客户端获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的待处理业务的业务补充信息对所述待处理业务进行处理。
在本实施例中,业务参与方客户端在向业务请求方客户端提供业务补充信息时,可能存在业务补充信息被恶意篡改的可能。因此,可通过数字签名来验证业务补充信息。其中,业务参与方的公钥与该业务参与方的身份标识的映射关系被存储至存储设备中。该存储过程可参考上述存证业务基础信息和身份标识的映射关系的过程,在此不再赘述。
作为一示例性实施例,业务参与方客户端在生成业务图形码时,可对业务补充信息和身份标识进行哈希运算得到信息摘要,再通过业务参与方的私钥对信息摘要进行签名得到数字签名,并将数字签名记录至业务图形码中。那么,存储设备节点可获取与查询请求中包含的身份标识对应的公钥,并向业务请求方客户端返回该公钥,以使得该业务请求方客户端通过该公钥对解析业务图形码得到的数字签名进行数字签名验证。同时,该业务请求方客户端对解析业务图形码得到的业务补充信息和身份标识进行哈希运算得到验证摘要。当验证摘要与通过数字签名验证得到的信息摘要不一致时,说明业务补充信息可能被篡改,业务请求方客户端可禁止执行对待处理业务进行处理的操作。
进一步的,业务参与方可对数字签名所使用的公钥和私钥进行修改。当业务参与方客户端获得更新以后的更新私钥和更新私钥时,可向存储设备发起针对与业务参与方的身份标识对应的公钥的密钥更新请求(包含更新公钥)。同时,可设定为仅业务参与方才具备修改数字签名所使用的公私钥的权限。那么,业务参与方在使用业务参与方客户端向存储设备发起密钥更新请求时,可采用自身的私钥(原有私钥,而非更新私钥)对密钥更新请求进行数字签名。那么,存储设备节点在接收到该密钥更新请求后,通过业务参与方的公钥(原有公钥)进行数字签名验证,当验证得出该密钥更新请求被业务参与方的私钥进行数字签名时,可将与该业务参与方的身份标识对应的公钥更新为密钥更新请求中包含的更新公钥。
除此之外,还可更新业务参与方的业务基础信息。比如,可设定为当得到业务参与方的确认后,便可更新该业务参与方的业务基础信息;或者,当需要更新业务参与方的某一业务基础信息时,需要同时得到业务参与方与配置该业务基础信息的业务响应服务端的确认。其中,更新包括添加、删除、修改业务信息等。
类似的,可通过向存储设备发起针对业务参与方的业务基础信息的信息更新请求(包含更新业务基础信息和该业务参与方客户端的身份标识),来实现对业务基础信息的更新。其中,可通过数字签名的方式来表达上述“确认”的含义。那么,存储设备在接收到信息更新请求后,针对上述更新业务基础信息的第一种情况:当信息更新请求被业务参与方的私钥进行数字签名时(说明得到业务参与方客户端的确认),将存储设备存储的映射关系中与该业务参与方的身份标识对应的业务基础信息更新为更新业务基础信息。针对上述更新业务基础信息的第二种情况:当信息更新请求被业务参与方的私钥和与业务参与方相关联的任一业务响应服务端的私钥进行数字签名(即被业务参与方客户端和该任一业务响应服务端进行多重签名)时,将该任一业务响应服务端针对该业务参与方客户端配置的业务基础信息更新为更新业务基础信息。
需要说明的是,业务处理方法的详细过程可参考上述图4所示实施例,在此不再赘述。
由以上实施例可见,通过引入存储设备用于记录各个业务参与方的业务基础信息,可以在同一业务参与方客户端与多个业务响应服务端建立关联关系的情况下,将对应于各个业务响应服务端的业务图形码合并至一个支持互通性的业务图形码中,使得各个业务请求方均可以通过扫描该支持互通性的业务图形码来获取业务基础信息和业务补充信息,进而实施与该业务参与方相关的业务处理,从而可以降低成本,简化用户操作,提高业务处理效率。其中,该支持互通性的业务图形码中包含存储设备向业务参与方分配的身份标识即可,而无需包含各个业务响应服务端向业务参与方分配的业务基础信息。一方面,该支持互通性的业务图形码包含的信息量相对较少,有利于提高生成该业务图形码的效率,以及提高业务请求方客户端解析该业务图形码的准确率和速度,进而提升用户体验。另一方面,存储设备仅需执行针对业务基础信息的查询操作,无需执行生成业务图形码、聚合多个业务图形码、协助业务请求方客户端实施业务处理等涉及数据处理的复杂操作,从而避免占用较多的处理资源;因此,可在对存储设备的性能要求不高的情况下,保证业务的顺利进行。
同时,通过存储设备来记录各个业务响应服务端配置的业务基础信息,而无需将各个业务响应服务端配置的业务基础信息合并至一个图形码中,可以保留各个业务响应服务端配置的业务基础信息的原有信息格式,允许各个业务响应服务端仍然可以按照各自的信息格式来生成业务基础信息,从而向业务参与方提供差异化的服务。
为了便于理解,下面以商户订单码的应用场景为例对本说明书的技术方案进行详细说明。
请参见图6A,图6A是一示例性实施例提供的一种扫码支付的架构示意图。如图6A所示,该架构中包括区块链节点60(作为存储设备)、由商户使用的商户客户端61、支付平台的支付平台服务端62和由用户使用的支付客户端63。其中,商户客户端61、支付平台服务端62和支付客户端63均可以通过商户的商户标识来访问区块链上存证的该商户的收单信息。针对商户的收单信息(比如,支付平台向商户分配的账户、标识号、支付平台名称、支付平台的访问地址等),可由商户或者支付平台作为执行主体,打包一笔包含收单信息和商户标识的交易,并向区块链节点发起该交易,以使得区块链节点将交易中包含的商户标识和收单信息的映射关系(通过共识后)存证至区块链上。其中,对收单信息进行隐私保护的过程可参考上述图5所示实施例。
例如,在比特币的区块链模型中,商户客户端可通过向区块链进行注册以获得钱包地址作为自身的商户标识。那么,在存证与钱包地址对应的收单信息时,可将收单信息打包至区块中,并将该收单信息与钱包地址建立索引关系,以供后续区块链节点根据钱包地址查询该收单信息。而当对商户标识和收单信息的映射关系进行更新时,通过更新上述索引关系即可。
又如,在以太坊的区块链模型中,商户可使用商户客户端向区块链进行注册以获得账户地址作为自身的商户标识。那么,在存证与账户地址对应的收单信息时,可将收单信息存储至该账户地址对应的账户中,以供后续区块链节点根据账户地址查询该收单信息。例如,在以太坊或者基于以太坊的架构而衍生出的区块链模型中,可以包括外部账户和合约账户等。外部账户通常为用户(个人或机构)所有,由用户直接控制,也称之为用户账户;而合约账户则对应于区块链中的智能合约,由用户通过外部账户创建。各类账户的结构都类似,例如可以包含Nonce字段、Balance字段、Code字段和Storage字段等。每个账户的Nonce字段的取值从0开始,且Nonce字段的取值随相应账户所发起的交易而依次递增,使得该账户发起的每一交易所含Nonce取值均不相同,从而避免重放攻击。Balance字段用于存放余额。Code字段用于存放智能合约的合约代码(在实际应用中,Code字段中通常仅维护合约代码的hash值,因此Code字段通常也称之为Codehash字段),因而外部账户的Code字段通常为空。Storage字段用于存放账户在状态树中对应节点处的取值。因此,可将业务基础信息存储至外部账户的Code字段、Storage字段或者其他自定义的字段中。而当对商户标识和收单信息的映射关系进行更新时,在该账户地址对应的账户的相应字段更新收单信息即可。
请参见图6B,图6B是一示例性实施例提供的另一种扫码支付的架构示意图。如图6B所示,该架构中包括容器平台服务端64(作为存储设备)、由商户使用的商户客户端61、支付平台的支付平台服务端62和由用户使用的支付客户端63。其中,商户客户端61、支付平台服务端62和支付客户端63均可以通过商户的商户标识来访问容器平台服务端64中记录的该商户的收单信息。
以下以存储设备为区块链节点的情况进行说明,存储设备为容器平台服务端与此类似。
请参见图7,图7是一示例性实施例提供的一种基于订单码进行支付的示意图。如图7所示,该支付过程可以包括以下步骤:
步骤702,商户客户端61基于订单信息、商户标识和商户签名生成订单码。
在本实施例中,当用户从商户中选取所需购买的商品时,由商户通过商户客户端61针对用户选取的商品生成待支付订单的订单信息。而在生成对应于待支付订单的订单码时,可对订单信息和商户标识进行哈希运算得到信息摘要,再通过自身的私钥对信息摘要进行签名得到数字签名,并将数字签名记录至订单码中。
步骤704,支付客户端63扫描商户的订单码得到商户标识、订单信息和商户签名。
步骤706,支付客户端63向区块链节点60发送查询交易(包含商户标识)。
步骤708,区块链节点60在记录的映射关系中查询与查询交易中包含的商户标识对应的收单信息和商户公钥。
步骤710,区块链节点60向支付客户端63返回查询到的收单信息(即候选收单信息)和商户公钥。
在本实施例中,支付平台在配置收单信息时,可在收单信息中记录自身的服务端标识。例如,收单信息中包含支付平台的名称,该名称作为上述服务端标识。基于上述对收单信息的设定,可在候选收单信息中查找记录有目标服务端标识的收单信息,并将查找到的收单信息作为目标收单信息,目标服务端标识为与支付客户端对应的支付平台的服务端标识。
在本实施例中,还可由区块链20从候选收单信息中识别得到与支付客户端相匹配的目标收单信息,并将识别得到的目标收单信息返回至支付客户端63。在该情况下,支付客户端63可在查询交易中记录自身的客户端标识,以用于确定与该客户端标识对应的服务端标识。
举例而言,支付平台A的名称为A,该支付平台的支付App(安装于用户的支付客户端中)的客户端标识为a,若查找到候选收单信息中存在记录有A的收单信息,则将该收单信息作为支付客户端a支持的收单信息;否则,说明支付客户端s不支持当前商户,交易终止。
步骤712,支付客户端63通过商户公钥对商户签名进行数字签名验证。
验证过程可参考上述图4所述实施例的相应部分,在此不再赘述。
步骤714,当验证通过时,支付客户端63识别支持的收单信息,并基于支持的收单信息和订单信息完成支付。
在本实施例中,支付客户端63在基于目标收单信息和订单信息完成对商户的支付之前,可先展示订单信息以供用户确认。例如,订单信息为用户当前与商户产生的订单的交易金额、交易明细等支付信息,在用户完成对订单信息的确认后,确认提交进行支付。支付客户端向支付平台提交支付请求指令(包含商户的账户信息和订单信息中的交易金额等),以由支付平台对支付指令进行处理,完成支付过程,并向支付客户端和商户客户端返回支付结果。
由以上实施例可见,通过引入区块链用于记录各个商户客户端的收单信息,可以在同一商户客户端与多个支付平台建立关联关系的情况下,将对应于各个支付平台的订单码合并至一个支持互通性的订单码(记录区块链向商户客户端分配的商户标识,以及商户客户端生成的订单信息)中,使得各个用户均可以通过扫描该支持互通性的订单码来实施与该商户客户端相关的支付业务,从而可以降低成本,简化用户操作,提高支付效率。其中,该支持互通性的订单码中包含区块链网络向商户分配的身份标识即可,而无需包含各个业务响应服务端向商户分配的业务基础信息。一方面,该支持互通性的订单码包含的信息量相对较少,有利于提高生成该订单码的效率,以及提高支付客户端解析该订单码的准确率和速度,进而提升用户体验。另一方面,区块链节点仅需执行针对业务基础信息的查询操作,无需执行生成订单码、聚合多个订单码、协助支付客户端实施支付过程等涉及数据处理的复杂操作,从而避免占用较多的处理资源;因此,可在对区块链节点的性能要求不高的情况下,保证业务的顺利进行。
同时,通过区块链节点来记录各个支付平台配置的收单信息,而无需将各个支付平台配置的收单信息合并至一个订单码中,可以保留各个支付平台配置的收单信息的原有信息格式,允许各个支付平台仍然可以按照各自的信息格式来生成收单信息,从而向商户提供差异化的服务。
与上述方法实施例相对应,本说明书还提供了一种业务处理装置的实施例。
本说明书的业务处理装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言,请参考图8,图8是一示例性实施例提供的一种设备的示意结构图。如图8所示,在硬件层面,该设备包括处理器802、内部总线804、网络接口806、内存808以及非易失性存储器810,当然还可能包括其他业务所需要的硬件。处理器802从非易失性存储器810中读取对应的计算机程序到内存808中然后运行,在逻辑层面上形成业务处理装置。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图9,在软件实施方式中,该业务处理装置应用于业务参与方客户端,可以包括:
生成单元91,根据待处理业务的业务补充信息和业务参与方的身份标识生成业务图形码以由业务请求方客户端解析,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储;
其中,当业务请求方客户端解析所述业务图形码得到所述身份标识时,所述身份标识由所述业务请求方客户端通过针对所述业务参与方客户端的查询请求提交至所述存储设备,以由所述存储设备节点根据所述映射关系查找与所述身份标识对应的候选业务基础信息,所述业务请求方客户端在基于解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理时所采用的业务基础信息,为所述候选业务基础信息中与所述业务请求方客户端相匹配的业务基础信息。
可选的,所述存储设备包括区块链节点,所述业务参与方客户端的业务基础信息和所述身份标识的映射关系被所述区块链节点发布至区块链进行存证。
可选的,所述业务参与方包括商户,所述业务请求方包括支付方,所述待处理业务包括待支付订单,所述业务补充信息包括所述待支付订单的订单信息,与所述商户客户端相关联的业务响应服务端包括支付平台服务端,各个支付平台服务端针对所述商户配置的业务基础信息包括收单信息。
本说明书的业务处理装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言,请参考图10,图10是一示例性实施例提供的一种设备的示意结构图。如图10所示,在硬件层面,该设备包括处理器1002、内部总线1004、网络接口1006、内存1008以及非易失性存储器1010,当然还可能包括其他业务所需要的硬件。处理器1002从非易失性存储器1010中读取对应的计算机程序到内存1008中然后运行,在逻辑层面上形成业务处理装置。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图11,在软件实施方式中,该业务处理装置应用于业务请求方客户端,可以包括:
解析单元1101,解析业务参与方客户端生成的业务图形码以得到所述业务图形码中包含的待处理业务的业务补充信息和业务参与方的身份标识,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至存储设备进行存储;
查询单元1102,基于所述身份标识向所述存储设备发起针对所述业务参与方的查询请求,以使所述存储设备根据所述映射关系查找与所述查询请求中身份标识对应的候选业务基础信息;
业务处理单元1103,获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的业务补充信息对所述待处理业务进行处理。
可选的,所述业务图形码还包含通过所述业务参与方客户端的私钥对信息摘要进行签名得到的数字签名,所述信息摘要由对所述业务补充信息和所述身份标识进行哈希运算得到;在对所述待处理业务进行处理之前,所述装置还包括:
接收单元1104,接收所述存储设备节点返回的与所述查询请求中包含的身份标识对应的公钥,并通过所述公钥对解析所述业务图形码得到的所述数字签名进行数字签名验证;
摘要获取单元1105,对解析所述业务图形码得到的业务补充信息和身份标识进行哈希运算得到验证摘要;
验证单元1106,当所述验证摘要与通过数字签名验证得到的信息摘要不一致时,禁止执行对所述待处理业务进行处理的操作。
可选的,所述业务处理单元1103具体用于:
接收所述存储设备返回的所述目标业务基础信息,所述目标业务基础信息由所述存储设备从所述候选业务基础信息中识别得到;
或者,接收所述存储设备返回的所述候选业务基础信息,并在接收到的候选业务基础信息中识别与所述业务请求方客户端相匹配的业务基础信息以作为所述目标业务基础信息。
可选的,任一业务基础信息记录有配置所述任一业务基础信息的业务响应服务端的服务端标识;通过以下方式识别出所述目标业务基础信息:
在所述候选业务基础信息中查找记录有目标服务端标识的业务基础信息,并将查找到的业务基础信息作为所述目标业务基础信息,所述目标服务端标识为与所述业务请求方客户端对应的业务响应服务端的服务端标识。
可选的,所述存储设备包括区块链节点,所述业务参与方客户端的业务基础信息和所述身份标识的映射关系被所述区块链节点发布至区块链进行存证。
可选的,所述业务参与方包括商户,所述业务请求方包括支付方,所述待处理业务包括待支付订单,所述业务补充信息包括所述待支付订单的订单信息,与所述商户客户端相关联的业务响应服务端包括支付平台服务端,各个支付平台服务端针对所述商户配置的业务基础信息包括收单信息。
本说明书的业务处理装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。
从硬件层面而言,请参考图12,图12是一示例性实施例提供的一种设备的示意结构图。如图12所示,在硬件层面,该设备包括处理器1202、内部总线1204、网络接口1206、内存1208以及非易失性存储器1210,当然还可能包括其他业务所需要的硬件。处理器1202从非易失性存储器1210中读取对应的计算机程序到内存1208中然后运行,在逻辑层面上形成业务处理装置。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图13,在软件实施方式中,该业务处理装置应用于存储设备,可以包括:
第一接收单元1301,接收业务请求方客户端发起的针对业务参与方的查询请求,所述查询请求中包含所述业务参与方的身份标识,所述身份标识由所述业务请求方客户端解析业务参与方客户端生成的业务图形码得到,所述业务参与方与至少一个业务响应服务端相关联,各个相关联的业务响应服务端针对所述业务参与方配置有相应的业务基础信息,各个相关联的业务响应服务端分别为所述业务参与方产生的业务基础信息和所述身份标识的映射关系被上传至所述存储设备进行存储;
查询单元1302,根据所述映射关系查找与所述查询请求中包含的身份标识对应的候选业务基础信息,以由所述业务请求方客户端获取所述候选业务基础信息中与所述业务请求方客户端相匹配的目标业务基础信息,并基于所述目标业务基础信息和解析所述业务图形码得到的待处理业务的业务补充信息对所述待处理业务进行处理。
可选的,存储在所述存储设备的业务基础信息被采用特定对称密钥进行加密;所述装置还包括:
第一获取单元1303,获取所述特定对称密钥;
解密单元1304,在可信执行环境内采用所述特定对称密钥对查找到的候选业务基础信息进行解密。
可选的,所述业务图形码还包含通过所述业务参与方的私钥对信息摘要进行签名得到的数字签名,所述信息摘要由对所述业务补充信息和所述身份标识进行哈希运算得到;所述装置还包括:
第二获取单元1305,获取与所述查询请求中包含的身份标识对应的公钥;
返回单元1306,向所述业务请求方客户端返回所述公钥,以使得所述业务请求方客户端通过所述公钥对解析所述业务图形码得到的所述数字签名进行数字签名验证,并在验证摘要与通过数字签名验证得到的信息摘要不一致时禁止执行对所述待处理业务进行处理的操作;所述验证摘要由所述业务请求方客户端对解析所述业务图形码得到的业务补充信息和身份标识进行哈希运算得到。
可选的,还包括:
第二接收单元1307,接收针对与所述业务参与方的身份标识对应的公钥的密钥更新请求,所述密钥更新请求中包含更新公钥;
第一更新单元1308,当所述密钥更新请求被所述业务参与方的私钥进行数字签名时,将与所述业务参与方的身份标识对应的公钥更新为所述更新公钥。
可选的,还包括:
第三接收单元1309,接收针对所述业务参与方的业务基础信息的信息更新请求,所述信息更新请求中包含更新业务基础信息;
第二更新单元1310,当所述信息更新请求被所述业务参与方的私钥进行数字签名时,将所述存储设备存储的映射关系中与所述业务参与方的身份标识对应的业务基础信息更新为所述更新业务基础信息;
或者,当所述信息更新请求被所述业务参与方的私钥和与所述业务参与方相关联的任一业务响应服务端的私钥进行数字签名时,将所述任一业务响应服务端针对所述业务参与方配置的业务基础信息更新为所述更新业务基础信息。
可选的,所述存储设备包括区块链节点,所述业务参与方客户端的业务基础信息和所述身份标识的映射关系被所述区块链节点发布至区块链进行存证。
可选的,所述业务参与方包括商户,所述业务请求方包括支付方,所述待处理业务包括待支付订单,所述业务补充信息包括所述待支付订单的订单信息,与所述商户客户端相关联的业务响应服务端包括支付平台服务端,各个支付平台服务端针对所述商户配置的业务基础信息包括收单信息。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的,计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。