用于双离线场景下的聚合支付方法、装置、接收端及支付端与流程

用于双离线场景下的聚合支付方法、装置、接收端及支付端
【技术领域】
1.本发明涉及数字资产技术领域，尤其涉及一种用于双离线场景下的聚合支付方法、装置、接收端及支付端。


背景技术：

2.数字资产是指以电子数据形式存在的资产，例如虚拟资产、数字货币、电子货币等。在数字资产的网络支付业务中，通常的情形是支付端(如付款方设备)和接收端(如收款方设备)中的至少一方能够与数字资产服务端(如登记中心、支付中心)进行实时通信，并向数字资产服务端发出支付数字资产或接收数字资产的请求，数字资产服务端根据收到的请求进行数字资产的实时划转。
3.双离线场景是指在支付端和接收端都不能与数字资产服务端进行实时通信时的场景，例如行驶中的飞机、没有网络信号覆盖的偏僻山区或公海轮船或地下商场、数万人同时就餐造成网络支付堵塞的大型食堂、通信网络或数字资产服务端出现故障等场景，使得支付端和接收端都不能与数字资产服务端进行实时通信。相应的，双离线支付是指在双离线场景下进行的支付。
4.随着数字资产业务在金融、支付等领域的快速推进，例如支付宝、微信支付、央行数字货币及各类银行支付业务等，都有实施双离线支付的需求和必要，因此，针对支付宝、微信支付、央行数字货币及各类银行支付业务等的双离线支付方式，为了简化支付端和接收端的操作和提高使用体验，有必要提供双离线场景下的聚合支付能力，将多种双离线支付方式进行整合。
5.需要说明的是，上述背景信息仅用于加强对本发明背景技术的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术信息。


技术实现要素：

6.本发明的主要目的在于提供一种用于双离线场景下的聚合支付方法、装置、接收端及支付端，进而至少在一定程度上解决由于相关技术的限制和缺陷而导致的一个或者多个技术问题，包括以下技术方案：
7.第一方面，提供了一种用于双离线场景下的聚合支付方法，应用于支付端，所述方法包括：
8.通过局域网络向接收端发送支付请求，以使得所述接收端获取预先设置的商户识别信息；
9.接收所述接收端返回的所述预先设置的商户识别信息；
10.生成离线支付凭证，所述离线支付凭证中包括所述预先设置的商户识别信息和相应的数字资产；
11.通过局域网络向所述接收端对应的验证接口发送所述离线支付凭证，以使得所述对应的验证接口在接收到所述离线支付凭证时调用对应的验证方式以进行验证，并且在验
证所述离线支付凭证合法之后，确定所述支付端支付成功，所述对应的验证接口是指对应于所述支付端的验证接口。
12.优选的，所述相应的数字资产包括：
13.余额形式的数字资产，或者字符串形式的数字资产。
14.优选的，若所述接收端提供对多个商户的支持，则在所述支付请求中还包括映射字符串，以使得所述接收端获取该映射字符串，并且根据该映射字符串获取相应商户的商户识别信息。
15.优选的，所述通过局域网络向所述接收端对应的验证接口发送所述离线支付凭证包括：
16.在所述支付端内预置所述对应的验证接口的地址，根据该预置的地址将所述离线支付凭证发送给所述对应的验证接口；或者，
17.所述接收所述接收端返回的所述预先设置的商户识别信息还包括接收所述接收端返回的验证接口地址，根据该验证接口地址将所述离线支付凭证发送给所述对应的验证接口。
18.优选的，所述通过局域网络向接收端发送支付请求还包括：
19.在所述支付请求中还包括所述支付端的支付识别信息，以使得所述接收端从所述支付请求中获取该支付识别信息；或者，
20.在发送所述支付请求时还携带所述支付端的客户端识别信息，以使得所述接收端根据该客户端识别信息获取支付识别信息。
21.优选的，所述商户识别信息包括：
22.终端设备标识、芯片卡标识、手机号码、账号、数字证书、公钥、基于公钥生成的地址或其他可用于唯一地确定数字资产接收账户的信息。
23.优选的，所述生成离线支付凭证还包括：
24.对待签名信息进行数字签名生成签名值，在所述离线支付凭证中还包括所述签名值，所述待签名信息包括所述相应的数字资产。
25.优选的，所述待签名信息还包括：
26.所述预先设置的商户识别信息。
27.第二方面，提供了一种用于双离线场景下的聚合支付方法，应用于接收端，所述接收端聚合多种双离线支付方式，其中每种支付方式有每种支付方式对应的验证方式，所述方法包括：
28.在接收到支付端通过局域网络发送的支付请求时，获取预先设置的商户识别信息并且返回给所述支付端，以使得所述支付端在生成的离线支付凭证中包括所述预先设置的商户识别信息和相应的数字资产；
29.提供多个验证接口，其中每个验证接口分别对应于所述多种双离线支付方式中一种支付方式的验证方式，并且若接收到所述离线支付凭证则调用该验证接口对应的验证方式以进行验证，在验证所述离线支付凭证合法之后，确定所述支付端支付成功；
30.其中，所述每种支付方式对应的验证方式包括：
31.商户验证方式，具体的，获取所述离线支付凭证中包括的商户识别信息，以及获取该种验证方式对应的商户识别信息，判断所述对应的商户识别信息与所述包括的商户识别
信息是否一致，若一致，则确定验证通过；
32.若实施的验证方式都确定验证通过，则确定所述离线支付凭证合法。
33.优选的，所述相应的数字资产包括：
34.余额形式的数字资产，或者字符串形式的数字资产。
35.优选的，若所述接收端在每种支付方式对应的服务端上注册的是相同的商户识别信息，则所述方法包括：
36.所述接收端预先设置所述相同的商户识别信息；
37.所述获取预先设置的商户识别信息包括：获取所述相同的商户识别信息；
38.所述获取该种验证方式对应的商户识别信息包括：获取所述相同的商户识别信息为所述对应的商户识别信息。
39.进一步的，若所述接收端在每种支付方式对应的服务端上注册的是相同的商户识别信息，，并且所述接收端提供对多个商户的支持，则所述方法还包括：
40.所述接收端预先设置所述相同的商户识别信息包括：预先建立映射字符串与所述相同的商户识别信息的对应关系；
41.在所述支付请求中还包括映射字符串，获取该映射字符串；
42.所述获取预先设置的商户识别信息包括：根据该映射字符串通过该对应关系获取对应的商户识别信息。
43.优选的，若所述接收端在每种支付方式对应的服务端上注册的商户识别信息不相同，则所述方法包括：
44.所述获取预先设置的商户识别信息包括：预先建立支付识别信息与商户识别信息的对应关系，根据所述支付请求获取支付识别信息，根据所述支付识别信息通过该对应关系获取对应的商户识别信息；
45.所述获取该种验证方式对应的商户识别信息包括：获取该种验证方式对应的商户识别信息为所述对应的商户识别信息，其中，每种验证方式预先设置对应的商户识别信息。
46.进一步的，若所述接收端在每种支付方式对应的服务端上注册的商户识别信息不相同，并且所述接收端提供对多个商户的支持，则所述方法还包括：
47.所述接收端预先建立支付识别信息与商户识别信息的对应关系包括：预先建立映射字符串、支付识别信息与商户识别信息的对应关系；
48.在所述支付请求中还包括映射字符串，获取该映射字符串；
49.所述获取预先设置的商户识别信息包括：根据该映射字符串和所述支付识别信息通过该对应关系获取对应的商户识别信息。
50.优选的，所述获取预先设置的商户识别信息并且返回给所述支付端还包括：
51.根据所述支付请求获取支付识别信息；
52.根据所述支付识别信息获取对应的验证接口地址，并且将所述验证接口地址返回给所述支付端，以使得所述支付端根据所述验证接口地址将生成的所述离线支付凭证发送给对应的验证接口。
53.优选的，所述根据所述支付请求获取支付识别信息包括：
54.所述支付请求中包括所述支付端的支付识别信息，从所述支付请求中获取所述支付识别信息；或者，
55.根据所述支付端在发送所述支付请求时携带的客户端识别信息获取所述支付识别信息。
56.优选的，所述提供多个验证接口包括提供验证接口一和验证接口二，其中：
57.所述验证接口一对应于第一种验证方式，并且若接收到所述离线支付凭证则调用该第一种验证方式以进行验证，该第一种验证方式为对支付方式一的离线支付凭证进行验证的验证方式；
58.所述验证接口二对应于第二种验证方式，并且若接收到所述离线支付凭证则调用该第二种验证方式以进行验证，该第二种验证方式为对支付方式二的离线支付凭证进行验证的验证方式。
59.优选的，所述每个验证接口分别对应于所述多种双离线支付方式中一种支付方式的验证方式包括：每个验证接口分别对应于所述多种双离线支付方式中一种支付方式的验证sdk；所述若接收到所述离线支付凭证则调用该验证接口对应的验证方式以进行验证包括：若接收到所述离线支付凭证则调用该验证接口对应的验证sdk以进行验证。
60.优选的，所述判断所述对应的商户识别信息与所述包括的商户识别信息是否一致包括：
61.若所述对应的商户识别信息为一个商户识别信息，则将所述对应的商户识别信息与所述包括的商户识别信息进行比较，若一致，则确定验证通过；或者，
62.若所述对应的商户识别信息包括多个商户识别信息，则将所述多个商户识别信息与所述包括的商户识别信息分别进行比较，若其中有任意一个商户识别信息与所述包括的商户识别信息相一致，则确定验证通过。
63.优选的，所述商户识别信息包括：
64.终端设备标识、芯片卡标识、手机号码、账号、数字证书、公钥、基于公钥生成的地址或其他可用于唯一地确定数字资产接收账户的信息。
65.优选的，所述每种支付方式对应的验证方式还包括对应的数字签名验证方式，具体的，所述离线支付凭证中包括签名值，所述签名值为所述支付端对待签名信息进行数字签名生成的签名值，所述待签名信息包括所述相应的数字资产，使用该对应的数字签名验证方式根据所述签名值对所述离线支付凭证进行数字签名验证。
66.优选的，所述对应的数字签名验证方式包括：
67.对应的数字签名验证相关加密算法、或/和对应的待校验信息生成方式、或/和对应的公钥、或/和对应的根证书、或/和对应的公共参数。
68.优选的，在所述确定所述支付端支付成功之后还包括：
69.将所述离线支付凭证发送给所述对应的验证方式所对应的服务端，以使得所述对应的服务端根据所述离线支付凭证进行数字资产的划转。
70.优选的，所述将所述离线支付凭证发送给所述对应的验证方式所对应的服务端包括：
71.所述接收端与所述对应的服务端建立网络连接，所述接收端通过网络将所述离线支付凭证发送给所述对应的服务端；或者，
72.所述接收端将所述离线支付凭证同步给中转设备，以使得所述中转设备通过网络将所述离线支付凭证发送给所述对应的服务端。
73.第三方面，提供了一种用于双离线场景下的聚合支付装置，所述装置包括：
74.接收模块：用于接收支付端通过局域网络发送的支付请求；
75.商户获取模块，用于获取预先设置的商户识别信息；
76.返回模块，用于将所述预先设置的商户识别信息返回给所述支付端，以使得所述支付端在生成的离线支付凭证中包括所述预先设置的商户识别信息和相应的数字资产；
77.验证接口一，用于接收支付方式为支付方式一的离线支付凭证，并且在接收到所述支付方式一的离线支付凭证时调用验证模块一以进行验证；
78.所述验证模块一，用于对所述支付方式一的离线支付凭证进行验证，其中包括商户验证单元一，具体的，所述支付方式一的离线支付凭证中包括商户识别信息，所述商户验证单元一用于获取该包括的商户识别信息，以及获取对应的商户识别信息，判断该对应的商户识别信息与该包括的商户识别信息是否一致，若一致，则确定验证通过，并且当所述验证模块一包括的验证单元在执行时都确定验证通过，则确定所述支付方式一的离线支付凭证合法；
79.验证接口二，用于接收支付方式为支付方式二的离线支付凭证，并且在接收到所述支付方式二的离线支付凭证时调用验证模块二以进行验证；
80.所述验证模块二，用于对所述支付方式二的离线支付凭证进行验证，其中包括商户验证单元二，具体的，所述支付方式二的离线支付凭证中包括商户识别信息，所述商户验证单元二用于获取该包括的商户识别信息，以及获取对应的商户识别信息，判断该对应的商户识别信息与该包括的商户识别信息是否一致，若一致，则确定验证通过，并且当所述验证模块二包括的验证单元在执行时都确定验证通过，则确定所述支付方式二的离线支付凭证合法；
81.接受模块，用于在所述验证模块一或所述验证模块二确定离线支付凭证合法之后，确定所述支付端支付成功。
82.优选的，若所述接收端在所述支付方式一和所述支付方式二对应的服务端上注册的是相同的商户识别信息，则所述装置还包括存储单元一，其中：
83.所述存储单元一用于预先存储所述相同的商户识别信息；
84.所述商户获取模块中所述获取预先设置的商户识别信息包括：从所述存储单元一中获取所述相同的商户识别信息；
85.所述商户获取单元一中所述获取对应的商户识别信息包括：从所述存储单元一中获取所述相同的商户识别信息；
86.所述商户获取单元二中所述获取对应的商户识别信息包括：从所述存储单元一中获取所述相同的商户识别信息。
87.优选的，若所述接收端在所述支付方式一和所述支付方式二对应的服务端上注册的是不相同的商户识别信息，其中，所述接收端在所述支付方式一对应的服务端上注册的商户识别信息为商户识别信息一，所述接收端在所述支付方式二对应的服务端上注册的商户识别信息为商户识别信息二，则所述装置还包括存储单元二、存储单元三和存储单元四，其中：
88.所述存储单元二用于预先存储支付识别信息与商户识别信息的对应关系，其中包括存储支付识别信息一与所述商户识别信息一的对应关系，以及存储支付识别信息二与所
述商户识别信息二的对应关系；
89.所述商户获取模块中所述获取预先设置的商户识别信息包括：根据所述支付请求获取支付识别信息，并且根据所述支付识别信息在所述存储单元二中通过该对应关系获取对应的商户识别信息，其中包括，当所述支付识别信息为所述支付识别信息一时，则获取的商户识别信息为所述商户识别信息一，当所述支付识别信息为所述支付识别信息二时，则获取的商户识别信息为所述商户识别信息二；
90.所述存储单元三用于存储所述商户识别信息一；
91.所述商户验证单元一中所述获取对应的商户识别信息包括：从所述存储单元三中获取所述商户识别信息一；
92.所述存储单元四用于存储所述商户识别信息二；
93.所述商户验证单元二中所述获取对应的商户识别信息包括：从所述存储单元四中获取所述商户识别信息二。
94.优选的，所述装置还包括：
95.获取识别模块，用于根据所述支付请求获取支付识别信息；
96.地址获取模块，用于根据所述支付识别信息获取对应的验证接口地址，并且将所述验证接口地址返回给所述支付端，以使得所述支付端根据所述验证接口地址将生成的所述离线支付凭证发送给对应的验证接口。
97.优选的，所述获取识别模块包括：
98.获取识别单元一，用于从所述支付请求中获取所述支付识别信息，所述支付请求中包括所述支付端的支付识别信息；或者，
99.获取识别单元二，用于根据所述支付端在发送所述支付请求时携带的客户端识别信息获取所述支付识别信息。
100.优选的，所述验证模块一还包括：
101.签名验证单元一，用于若所述离线支付凭证还包括签名值，该签名值为支付端一对待签名信息进行数字签名生成的签名值，该待签名信息包括所述相应的数字资产，则根据该签名值对所述离线支付凭证进行数字签名验证，其中，该数字签名验证的验证方式为所述支付方式一所对应的数字签名验证方式，所述支付端一为所述支付方式一的支付端。
102.优选的，所述验证模块二还包括：
103.签名验证单元二，用于若所述离线支付凭证还包括签名值，该签名值为支付端二对待签名信息进行数字签名生成的签名值，该待签名信息包括所述相应的数字资产，则根据该签名值对所述离线支付凭证进行数字签名验证，其中，该数字签名验证的验证方式为所述支付方式二所对应的数字签名验证方式，所述支付端二为所述支付方式二的支付端；
104.优选的，所述装置还包括：
105.发送模块，用于在所述接受模块确定所述支付端支付成功之后，将确定合法的离线支付凭证发送给验证该离线支付凭证的验证模块所对应的服务端，以使得所述对应的服务端根据该离线支付凭证进行数字资产的划转，其中具体包括，对于所述验证模块一确定合法的离线支付凭证，将该离线支付凭证发送给服务端一，对于所述验证模块二确定合法的离线支付凭证，将该离线支付凭证发送给服务端二。
106.第四方面，一种支付端设备，所述支付端设备包括处理器、存储器，所述处理器用
于运行所述存储器所存储的程序，所述程序运行时执行包括如上第一方面所述的方法。
107.一种接收端设备，所述接收端设备包括处理器、存储器，所述处理器用于运行所述存储器所存储的程序，所述程序运行时执行包括如上第二方面所述的方法。
108.一种聚合支付系统，其特征在于，所述系统包括如上第三方面所述的装置。
109.一种存储介质，所述存储介质中存储有程序，所述程序用于实现如上第一方面所述的方法，或者所述程序用于实现如上第二方面所述的方法。
110.综上所述，本发明提供的技术方案应用在双离线场景下，接收端提供多个验证接口，每个验证接口分别提供多种双离线支付方式中一种支付方式的验证方式，其中每个验证接口在接收到离线支付凭证时调用该验证接口对应的验证方式以进行验证，其中，该离线支付凭证中包括的商户识别信息是接收端向支付端提供的，从而使得支付端在生成的该离线支付凭证中包括该商户识别信息，进而使得该离线支付凭证通过接收端的验证。带来的技术效果可以在接收端上整合多种双离线支付方式；对于支付端而言，不需要用户或应用服务器向支付端提供商户识别信息，使用同一个输入信息即可以触发不同的支付端完成数字资产的支付过程，从而简化了支付端的操作，提高了用户的使用体验。
【附图说明】
111.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
112.图1是本发明所涉及的一种实施环境的结构示意图；
113.图2是一种用于双离线场景下的聚合支付方法实施例一的流程示意图；
114.图3是一种用于双离线场景下的聚合支付方法实施例二的流程示意图；
115.图4是一种用于双离线场景下的聚合支付方法实施例三的流程示意图；
116.图5是一种用于双离线场景下的聚合支付装置实施例一的结构示意图；
117.图6是一种用于双离线场景下的聚合支付装置实施例二的结构示意图；
118.图7是一种用于双离线场景下的聚合支付装置实施例三的结构示意图；
119.图8是一种用于双离线场景下的聚合支付装置实施例四的结构示意图；
120.图9是一种用于双离线场景下的聚合支付装置实施例五的结构示意图；
121.图10是一种用于双离线场景下的聚合支付装置实施例六的结构示意图。
122.本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
【具体实施方式】
123.为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
124.一、实施环境说明
125.请参考图1，其示出了本发明所涉及的一种实施环境的结构示意图，其中：
126.接收端是指数字资产的接收端，用于接收支付端的离线支付，以及用于聚合多种
双离线支付方式，例如聚合支付宝、微信支付、央行数字货币及各类银行支付业务等的双离线支付方式，也可以理解为接收端用于支持多种可用于双离线场景下的支付方式或支付通道。接收端既可以是软件程序，也可以是由软件和硬件组合实现的设备，例如，可以是智能手机、销售终端(pos机)、pc(个人电脑)、服务器、智能电视、平板电脑、笔记本电脑等设备，也可以是其他带有通信功能的设备。
127.支付端是指数字资产的支付端，用于向接收端进行离线支付。支付端既可以是软件程序，例如支付客户端程序；也可以是由软件和硬件组合实现的设备，例如，既可以是智能手机、智能电视、平板电脑、笔记本电脑等用户终端设备，也可以是智能手表、智能手环等可穿戴式终端设备，还可以是其他带有通信功能的设备。
128.对于接收端聚合的多种双离线支付方式，其中，每种支付方式分别有其对应的服务端和支付端，例如，支付宝有支付宝的服务端和支付端(或称为客户端)，微信支付有微信支付的服务端和支付端(或称为客户端)，央行数字货币有央行数字货币的服务端和支付端等。如图1所示示例，接收端连接的支付端包括支付端一和支付端二，接收端连接的服务端包括服务端一和服务端二，其中，支付端一和服务端一分别为支付方式一对应的支付端和服务端，支付端二和服务端二分别为支付方式二对应的支付端和服务端，可以理解，实际实施过程中，接收端还可以聚合支付方式三、支付方式四、支付方式五等更多的支付方式，相应的，每种支付方式分别有其对应的服务端和支付端。
129.支付端(例如如图1所示的支付端一或支付端二)与接收端之间的信息传递通过局域网络以实现，具体的，在支付端和接收端不能与互联网实时通信的环境下，在该环境内建立局域网络，支付端和接收端接入该局域网络，支付端与接收端通过该局域网络相互通信。
130.接收端与服务端(例如如图1所示的服务端一或服务端二)之间的信息传递，既可以由接收端与服务端建立网络连接以实现直接的信息传递，该网络既可以是互联网，也可以是专用的网络；也可以由接收端通过中转设备与服务端实现间接的信息传递。
131.需要说明的是，本领域技术人员可以理解，图1中示出的实施环境结构并不构成对实施环境的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。图1中示出的实施环境结构仅用于加强对本发明技术的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术信息。
132.二、一种用于双离线场景下的聚合支付方法实施例一
133.请参考图2，其示出了本发明提供的一种用于双离线场景下的聚合支付方法实施例一的流程图。本实施例以该方法应用于图1所示实施环境中的支付端来举例说明，该方法可以包括：
134.步骤201.通过局域网络向接收端发送支付请求，以使得所述接收端获取预先设置的商户识别信息。
135.步骤202.接收所述接收端返回的所述预先设置的商户识别信息。
136.步骤203.生成离线支付凭证，所述离线支付凭证中包括所述预先设置的商户识别信息和相应的数字资产。
137.步骤204.通过局域网络向所述接收端对应的验证接口发送所述离线支付凭证，以使得所述对应的验证接口在接收到所述离线支付凭证时调用对应的验证方式以进行验证，并且在验证所述离线支付凭证合法之后，确定所述支付端支付成功，所述对应的验证接口
是指对应于所述支付端的验证接口。
138.由此实施过程可知，本发明实施例不需要用户或应用服务器向支付端提供商户识别信息，使用同一个输入信息即可以触发不同的支付端完成数字资产的支付过程，从而简化了支付端的操作，提高了用户的使用体验。
139.三、一种用于双离线场景下的聚合支付方法实施例二
140.请参考图3，其示出了本发明提供的一种用于双离线场景下的聚合支付方法实施例二的流程图。本实施例以该方法应用于图1所示实施环境中的接收端来举例说明，该方法可以包括：
141.步骤301.在接收到支付端通过局域网络发送的支付请求时，获取预先设置的商户识别信息并且返回给所述支付端，以使得所述支付端在生成的离线支付凭证中包括所述预先设置的商户识别信息和相应的数字资产。
142.步骤302.提供多个验证接口，其中每个验证接口分别对应于所述多种双离线支付方式中一种支付方式的验证方式，并且若接收到所述离线支付凭证则调用该验证接口对应的验证方式以进行验证，在验证所述离线支付凭证合法之后，确定所述支付端支付成功。
143.其中，所述每种支付方式对应的验证方式包括：
144.商户验证方式，具体的，获取所述离线支付凭证中包括的商户识别信息，以及获取该种验证方式对应的商户识别信息，判断所述对应的商户识别信息与所述包括的商户识别信息是否一致，若一致，则确定验证通过；
145.若实施的验证方式都确定验证通过，则确定所述离线支付凭证合法。
146.由此实施过程可知，本发明实施例中接收端向支付端提供商户识别信息，从而使得支付端在生成的离线支付凭证中包括该商户识别信息，以及接收端提供多个验证接口，每个验证接口分别提供多种双离线支付方式中一种支付方式的验证方式，其中每个验证接口在接收到离线支付凭证时调用该验证接口对应的验证方式以进行验证，并且由于该离线支付凭证中包括的商户识别信息是接收端提供给支付端的，因此可以使得在使用商户验证方式进行验证时能验证通过，如此，可以使得在接收端上有效地整合多种双离线支付方式。
147.四、一种用于双离线场景下的聚合支付方法实施例三
148.请参考图4，其示出了本发明提供的一种用于双离线场景下的聚合支付方法实施例三的流程图。本实施例是结合了上述一种用于双离线场景下的聚合支付方法实施例一和实施例二所形成的实施例。本实施例以该方法应用于图1所示的实施环境来举例说明，该方法可以包括：
149.步骤401.支付端通过局域网络向接收端发送支付请求。
150.支付端通过局域网络向接收端发送支付请求，在实际实施过程中，可以有多种方式触发支付端通过局域网络向接收端发送支付请求。以在行驶的飞机等不能与互联网进行实时通信的环境内建立局域网络为例，例如，乘务员向乘客出示图形码，乘客使用支付端扫描及解析该图形码而触发支付端通过局域网络向接收端发送支付请求，可以理解，图形码可以是二维码或条形码，也可以是其它可以通过扫描及解码方式获取其信息的图形；又例如，接收端为在该局域网络内用于接收离线支付的服务器，应用服务器为在该局域网络内用于提供应用服务(如购物、观影)的服务器，乘客使用座位上安装的电脑终端访问应用服务器时触发购买相应的服务，应用服务器向电脑终端返回相应的服务信息(如购买相应服
务所需的支付数额等)，并且在电脑终端上根据该相应的服务信息显示图形码，则乘客使用支付端扫描及解析该图形码而触发支付端通过局域网络向接收端发送支付请求；还例如，乘客使用自己的移动终端接入该局域网络，在访问应用服务器时触发购买相应的服务，应用服务器向移动终端返回相应的服务信息，移动终端调用运行在移动终端上相应的支付端(如支付客户端程序)，并且通过本地进程间通信向该支付端传递该相应的服务信息，从而触发该支付端通过局域网络向接收端发送支付请求。
151.可选的，如果接收端提供对多个商户的支持，则在所述支付请求中还可以包括映射字符串，该映射字符串用于在接收端上映射相应商户的商户识别信息。可以理解，在上述图形码或相应的服务信息中，可以包括用于相应商户的映射字符串，从而使得支付端可以从上述图形码或相应的服务信息中获取该映射字符串，并且在所述支付请求中包括该映射字符串。
152.可以理解，在上述图形码或相应的服务信息中，还可以包括请求地址，以此使得支付端根据该请求地址通过局域网络向接收端发送所述支付请求。
153.可以理解，支付端可以是如图1所示的支付端一或支付端二，为了便于说明，本实施例仅以其中一个支付端为例进行说明。
154.相应地，接收端通过局域网络接收所述支付请求。
155.步骤402.接收端获取预先设置的商户识别信息。
156.商户识别信息主要用于在服务端确定数字资产划转时的接收账户，可以是终端设备标识、芯片卡标识、手机号码、账号、数字证书、公钥、基于公钥生成的地址或其他可用于在服务端唯一地确定接收账户的信息。
157.对于接收端聚合的多种双离线支付方式，接收端在每种支付方式对应的服务端上注册的商户识别信息，既可以相同，例如，接收端以手机号码在每种支付方式对应的服务端上分别注册账号，即该手机号码是该接收端在每种支付方式对应的服务端上的商户识别信息，亦即该接收端在每种支付方式对应的服务端上注册的商户识别信息相同；也可以不相同，例如，接收端在服务端一上的注册账号为“usera”，在服务端二上的注册账号为“userb”，即接收端在服务端一和服务端二上的商户识别信息分别为“usera”和“userb”。
158.接收端获取预先设置的商户识别信息，可以包括：
159.获取方式一，如果接收端在每种支付方式对应的服务端上注册的商户识别信息相同，即接收端在每种支付方式对应的服务端上注册的是相同的商户识别信息，并且接收端预先设置该相同的商户识别信息，则接收端获取该预先设置的商户识别信息。例如，该商户识别信息既是接收端在服务端一上用于确定接收账户的信息，也是接收端在服务端二上用于确定接收账户的信息，则接收端获取该商户识别信息并且返回给支付端。进一步的，接收端还可以提供对多个商户的支持，具体的，接收端预先建立映射字符串与商户识别信息的对应关系，如上述步骤401中所述，所述支付请求中还包括映射字符串，接收端根据该映射字符串通过该对应关系获取对应的商户识别信息，例如，接收端预先建立映射字符串一与商户识别信息“user1”的对应关系，以及建立映射字符串二与商户识别信息“user2”的对应关系，其中，商户识别信息“user1”为商户一在每种支付方式对应的服务端上注册的相同的商户识别信息，商户识别信息“user2”为商户二在每种支付方式对应的服务端上注册的相同的商户识别信息，当接收端从所述支付请求中获取的映射字符串为映射字符串一时，则
接收端通过对应关系获取的商户识别信息为商户识别信息“user1”，当接收端从所述支付请求中获取的映射字符串为映射字符串二时，则接收端通过对应关系获取的商户识别信息为商户识别信息“user2”。
160.获取方式二，如果接收端在每种支付方式对应的服务端上注册的商户识别信息不相同，并且接收端预先建立有支付识别信息与商户识别信息的对应关系，根据所述支付请求获取支付识别信息，并且根据该支付识别信息通过该对应关系获取对应的商户识别信息。例如，接收端建立支付识别信息“pay1”与商户识别信息“usera”的对应关系，以及建立支付识别信息“pay2”与商户识别信息“userb”的对应关系，其中，支付识别信息“pay1”为支付方式一的支付识别信息，支付识别信息“pay2”为支付方式二的支付识别信息，商户识别信息“usera”为接收端在服务端一上注册的商户识别信息，商户识别信息“userb”为接收端在服务端二上注册的商户识别信息，当接收端从所述支付请求中获取的支付识别信息为“pay1”时，则接收端根据该支付识别信息“pay1”通过对应关系获取的对应的商户识别信息为“usera”，当接收端从所述支付请求中获取的支付识别信息为“pay2”时，则接收端根据该支付识别信息“pay2”通过对应关系获取的对应的商户识别信息为“userb”。进一步的，接收端还可以提供对多个商户的支持，具体的，接收端预先建立支付识别信息、映射字符串与商户识别信息的对应关系，如上述步骤401中所述，在所述支付请求中还包括映射字符串，接收端根据所述支付识别信息和该映射字符串通过该对应关系获取对应的商户识别信息，例如，接收端预先建立映射字符串一、支付识别信息“pay1”与商户识别信息“user1a”的对应关系，以及建立映射字符串一、支付识别信息“pay2”与商户识别信息“user1b”的对应关系，其中，商户识别信息“user1a”为商户一在服务端一上注册的商户识别信息，商户识别信息“user1b”为商户一在服务端二上注册的商户识别信息，当接收端从所述支付请求中获取到映射字符串一和支付识别信息“pay1”时，则接收端根据映射字符串一和支付识别信息“pay1”通过对应关系获取到的对应的商户识别信息为“user1a”，当接收端从所述支付请求中获取到映射字符串一和支付识别信息“pay2”时，则接收端根据映射字符串一和支付识别信息“pay2”通过对应关系获取到的对应的商户识别信息为“user1b”；如此，接收端还可以为商户二预先建立映射字符串二、支付识别信息“pay1”与商户识别信息“user2a”的对应关系，以及建立映射字符串二、支付识别信息“pay2”与商户识别信息“user2b”的对应关系,其中，商户识别信息“user2a”为商户二在服务端一上注册的商户识别信息，商户识别信息“user2b”为商户二在服务端二上注册的商户识别信息等，依此类推，在此不再赘述。
161.支付识别信息是指可用于标识支付方式的识别信息，例如，对于支付方式一和支付方式二，可以通过支付识别信息“pay1”和“pay2”分别标识支付方式一和支付方式二。上述接收端根据所述支付请求获取支付识别信息，可以包括多种实施方式，具体可以包括：
162.例如，所述支付请求中包括所述支付端的支付识别信息，从所述支付请求中获取所述支付识别信息。具体的，支付端在发送的所述支付请求中包括该支付端的支付识别信息，则接收端从所述支付请求中获取该支付识别信息，比如，支付端一在发送的支付请求中包括的支付识别信息为支付识别信息一，支付端二在发送的支付请求中包括的支付识别信息为支付识别信息二，则如果所述支付请求是支付端一发送的，则接收端从所述支付请求中获取的支付识别信息为支付识别信息一，如果所述支付请求是支付端二发送的，则接收端从所述支付请求中获取的支付识别信息为支付识别信息二。
163.又例如，支付端在通过局域网络发送所述支付请求时还携带有支付端的客户端识别信息，则接收端根据该客户端识别信息获取所述支付识别信息，比如，useragent(用户代理)是在浏览器等客户端中携带的一种客户端识别信息，能够识别客户端所使用的操作系统及版本、cpu类型、浏览器及版本、浏览器语言、浏览器插件等，以支付宝为例，在支付宝客户端携带的客户端识别信息(useragent)中包含了“alipayclient”，则接收端获取该“alipayclient”为所述支付识别信息，以微信支付为例，在微信客户端携带的客户端识别信息(useragent)中包含了“micromessenger”，则接收端获取该“micromessenger”为所述支付识别信息。
164.进一步的，接收端还可以根据所述支付识别信息获取对应的验证接口地址，具体的，接收端建立支付识别信息与验证接口地址(如url地址)的对应关系，接收端根据所述支付识别信息通过该对应关系获取对应的验证接口地址，例如，接收端上建立的支付识别信息与验证接口地址的对应关系包括支付识别信息一与第一url地址的对应关系，以及包括支付识别信息二与第二url地址的对应关系，因此，如果接收端获取的所述支付识别信息为支付识别信息一，则获取的验证接口地址为第一url地址，如果接收端获取的所述支付识别信息为支付识别信息二，则获取的验证接口地址为第二url地址。
165.步骤403.接收端向支付端返回所述预先设置的商户识别信息。
166.接收端将所述预先设置的商户识别信息返回给支付端，以使得支付端在生成的离线支付凭证中包括所述预先设置的商户识别信息。
167.进一步的，接收端将所述验证接口地址返回给支付端，以使得支付端根据所述验证接口地址将生成的离线支付凭证发送给对应的验证接口。
168.相应地，支付端接收接收端返回的所述预先设置的商户识别信息，进一步的，还包括接收接收端返回的所述验证接口地址。
169.步骤404.支付端生成离线支付凭证，所述离线支付凭证中包括所述预先设置的商户识别信息和相应的数字资产。
170.支付端生成离线支付凭证，所述离线支付凭证包括所述预先设置的商户识别信息和相应的数字资产。
171.所述离线支付凭证中包括的相应的数字资产，是支付端支付给接收端的数字资产，在支付端确定要支付给接收端的支付数额之后，支付端根据该支付数额在生成的离线支付凭证中包括相应的数字资产。例如，本发明实施例中的数字资产可以是余额形式的数字资产，假设支付端确定要支付给接收端的支付数额为20，相当于支付端要支付给接收端相应的数字资产为20，则支付端在生成的离线支付凭证中包括20；又例如，本发明实施例中的数字资产还可以是字符串形式的数字资产，以数字货币为例，每个不同的加密字符串分别表示对应的数字货币，假设支付端确定要支付给接收端的支付数额为20，则支付端从支付端当前可用的数字资产中选取面值为20的加密字符串为所述相应的数字资产，或者选取面值总和为20的多个加密字符串为所述相应的数字资产，并且在支付端生成的离线支付凭证中包括该选取的一个或多个加密字符串。
172.可以理解，支付端确定要支付给接收端的支付数额，可以是用户输入的，例如支付端的用户在支付端的操作界面上输入支付数额；也可以是应用服务器传递的，例如在应用服务器返回的服务信息中包括购买相应服务所需的支付数额；还可以是接收端传递的，例
如在接收端向支付端返回所述预先设置的商户识别信息时，还包括返回支付端所需支付的支付数额等。
173.在所述离线支付凭证中包括所述预先设置的商户识别信息，将用于接收端验证所述离线支付凭证的合法性，进一步的，还可以在所述离线支付凭证中包括签名值等，以此使得接收端可以根据该签名值验证所述离线支付凭证的合法性。
174.具体的，为了防止离线支付凭证被篡改，支付端还可以对所述离线支付凭证中的关键信息进行数字签名以生成签名值，即所述离线支付凭证中还可以包括所述签名值，即支付端对待签名信息进行数字签名以生成签名值，所述待签名信息包括所述离线支付凭证中相应的数字资产，进一步的，所述待签名信息还可以包括商户识别信息等信息。
175.可以理解，数字签名是指附加在数据单元上的数据，或是对数据单元所作的密码变换，这种数据或变换允许数据单元的验证方(如接收端或服务端)用以确认数据单元的来源和完整性，并保护数据防止被伪造或抵赖。
176.在数字签名的一种实现方式中，使用非对称加密算法进行数字签名以生成所述签名值，例如，支付端使用哈希算法对所述待签名信息进行哈希计算得到哈希值(即信息摘要)，支付端使用支付端的私钥对该哈希值加密得到加密结果(即签名值)。
177.上述步骤401至404，是支付端获取商户识别信息至在生成的离线支付凭证中包括该商户识别信息的过程，对于支付端而言，不需要用户或应用服务器向支付端提供商户识别信息，而且使用同一个输入信息即可以触发不同的支付端完成该过程，从而简化了支付端的操作，提高了用户的使用体验，例如，可以通过提供同一个图形码给不同的支付端以完成该过程，不需要分别向支付端一提供图形码一、又向支付端二提供图形码二以完成该过程；又例如，可以通过同一服务信息触发不同的支付端以完成该过程，不需要分别向不同的支付端提供不同的服务信息以触发完成该过程。
178.步骤405.支付端通过局域网络向接收端对应的验证接口发送所述离线支付凭证。
179.支付端通过局域网络向接收端对应的验证接口发送所述离线支付凭证，该对应的验证接口是指对应于该支付端的验证接口。例如，支付端一在接收端上对应的验证接口为验证接口一，即接收端上的验证接口一为用于接收支付端一发送的离线支付凭证的验证接口；支付端二在接收端上对应的验证接口为验证接口二，即接收端上的验证接口二为用于接收支付端二发送的离线支付凭证的验证接口；又例如，支付宝客户端在接收端上对应的验证接口为支付宝验证接口，即接收端上的支付宝验证接口为用于接收支付宝客户端发送的离线支付凭证的验证接口；微信客户端在接收端上对应的验证接口为微信支付验证接口，即接收端上的微信支付验证接口为用于接收微信客户端发送的离线支付凭证的验证接口。
180.具体的，支付端通过局域网络向接收端对应的验证接口发送所述离线支付凭证，其中，所述对应的验证接口的地址，可以是预置在支付端内，则支付端可以根据该预置的验证接口地址将所述离线支付凭证发送给对应的验证接口，例如，支付端一预置的验证接口地址为地址一，该地址一是接收端上验证接口一的地址，支付端二预置的验证接口地址为地址二，该地址二是接收端上验证接口二的地址，如此，如果支付端为支付端一，则根据预置的验证接口地址(即地址一)会将所述离线支付凭证发送给验证接口一，如果支付端为支付端二，则根据预置的验证接口地址(即地址二)会将所述离线支付凭证发送给验证接口
二；所述对应的验证接口的地址，也可以是如上述步骤403至步骤404中所述，接收端将所述验证接口地址返回给支付端，则支付端根据该验证接口地址将所述离线支付凭证发送给对应的验证接口，例如，如果支付端为支付端一，则在上述步骤403至步骤404中，支付端从接收端接收的所述验证接口地址为第一url地址，该第一url地址为接收端上验证接口一的地址，则支付端根据该第一url地址会将所述离线支付凭证发送给验证接口一，如果支付端为支付端二，则在上述步骤403至步骤404中，支付端从接收端接收的所述验证接口地址为第二url地址，该第二url地址为接收端上验证接口二的地址，则支付端根据该第二url地址会将所述离线支付凭证发送给验证接口二。
181.相应的，接收端通过所述对应的验证接口接收及获取支付端发送的所述离线支付凭证。
182.步骤406.接收端上所述对应的验证接口在接收到所述离线支付凭证时调用所述对应的验证接口对应的验证方式以进行验证。
183.本发明实施例中的接收端用于聚合多种双离线支付方式，其中每种支付方式有每种支付方式对应的验证方式。验证方式是指对离线支付凭证进行离线验证的验证方式，由于每种支付方式所生成的离线支付凭证存在相应的区别，因此，每种支付方式有每种支付方式对应的验证方式。可以理解，每种支付方式的支付端生成的离线支付凭证对应的支付方式属于该种支付方式，例如，支付端一生成的离线支付凭证对应的支付方式为支付方式一，支付端二生成的离线支付凭证对应的支付方式为支付方式二。
184.接收端提供多个验证接口，其中每个验证接口分别对应于所述多种双离线支付方式中一种支付方式的验证方式，并且若接收到所述离线支付凭证则调用该验证接口对应的验证方式以进行验证，即每个验证接口在接收到离线支付凭证时，调用该验证接口对应的验证方式对该离线支付凭证进行验证。例如，接收端提供验证接口一和验证接口二，其中，所述验证接口一对应于第一种验证方式，并且若接收到所述离线支付凭证则调用该第一种验证方式以进行验证，该第一种验证方式为对支付方式一的离线支付凭证进行验证的验证方式，所述验证接口二对应于第二种验证方式，并且若接收到所述离线支付凭证则调用该第二种验证方式以进行验证，该第二种验证方式为对支付方式二的离线支付凭证进行验证的验证方式；又例如，以支付宝支付和微信支付为例，接收端提供支付宝验证接口和微信支付验证接口，当支付宝验证接口接收到离线支付凭证时，则调用支付宝的验证方式对该离线支付凭证进行验证，当微信支付验证接口接收到离线支付凭证时，则调用微信支付的验证方式对该离线支付凭证进行验证。
185.可以理解，本发明实施例中的验证接口，是指接收端用于与支付端通过网络进行数据交互的接口，接收端通过验证接口接收支付端发送的离线支付凭证，并且调用该验证接口对应的验证方式对接收的离线支付凭证进行验证。例如，接收端提供多个url(uniform resource locator,统一资源定位器)地址，每个url地址用于不同的验证接口，如此，则支付端根据url地址向对应的验证接口发送所述离线支付凭证；又例如，在上述步骤402至步骤403中，接收端根据所述支付识别信息获取到对应的url地址并且返回给支付端，在上述步骤405中，支付端根据该url地址向对应的验证接口发送所述离线支付凭证。
186.可以理解，接收端通过所述对应的验证接口在接收到所述离线支付凭证时调用所述对应的验证接口对应的验证方式以进行验证，还可以是在接收到所述离线支付凭证时调
用所述对应的验证接口对应的验证sdk以进行验证。具体的，每种支付方式发布对自己支付方式的离线支付验证sdk(开发工具包)，每个验证接口对应的验证方式为调用该验证接口对应的验证sdk以进行实现，例如微信支付发布用于微信离线支付凭证的验证sdk，支付宝发布用于支付宝离线支付凭证的验证sdk，则在接收端上集成该多种验证sdk，微信支付验证接口对应的验证方式为调用微信离线支付凭证的验证sdk以进行实现，支付宝支付验证接口对应的验证方式为调用支付宝离线支付凭证的验证sdk以实现。
187.具体的，每种支付方式对应的验证方式可以包括多种具体的验证方式，其中可以包括：
188.商户验证方式，获取所述离线支付凭证中包括的商户识别信息，以及获取该种验证方式对应的商户识别信息，判断该对应的商户识别信息与所述包括的商户识别信息是否一致，若一致，则确定验证通过。
189.具体的，对于要验证的离线支付凭证，该离线支付凭证中包括商户识别信息，如上述步骤404中所述，在生成的所述离线支付凭证中包括所述预先设置的商户识别信息，由此，接收端获取所述包括的商户识别信息，也可以理解为获取所述离线支付凭证中包括的商户识别信息，以及获取该种验证方式对应的商户识别信息，接收端将该对应的商户识别信息与所述包括的商户识别信息进行比较，若二者一致，则表明所述离线支付凭证是属于发送给该接收端的离线支付凭证，而不是用于发送给其他接收端的离线支付凭证，确定验证通过；否则，则表明所述离线支付凭证不是发送给该接收端的离线支付凭证，确定验证不通过。
190.可以理解，实际实施过程中，对应的商户识别信息可以不限于一个，也可以包括多个商户识别信息，如此，可以将该多个商户识别信息与所述包括的商户识别信息进行比较，如果有任意一个商户识别信息与所述包括的商户识别信息相一致，则确定验证通过。进一步的，还可以对商户识别信息确定相应的类型，则还可以从该多个商户识别信息中确定与所述包括的商户识别信息的类型相一致的商户识别信息，再将两者进行比较等。
191.上述获取该种验证方式对应的商户识别信息，可以包括多种实施方式：
192.例如，如果接收端在每种支付方式对应的服务端上注册的商户识别信息相同，则接收端预先设置该相同的商户识别信息，获取该预先设置的商户识别信息为所述对应的商户识别信息。
193.又例如，如果接收端在每种支付方式对应的服务端上注册的商户识别信息不相同，则每种支付方式对应的验证方式设置对应的商户识别信息，以此使得每种支付方式对应的验证方式获取该种验证方式对应的商户识别信息为所述对应的商户识别信息。例如，第一种验证方式预先设置对应的商户识别信息为“usera”，第二种验证方式预先设置对应的商户识别信息为“userb”，其中，商户识别信息“usera”为接收端在服务端一上注册的商户识别信息，商户识别信息“userb”为接收端在服务端二上注册的商户识别信息，则如果是验证接口一调用第一种验证方式对接收的离线支付凭证进行验证，则第一种验证方式获取的对应的商户识别信息为“usera”，如果是验证接口二调用第二种验证方式对接收的离线支付凭证进行验证，则第二种验证方式获取的对应的商户识别信息为“userb”。
194.可以理解，上述步骤402中接收端获取预先设置的商户识别信息，则该获取的预先设置的商户识别信息与本步骤中获取的该种验证方式对应的商户识别信息应当是一致的，
如此才可以使得判断所述对应的商户识别信息与所述包括的商户识别信息是一致的。
195.进一步的，每种支付方式对应的验证方式还可以包括对应的数字签名验证方式，具体的，所述离线支付凭证中包括签名值，所述签名值为所述支付端对待签名信息进行数字签名生成的签名值，所述待签名信息包括所述相应的数字资产，使用该对应的数字签名验证方式根据所述签名值对所述离线支付凭证进行数字签名验证。
196.如上述步骤401中所述，支付端还可以对待签名信息进行数字签名以生成签名值，即所述离线支付凭证中包括签名值，则每种支付方式对应的验证方式还可以包括对应的数字签名验证方式，使用该对应的数字签名验证方式根据所述签名值对所述离线支付凭证进行数字签名验证。
197.可以理解，由于每种支付方式在数字签名的验证方式上可能存在的不同，例如数字签名验证相关的加密算法、待校验信息的生成方式、公钥、根证书和公共参数等都可能存在不同，因此，每种支付方式对应的验证方式中包括的对应的数字签名验证方式，其中包括的数字签名验证相关的加密算法、或/和待校验信息生成方式、或/和公钥、或/和根证书、或/和公共参数等都是与该种支付方式对应的，从而使得可以对所述离线支付凭证进行数字签名验证。例如，第一种验证方式对应的数字签名验证方式为第一种数字签名验证方式，该第一种数字签名验证方式中包括的数字签名验证相关的加密算法、或/和待校验信息生成方式、或/和公钥、或/和根证书、或/和公共参数等都是与支付方式一的数字签名方式相对应的，亦即是与支付端一在生成所述离线支付凭证的数字签名方式是相对应的，第二种验证方式对应的数字签名验证方式为第二种数字签名验证方式，该第二种数字签名验证方式中包括的数字签名验证相关的加密算法、或/和待校验信息生成方式、或/和公钥、或/和根证书、或/和公共参数等都是与支付方式二的数字签名方式相对应的，亦即是与支付端二在生成所述离线支付凭证的数字签名方式是相对应的。
198.具体的，对于待验证的离线支付凭证，该离线支付凭证中包括签名值，如上述步骤404中所述，在生成的所述离线支付凭证中还包括签名值，相应的，该对应的数字签名验证方式包括：
199.生成待校验信息，并且生成方式与支付端生成待签名信息的生成方式相同，从而使得该生成的待校验信息与支付端生成的待签名信息相同。可以理解，该生成的待校验信息至少包括所述相应的数字资产，如果支付端生成的待签名信息中还包括所述商户识别信息或/和其他的信息，则该生成的待校验信息中也包括所述商户识别信息或/和相同的其他信息，从而使得该生成的待校验信息与支付端生成的待签名信息相同；
200.获取所述支付端的公钥，并且使用该公钥解密所述签名值得到解密结果(即信息摘要)，并且使用相同的哈希算法对所述待校验信息进行哈希计算得到哈希值(即校验值)，比较该解密结果(即信息摘要)与该校验值是否相同，若相同，则确定数字签名验证通过，否则，则确定验证不通过。
201.可以有多种方式获取支付端的公钥，例如，当支付端基于ibc(identity
‑
based cryptograph)产生的私钥对所述待签名信息进行数字签名，并且以支付端识别信息作为支付端的公钥时，在所述离线支付凭证中包括该支付端识别信息，则接收端获取该支付端识别信息作为支付端的公钥；又例如，当支付端基于pki(public key infrastructure)体系产生的私钥对所述待签名信息进行数字签名时，支付端可以在向接收端发送所述离线支付
凭证时还包括发送支付端的数字证书，如此接收端从该数字证书中获取支付端的公钥，可以理解，实际应用过程中，还应当使用预置的根证书验证该支付端的数字证书是否合法。
202.可以理解，对于上述每种支付方式对应的验证方式，只有实施的验证方式都确定验证通过，才确定所述离线支付凭证合法，否则，若任一验证方式为验证不通过，则确定所述离线支付凭证不合法。可以理解，当某支付方式对应的验证方式只实施上述商户验证方式时，若该商户验证方式确定验证通过，则确定所述离线支付凭证合法，否则，若该商户验证方式验证不通过，则确定所述离线支付凭证不合法。也可以理解，当某支付方式对应的验证方式同时实施上述商户验证方式和数字签名验证方式时，只有商户验证方式和数字签名验证方式都确定验证通过，才确定所述离线支付凭证合法，否则，若商户验证方式或数字签名验证方式为验证不通过，则确定所述离线支付凭证不合法。
203.步骤407.在所述对应的验证方式验证所述离线支付凭证合法之后，确定所述支付端支付成功。
204.在接收端上所述对应的验证方式验证所述离线支付凭证合法之后，则确定所述支付端支付成功，也可以理解为认可该次支付。以行驶的飞机为例，例如，在确定支付端支付成功之后，则乘务员可以为支付成功的乘客提供相应的商品或服务；又例如，支付端在访问应用服务器时触发购买相应的服务，并且向接收端发送所述离线支付凭证，则接收端在确定支付端支付成功之后，向应用服务器反馈表示支付成功的信息，则应用服务器确定支付端购买成功，并且向支付端提供该相应的服务。
205.可选的，接收端将所述离线支付凭证发送给所述对应的验证方式所对应的服务端，以使得所述对应的服务端根据所述离线支付凭证进行数字资产的划转。
206.接收端将所述离线支付凭证发送给所述对应的验证方式所对应的服务端，例如，第一种验证方式对应的服务端为服务端一，第二种验证方式对应的服务端为服务端二，如果是验证接口一调用第一种验证方式对接收的离线支付凭证进行验证，则将所述离线支付凭证发送给该第一种验证方式所对应的服务端(即服务端一)，如果是验证接口二调用第二种验证方式对接收的离线支付凭证进行验证，则将所述离线支付凭证发送给该第二种验证方式所对应的服务端(即服务端二)。
207.接收端将所述离线支付凭证发送给所述对应的服务端，既可以由接收端与服务端建立网络连接，由接收端直接将所述离线支付凭证发送给所述对应的服务端，例如，以行驶的飞机为例，在飞机落地之后，接收端接入移动互联网并与所述对应的服务端建立网络连接，由接收端将所述离线支付凭证发送给所述对应的服务端；也可以由接收端间接地将所述离线支付凭证发送给所述对应的服务端，即接收端通过中转设备(如收款服务器等收款设备)将所述离线支付凭证发送给所述对应的服务端，例如，在飞机上部署有收款设备，接收端将所述离线支付凭证同步给收款设备，当飞机落地之后，收款设备与所述对应的服务端建立网络连接，收款设备将所述离线支付凭证发送给所述对应的服务端；又例如，在飞机落地之后，接收端接入移动互联网并与航空公司的收款服务器建立网络连接，接收端将所述离线支付凭证同步给该收款服务器，该收款服务器将所述离线支付凭证通过网络发送给所述对应的服务端。
208.在接收端将所述离线支付凭证发送给所述对应的服务端之后，则所述对应的服务端可以根据所述离线支付凭证进行数字资产的划转，具体的，所述对应的服务端将所述相
应的数字资产划转给所述离线支付凭证中包括的商户识别信息所在的账户。
209.上述实施过程，接收端提供多个验证接口，每个验证接口分别提供多种双离线支付方式中一种支付方式的验证方式，其中每个验证接口在接收到离线支付凭证时调用该验证接口对应的验证方式以进行验证，其中，该离线支付凭证中包括的商户识别信息是接收端向支付端提供的，从而使得支付端在生成的该离线支付凭证中包括该商户识别信息，进而使得该离线支付凭证通过接收端的验证。由此实施过程可知，本发明实施例所产生的技术效果，在双离线场景下，对于接收端而言，可以整合多种双离线支付方式；对于支付端而言，不需要用户或应用服务器向支付端提供商户识别信息，使用同一个输入信息即可以触发不同的支付端完成数字资产的支付过程，从而简化了支付端的操作，提高了用户的使用体验。
210.五、一种用于双离线场景下的聚合支付装置实施例一
211.请参考图5，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例一的结构示意图。为了便于说明，仅示出了与本发明实施例相关的部份。所述装置包括：
212.接收模块：用于接收支付端通过局域网络发送的支付请求；
213.商户获取模块，用于获取预先设置的商户识别信息；
214.返回模块，用于将所述预先设置的商户识别信息返回给所述支付端，以使得所述支付端在生成的离线支付凭证中包括所述预先设置的商户识别信息和相应的数字资产；
215.验证接口一，用于接收支付方式为支付方式一的离线支付凭证，并且在接收到所述支付方式一的离线支付凭证时调用验证模块一以进行验证；可以理解，支付端一生成的离线支付凭证对应的支付方式为支付方式一，即所述支付方式一的离线支付凭证为支付端一所生成的离线支付凭证；
216.所述验证模块一，用于对所述支付方式一的离线支付凭证进行验证，其中包括商户验证单元一，具体的，所述支付方式一的离线支付凭证中包括商户识别信息，所述商户验证单元一用于获取该包括的商户识别信息，以及获取对应的商户识别信息，判断该对应的商户识别信息与该包括的商户识别信息是否一致，若一致，则确定验证通过，并且当所述验证模块一包括的验证单元在执行时都确定验证通过，则确定所述支付方式一的离线支付凭证合法；
217.验证接口二，用于接收支付方式为支付方式二的离线支付凭证，并且在接收到所述支付方式二的离线支付凭证时调用验证模块二以进行验证；可以理解，支付端二生成的离线支付凭证对应的支付方式为支付方式二，即所述支付方式二的离线支付凭证为支付端二所生成的离线支付凭证；
218.所述验证模块二，用于对所述支付方式二的离线支付凭证进行验证，其中包括商户验证单元二，具体的，所述支付方式二的离线支付凭证中包括商户识别信息，所述商户验证单元二用于获取该包括的商户识别信息，以及获取对应的商户识别信息，判断该对应的商户识别信息与该包括的商户识别信息是否一致，若一致，则确定验证通过，并且当所述验证模块二包括的验证单元在执行时都确定验证通过，则确定所述支付方式二的离线支付凭证合法；
219.接受模块，用于在所述验证模块一或所述验证模块二确定离线支付凭证合法之后，确定所述支付端支付成功。
220.六、一种用于双离线场景下的聚合支付装置实施例二
221.请参考图6，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例二的结构示意图，该装置是在上述一种用于双离线场景下的聚合支付装置实施例一提供的装置上，所述验证模块一还包括签名验证单元一，或/和，所述验证模块二还包括签名验证单元二，其中：
222.所述签名验证单元一，用于若所述离线支付凭证还包括签名值，该签名值为支付端一对待签名信息进行数字签名生成的签名值，该待签名信息包括所述相应的数字资产，则根据该签名值对所述离线支付凭证进行数字签名验证，其中，该数字签名验证的验证方式为所述支付方式一所对应的数字签名验证方式，所述支付端一为所述支付方式一的支付端；
223.所述签名验证单元二，用于若所述离线支付凭证还包括签名值，该签名值为支付端二对待签名信息进行数字签名生成的签名值，该待签名信息包括所述相应的数字资产，则根据该签名值对所述离线支付凭证进行数字签名验证，其中，该数字签名验证的验证方式为所述支付方式二所对应的数字签名验证方式，所述支付端二为所述支付方式二的支付端。
224.可以理解，实际实施过程中，所述验证模块一中还包括所述签名验证单元一，以及所述验证模块二中还包括所述签名验证单元二，既可以同时实施，也可以选用其中一个进行实施，即所述验证模块一还包括签名验证单元一，或/和，所述验证模块二还包括签名验证单元二。
225.七、一种用于双离线场景下的聚合支付装置实施例三
226.对于上述一种用于双离线场景下的聚合支付装置实施例一所提供的装置，若所述接收端在所述支付方式一和所述支付方式二对应的服务端上注册的是相同的商户识别信息，则该装置还可以包括存储单元一。
227.请参考图7，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例三的结构示意图，该结构示意图中所述装置还包括所述存储单元二，其中：
228.所述存储单元一用于预先存储所述相同的商户识别信息；
229.所述商户获取模块中所述获取预先设置的商户识别信息包括：从所述存储单元一中获取所述相同的商户识别信息；
230.所述商户获取单元一中所述获取对应的商户识别信息包括：从所述存储单元一中获取所述相同的商户识别信息；
231.所述商户获取单元二中所述获取对应的商户识别信息包括：从所述存储单元一中获取所述相同的商户识别信息。
232.八、一种用于双离线场景下的聚合支付装置实施例四
233.对于上述一种用于双离线场景下的聚合支付装置实施例一所提供的装置，若所述接收端在所述支付方式一和所述支付方式二对应的服务端上注册的是不相同的商户识别信息，其中，所述接收端在所述支付方式一对应的服务端上注册的商户识别信息为商户识别信息一，所述接收端在所述支付方式二对应的服务端上注册的商户识别信息为商户识别信息二，则所述装置还可以包括存储单元二、存储单元三和存储单元四。
234.请参考图8，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施
例四的结构示意图，该结构示意图中所述装置还包括所述存储单元二、所述存储单元三和所述存储单元四，其中：
235.所述存储单元二用于预先存储支付识别信息与商户识别信息的对应关系，其中包括存储支付识别信息一与所述商户识别信息一的对应关系，以及存储支付识别信息二与所述商户识别信息二的对应关系；
236.所述商户获取模块中所述获取预先设置的商户识别信息包括：根据所述支付请求获取支付识别信息，并且根据所述支付识别信息在所述存储单元二中通过该对应关系获取对应的商户识别信息，其中包括，当所述支付识别信息为所述支付识别信息一时，则获取的商户识别信息为所述商户识别信息一，当所述支付识别信息为所述支付识别信息二时，则获取的商户识别信息为所述商户识别信息二；
237.所述存储单元三用于存储所述商户识别信息一；
238.所述商户验证单元一中所述获取对应的商户识别信息包括：从所述存储单元三中获取所述商户识别信息一；
239.所述存储单元四用于存储所述商户识别信息二；
240.所述商户验证单元二中所述获取对应的商户识别信息包括：从所述存储单元四中获取所述商户识别信息二。
241.九、一种用于双离线场景下的聚合支付装置实施例五
242.请参考图9，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例五的结构示意图。该装置在上述一种用于双离线场景下的聚合支付装置实施例一提供的装置上，还包括如下模块：
243.获取识别模块，用于根据所述支付请求获取支付识别信息；
244.地址获取模块，用于根据所述支付识别信息获取对应的验证接口地址，并且将所述验证接口地址返回给所述支付端，以使得所述支付端根据所述验证接口地址将生成的所述离线支付凭证发送给对应的验证接口。
245.优选的，所述获取识别模块包括：
246.获取识别单元一，用于从所述支付请求中获取所述支付识别信息，所述支付请求中包括所述支付端的支付识别信息；或者，
247.获取识别单元二，用于根据所述支付端在发送所述支付请求时携带的客户端识别信息获取所述支付识别信息。
248.可以理解，在上述一种用于双离线场景下的聚合支付装置实施例四中，所述商户获取模块在根据所述支付请求获取支付识别信息时，也可以调用所述获取识别模块以根据所述支付请求获取支付识别信息。
249.上述一种用于双离线场景下的聚合支付装置实施例五还可以与上述一种用于双离线场景下的聚合支付装置实施例一至实施例四中的任一实施例组成可选的实施例，即上述一种用于双离线场景下的聚合支付装置实施例一至实施例四中的任一实施例还可以包括所述获取识别模块和所述地址获取模块。
250.十、一种用于双离线场景下的聚合支付装置实施例六
251.请参考图10，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例六的结构示意图。该装置在上述一种用于双离线场景下的聚合支付装置实施例一提供的
装置上，还包括如下模块：
252.发送模块，用于在所述接受模块确定所述支付端支付成功之后，将确定合法的离线支付凭证发送给验证该离线支付凭证的验证模块所对应的服务端，以使得所述对应的服务端根据该离线支付凭证进行数字资产的划转，其中具体包括，对于所述验证模块一确定合法的离线支付凭证，将该离线支付凭证发送给服务端一，对于所述验证模块二确定合法的离线支付凭证，将该离线支付凭证发送给服务端二。
253.具体的，如果验证离线支付凭证的验证模块为所述验证模块一，由于所述验证模块一是用于对所述支付方式一的离线支付凭证进行验证的验证模块，其对应的服务端为服务端一，则将所述验证模块一确定合法的离线支付凭证发送给服务端一；如果验证离线支付凭证的验证模块为所述验证模块二，由于所述验证模块二是用于对所述支付方式二的离线支付凭证进行验证的验证模块，其对应的服务端为服务端二，则将所述验证模块二确定合法的离线支付凭证发送给服务端二。
254.上述一种用于双离线场景下的聚合支付装置实施例六还可以与上述一种用于双离线场景下的聚合支付装置实施例一至实施例五中的任一实施例组成可选的实施例，即上述一种用于双离线场景下的聚合支付装置实施例一至实施例五中的任一实施例还可以包括所述发送模块。
255.上述一种用于双离线场景下的聚合支付装置实施例一至实施例六提供的装置与上述一种一种用于双离线场景下的聚合支付方法实施例三中应用于接收端的实施过程属于同一构思，其具体实现原理和效果可详见方法实施例，在此不再赘述。
256.需要说明的是，在本文中，术语“包括”、“包含”、“传递”、“发送”或者任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者系统不仅包括那些要素，而且还可以包括没有明确列出的其他要素，或者是还可以包括为这种过程、方法、产品或者系统所固有的要素。
257.术语“第一”、“第二”、“第三”等(如果存在)仅用于将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。应该理解，这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。
258.上述本发明的各实施例序号仅仅为了描述，不代表实施例的优劣。
259.可以以许多方式来实现本发明的方法、装置、接收端及支付端。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法、装置、接收端及支付端。用于方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。
260.以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。