一种离线支付额度的控制方法、支付端、接收端、服务端及系统与流程

一种离线支付额度的控制方法、支付端、接收端、服务端及系统
【技术领域】
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.接收及获取所述支付端传递的所述第二到期时间；或者，
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.第五方面，一种系统，所述系统包括支付端设备、接收端设备以及服务端设备，其中，所述支付端设备包括如上第四方面所述的支付端设备，所述接收端设备包括如上第四方面所述的接收端设备，所述服务端设备包括如上第四方面所述的服务端设备。
113.综上所述，本发明提供的技术方案可带来的技术效果至少包括：第一，由于在服务端上存储了支付端的离线支付额度，并且根据离线支付凭证从其中扣减支付数额，因此，在服务端上可以获知支付端的离线支付额度的使用情况，例如可以获知离线支付额度的余额、扣减记录等；第二，一旦在支付端发生离线支付额度丢失的情况，由于在一定时间之后(即第一到期时间之后)，服务端会将相应存储的离线支付额度进行释放，从而可以避免服
务端上存储的离线支付额度一直得不到扣减的问题；第三，不但可以解决支付端发生离线支付额度丢失的问题，而且由于服务端可以不将存储的离线支付额度重新下发给支付端，因此可以避免支付端通过重复获取服务端存储的离线支付额度而导致其超过实际支付限额的情况；第四，进一步的，当服务端在下发离线支付额度时，还包括下发签名值，该签名值可以作为支付端验证该离线支付额度是否合法的验证信息，以及该签名值可以作为接收端验证离线支付凭证是否合法的验证信息；第五，进一步的，可以限制支付端需在限定的时间内(即第二到期时间之前)根据本地保存的离线支付额度进行离线支付，否则，将不能进行离线支付；第六，进一步的，可以限制接收端需在限定的时间内(即第一到期时间之前)及时地将离线支付凭证发送给服务端，否则，如果服务端在第一到期时间之后接收到离线支付凭证，则会确定该离线支付凭证不合法。
【附图说明】
114.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
115.图1是本发明所涉及的一种实施环境的结构示意图；
116.图2是一种离线支付额度的控制方法实施例一的流程图；
117.图3是一种离线支付额度的控制方法实施例二的流程图；
118.图4是一种离线支付额度的控制方法实施例三的流程图；
119.图5是一种离线支付额度的控制方法实施例四的流程图。
120.本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
【具体实施方式】
121.为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
122.一、实施环境说明
123.请参考图1，其示出了本发明所涉及的一种实施环境的结构示意图。该实施环境包括支付端、接收端和服务端，其中：
124.支付端：数字资产的支付端，用于向接收端进行离线支付。支付端既可以是软件程序，例如支付客户端程序；也可以是由软件和硬件组合实现的设备，例如，既可以是智能手机、智能电视、平板电脑、笔记本电脑等用户终端设备，也可以是智能手表、智能手环等可穿戴式终端设备，还可以是诸如芯片卡、硬件钱包等其他设备。
125.接收端：数字资产的接收端，用于接收支付端的离线支付，并且根据支付端提供的离线支付凭证向服务端请求完成数字资产的划转。接收端既可以是软件程序，也可以是由软件和硬件组合实现的设备，例如，既可以是智能手机、销售终端(pos机)、扫描枪、读码器、pc(个人电脑)、服务器等设备，也可以是智能电视、平板电脑、笔记本电脑、智能手表、智能手环等终端设备，还可以是诸如芯片卡、硬件钱包等其他设备。
126.服务端：数字资产的服务端，用于向支付端提供离线支付额度，以及向接收端提供数字资产划转服务，根据接收端传递的离线支付凭证完成数字资产在服务端的划转。实际实施过程中，服务端可以是用于提供数字资产服务的登记中心、支付中心等。服务端可以是一个物理或逻辑服务器，也可以是云服务器，还可以是由两个或两个以上分担不同职责的服务器相互协同来实现本说明书各实施例中服务端的各项功能。
127.支付端与接收端之间的信息传递通过本地通信以实现，本地通信是相对与数字资产服务端的通信方式而言的，即支付端与接收端之间不需经过数字资产服务端以实现相互的信息传递，例如可以包括局域网或近距离通信等方式，其中，近距离通信包括但不限于通过蓝牙、红外线、nfc、wifi、声波、ble(低功耗蓝牙)或图形码的通信方式。例如，在支付端和接收端不能与互联网实时通信的环境下，在该环境内建立局域网络，支付端和接收端接入该局域网络，支付端与接收端通过该局域网络相互通信；又例如，支付端与接收端通过蓝牙配对建立蓝牙通道以实现近距离通信；再例如，支付端与接收端通过nfc天线感应以实现近距离通信；还例如，支付端或接收端中的一端对要传递的信息进行编码生成图形码，另一端扫描并解析该图形码以获取要传递的信息，从而通过图形码实现支付端与接收端之间的近距离通信，图形码可以是二维码或条形码，也可以是其它可以通过扫描及解码方式获取其信息的图形。
128.支付端与服务端之间的信息传递，既可以由支付端与服务端建立网络连接以实现直接的信息传递，该网络既可以是互联网，也可以是专用的网络；也可以由支付端通过中间设备与服务端实现间接的信息传递，例如中间设备为带有nfc功能的前置机，支付端与该中间设备之间通过nfc通信进行信息传递，该中间设备与服务端之间通过专用网络进行信息传递，由此实现支付端通过中间设备与服务端之间的信息传递。
129.接收端与服务端之间的信息传递，既可以由接收端与服务端建立网络连接以实现直接的信息传递，该网络既可以是互联网，也可以是专用的网络；也可以由接收端通过中间设备与服务端实现间接的信息传递。
130.为了便于说明，本发明各实施例仅以一个支付端和一个接收端为例进行说明，但在实际实施环境中，可以包括多个甚至大量的支付端和接收端，对于一个终端设备，既可以只作为支付端或接收端，或者也可以既作为支付端又作为接收端。
131.需要说明的是，本领域技术人员可以理解，图1中示出的实施环境结构并不构成对实施环境的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。图1中示出的实施环境结构仅用于加强对本发明技术的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术信息。
132.二、一种离线支付额度的控制方法实施例一
133.请参考图2，其示出了本发明提供的一种离线支付额度的控制方法实施例一的流程图。本实施例以该方法应用于图1所示实施环境中的支付端来举例说明，该方法可以包括：
134.步骤201.接收服务端下发的离线支付额度，并且本地保存所述离线支付额度。
135.步骤202.在进行离线支付时，如果支付数额不大于本地保存的所述离线支付额度，则生成离线支付凭证，在所述离线支付凭证中包括所述支付数额，并且从本地保存的所述离线支付额度中扣减所述支付数额。
136.步骤203.将所述离线支付凭证通过本地通信传递给接收端。
137.上述应用于支付端的实施例，支付端根据服务端下发的离线支付额度进行支付，相应地在服务端存储有该离线支付额度，一旦在支付端发生离线支付额度丢失的情况，由于在一定时间之后服务端会将存储的该离线支付额度进行释放，从而可以避免服务端上存储的离线支付额度一直得不到扣减的问题。
138.三、一种离线支付额度的控制方法实施例二
139.请参考图3，其示出了本发明提供的一种离线支付额度的控制方法实施例二的流程图。本实施例以该方法应用于图1所示实施环境中的接收端来举例说明，该方法可以包括：
140.步骤301.接收支付端通过本地通信传递的离线支付凭证，所述离线支付凭证包括支付数额。
141.步骤302.可选的，对所述离线支付凭证进行验证，并且在验证所述离线支付凭证合法之后，确定所述支付端支付成功。
142.步骤303.将所述离线支付凭证发送给服务端，以使得所述服务端根据所述离线支付凭证进行数字资产的划转。
143.上述应用于接收端的实施例，接收端通过本地通信接收支付端传递的离线支付凭证，并将该离线支付凭证发送给服务端，由此使得服务端对该离线支付凭证进行验证，并且在确定该离线支付凭证合法之后，将该支付数额对应的数字资产从该支付端所在账户划转给该接收端所在账户。
144.四、一种离线支付额度的控制方法实施例三
145.请参考图4，其示出了本发明提供的一种离线支付额度的控制方法实施例三的流程图。本实施例以该方法应用于图1所示实施环境中的服务端来举例说明，该方法可以包括：
146.步骤401.响应于支付端的操作，确定所述支付端的离线支付额度，并且存储所述离线支付额度。
147.步骤402.确定所述离线支付额度的第一到期时间。
148.步骤403.将所述离线支付额度下发给所述支付端。
149.步骤404.当接收到接收端发送的离线支付凭证，所述离线支付凭证中包括支付数额，则对所述离线支付凭证进行验证，并且在验证所述离线支付凭证合法之后，从所述支付端所在账户中将所述支付数额的数字资产划转给所述接收端所在账户，以及从存储的所述离线支付额度中扣减所述支付数额。
150.步骤405.当所述服务端的当前系统时间达到所述第一到期时间之后的时间，则将存储的所述离线支付额度进行释放。
151.上述应用于服务端的实施例，服务端确定及存储支付端的离线支付额度，并且根据接收端发送的离线支付凭证在该存储的离线支付额度中扣减支付数额，由于在一定时间之后(即第一到期时间之后)，服务端会将该存储的离线支付额度进行释放，因此，即使在支付端发生离线支付额度丢失的情况，也可以有效地避免服务端上存储的离线支付额度一直得不到扣减的问题。
152.五、一种离线支付额度的控制方法实施例四
153.请参考图5，其示出了本发明提供的一种离线支付额度的控制方法实施例四的流程图。本实施例是结合了上述一种离线支付额度的控制方法实施例一、实施例二和实施例三所形成的实施例。本实施例以该方法应用于图1所示的实施环境来举例说明，该方法可以包括：
154.步骤501.服务端响应于支付端的操作，确定所述支付端的离线支付额度，并且存储所述离线支付额度。
155.服务端响应于为支付端确定离线支付额度的操作，例如在所述服务端为所述支付端开通离线支付功能时，或者在所述支付端向所述服务端发送获取离线支付额度的操作请求时，又或者在所述支付端发生特定行为时(如用户登录等)，触发所述服务端启动为所述支付端确定离线支付额度。
156.所述服务端确定所述支付端的离线支付额度，即确定授予给所述支付端可以用于进行离线支付的额度。在实际实施过程中，所述服务端可以以多种实施方式确定所述离线支付额度，例如，所述服务端使用一个预设的额度(例如1000)作为所述离线支付额度；又例如，所述服务端根据所述支付端请求的额度确定所述离线支付额度，比如，所述服务端接收所述支付端发送的获取离线支付额度的操作请求，该请求中请求的离线支付额度为1000，则所述服务端确定所述离线支付额度为1000；还例如，所述服务端根据所述支付端的支付记录、或/和信用等级、或/和用户信息等确定所述离线支付额度。
157.所述服务端存储所述离线支付额度。可以理解，所述服务端存储的所述离线支付额度，应当与所述支付端的其他信息相区分，例如在实际实施过程中，可以在所述支付端所在账户下设置用于离线支付额度的配置项，该配置项用于存储所述离线支付额度；或者，也可以在所述支付端所在账户下设置用于离线支付的子账户，该子账户下存储所述离线支付额度。
158.步骤502.所述服务端确定所述离线支付额度的第一到期时间。
159.所述服务端确定所述离线支付额度的第一到期时间，所述第一到期时间用于确定所述离线支付额度的到期时间，具体可以包括：
160.实施方式一，所述服务端将预先定期生成的到期时间确定为所述第一到期时间。
161.具体的，所述服务端以预先生成的到期时间作为所述第一到期时间，该预先生成的到期时间是定期生成的。例如，所述服务端在每天的“08:00:00”重新生成到期时间，该到期时间为5天之后的时间，然后当天“08:00:00”至第二天“08:00:00”之间确定的离线支付额度，都使用该到期时间作为所述第一到期时间；以所述服务端在“2020
‑
08
‑
08 08:00:00”生成到期时间为例，则生成的到期时间为“2020
‑
08
‑
13 08:00:00”，由此，如果所述服务端是在“2020
‑
08
‑
08 08:00:00”至“2020
‑
08
‑
09 08:00:00”之间确定的离线支付额度，则确定的所述第一到期时间为“2020
‑
08
‑
13 08:00:00”，同理，如果所述服务端是在“2020
‑
08
‑
09 08:00:00”至“2020
‑
08
‑
10 08:00:00”之间确定的离线支付额度，则确定的所述第一到期时间为“2020
‑
08
‑
14 08:00:00”，依此类推。
162.实施方式二，所述服务端根据第一预设时长和所述服务端的第一当前系统时间确定所述第一到期时间。
163.例如，所述服务端获取所述服务端此时的当前系统时间(即第一当前系统时间)，将所述第一当前系统时间加上第一预设时长以生成所述第一到期时间，以所述第一当前系
统时间是“2020
‑
08
‑
08 08:00:00”、所述第一预设时长是5天为例，则所述第一到期时间为“2020
‑
08
‑
13 08:00:00”。
164.实施方式三，所述服务端根据第二预设时长和所述支付端发送的起始时间确定所述第一到期时间。
165.具体的，所述服务端接收所述支付端发送的起始时间，并且根据第二预设时长和该发送的起始时间以确定所述第一到期时间，例如将该发送的起始时间加上该第二预设时长以生成所述第一到期时间。
166.进一步的，在所述服务端以所述第一当前系统时间验证通过所述支付端发送的起始时间之后，所述服务端再根据第二预设时长和该发送的起始时间以确定所述第一到期时间。具体的，所述服务端接收所述支付端发送的起始时间，所述服务端比较该发送的起始时间与所述第一当前系统时间之间的时间差值，若该时间差值小于第三预设时长，则表示该发送的起始时间验证通过，然后根据该发送的起始时间和第二预设时长以确定所述第一到期时间，例如，以该发送的起始时间是“2020
‑
08
‑
08 08:00:00”、该第二预设时长是5天为例，所述服务端将该发送的起始时间加上该第二预设时长以生成所述第一到期时间，则所述第一到期时间为“2020
‑
08
‑
13 08:00:00”；否则，则表示该发送的起始时间验证不通过，不根据该发送的起始时间和第二预设时长以确定所述第一到期时间。可以理解，所述服务端比较该发送的起始时间与所述第一当前系统时间之间的时间差值，主要作用是为了避免该发送的起始时间与所述第一当前系统时间相比有比较大的偏差，因此，所述第三预设时长应是一个相对较小的时长，例如可以是5分钟的时长等。
167.实施方式四，所述服务端将所述支付端发送的到期时间确定为所述第一到期时间。
168.具体的，所述服务端接收所述支付端发送的到期时间，并且将该发送的到期时间确定为所述第一到期时间。
169.进一步的，在所述服务端以所述第一当前系统时间验证通过所述支付端发送的到期时间之后，所述服务端再将该发送的到期时间确定为所述第一到期时间。具体的，所述服务端接收所述支付端发送的到期时间，所述服务端比较该发送的到期时间是否是所述第一当前系统时间加上第四预设时长内的时间，若是，则将该发送的到期时间作为所述第一到期时间，否则，则不将该发送的到期时间作为所述第一到期时间。可以理解，如此实施的主要作用在于，以所述支付端发送的到期时间作为所述第一到期时间，同时为了避免该发送的到期时间过长(例如为了避免该发送的到期时间为一年之后的时间)，因此，将该发送的到期时间限制在所述第一当前系统时间加上第四预设时长之内的时间，例如，以所述第一当前系统时间是“2020
‑
08
‑
08 08:00:00”、所述第四预设时长是5天为例，则如果该发送的到期时间是“2020
‑
08
‑
13 07:00:00”，则将该发送的到期时间作为所述第一到期时间，否则，如果该发送的到期时间是“2020
‑
08
‑
13 09:00:00”，则不将该发送的到期时间作为所述第一到期时间。
170.可以理解，本发明各实施例中所述的当前系统时间，是指在执行相应步骤时所在设备所处的系统时间，也可以理解为实际获取的当前系统时间是在执行获取当前系统时间时所在设备所处的系统时间，由于各步骤在实际执行时的先后顺序和所处的时间点有可能存在不同，则在不同设备及不同步骤在实际执行时获取的当前系统时间也可能会存在不
同。
171.进一步，在实际实施环境中，由于可以包括多个甚至大量的支付端和接收端，因此，为了使得所述服务端可以识别每个支付端对应的离线支付额度，以及为了确定每个离线支付额度对应的到期时间(即第一到期时间)，则可以在存储所述离线支付额度时将所述离线支付额度设置为所述支付端对应的离线支付额度，即建立所述支付端与所述离线支付额度的对应关系，以及将所述第一到期时间设置为所述离线支付额度对应的到期时间，例如，所述服务端获取所述支付端的支付端识别信息，建立所述支付端识别信息与所述离线支付额度的对应关系，可以理解，在实际建立所述支付端识别信息与所述离线支付额度的对应关系时，所述服务端还可以根据所述支付端识别信息确定所述支付端所在的账户，并且在所述支付端所在账户下建立用于离线支付的子账户或配置项，再通过该子账户或该配置项以存储和设置所述离线支付额度，并且将所述第一到期时间设置为所述离线支付额度对应的到期时间。
172.步骤503.所述服务端将所述离线支付额度下发给所述支付端。
173.所述服务端将所述离线支付额度下发给所述支付端，以所述离线支付额度为1000为例，则所述服务端下发给所述支付端的离线支付额度为1000。
174.进一步的，所述服务端将所述支付端的支付端识别信息下发给所述支付端，所述支付端识别信息为用于识别所述支付端的识别信息，可以是终端设备标识、芯片卡标识、手机号码、账号、数字证书、公钥、基于公钥生成的地址或其他可用于唯一地识别所述支付端的信息。
175.进一步的，所述服务端将所述第一到期时间下发给所述支付端。
176.进一步的，所述服务端还可以确定第二到期时间，所述第二到期时间为所述第一到期时间之前的时间，然后将所述第二到期时间下发给所述支付端，所述第二到期时间将用于接收端判断离线支付凭证是否合法。所述服务端确定第二到期时间，可以包括多种实施方式，具体可以参照上述步骤502中确定第一到期时间的实施方式，并且把所述第二到期时间确定为所述第一到期时间之前的时间，而且要使得所述第二到期时间与接收端上获取的第二到期时间相一致。
177.进一步的，所述服务端还可以生成签名值，并且将所述签名值下发给所述支付端，所述签名值为所述服务端对待签名信息进行数字签名生成的签名值。具体的，所述服务端对待签名信息进行数字签名以生成签名值，其中，所述待签名信息可以包括所述离线支付额度或/和所述支付端识别信息或/和所述第一到期时间或/和所述第二到期时间。
178.可以理解，数字签名是指附加在数据单元上的数据，或是对数据单元所作的密码变换，这种数据或变换允许数据单元的验证方(如支付端、接收端)用以确认数据单元的来源和完整性，并保护数据防止被伪造或抵赖。具体的，在数字签名的一种实现方式中，所述服务端使用非对称加密算法进行数字签名以生成所述签名值，例如，所述服务端使用哈希算法对所述待签名信息进行哈希计算得到哈希值(即信息摘要)，所述服务端使用所述服务端的私钥对该哈希值加密得到加密结果(即签名值)。
179.相应地，所述支付端接收所述服务端下发的所述离线支付额度，进一步的，所述支付端还接收所述服务端下发的所述支付端识别信息或/和所述第一到期时间或/和所述第二到期时间或/和所述签名值。
180.步骤504.所述支付端本地保存所述离线支付额度。
181.所述支付端本地保存所述离线支付额度。
182.对于上述步骤503和步骤504，所述服务端将所述离线支付额度下发给所述支付端，以及所述支付端本地保存所述离线支付额度，可以包括：
183.例如，所述服务端将所述离线支付额度发送给所述支付端，则所述支付端接收所述服务端发送的所述离线支付额度，以及本地保存接收到的所述离线支付额度。
184.又例如，如果所述服务端是根据所述支付端预先保存的离线支付额度确定的所述离线支付额度，则所述服务端可以向所述支付端返回第三确认信息，该第三确认信息表征所述服务端已经根据所述支付端预先保存的离线支付额度作为所述离线支付额度，则所述支付端在接收到该第三确认信息之后，所述支付端以预先保存的该离线支付额度作为本地保存的所述离线支付额度，例如，所述支付端向所述服务端发送获取离线支付额度的操作请求，该请求中请求的离线支付额度为1000，并且预先保存该离线支付额度(即1000)，当所述支付端接收到所述服务端返回的第三确认信息，该第三确认信息表征所述服务端已经以所述支付端预先保存的离线支付额度作为所述离线支付额度，则所述支付端以预先保存的该离线支付额度(即1000)作为本地保存的所述离线支付额度。
185.进一步的，如果所述支付端还接收有所述服务端下发的签名值，则所述支付端使用相应的数字签名验证方式对所述签名值进行数字签名验证，若验证所述签名值合法，则执行本步骤504及后续步骤，否则，则不执行本步骤504及后续步骤。
186.具体的，所述支付端生成第一待校验信息，并且生成方式与所述服务端生成待签名信息的生成方式相同，从而使得生成的所述第一待校验信息与所述服务端生成的所述待签名信息相同。
187.所述支付端获取所述服务端的公钥，使用该公钥解密所述签名值得到解密结果(即信息摘要)，并且所述支付端使用相同的哈希算法对所述第一待校验信息进行哈希计算得到哈希值(即校验值)，比较该解密结果(即信息摘要)与该校验值是否相同，若相同，则确定所述签名值合法，否则，则确定所述签名值不合法。
188.所述支付端获取所述服务端的公钥，可以是获取所述支付端预先保存的所述服务端的公钥，例如，所述支付端上预先保存所述服务端的公钥，则所述支付端获取该保存的公钥，可以理解，当所述服务端基于ibc(identity
‑
based cryptograph)产生的私钥对所述待签名信息进行数字签名，并且以所述服务端识别信息作为所述服务端的公钥时，则所述支付端预先保存的服务端的公钥为所述服务端的识别信息；所述支付端也可以是获取所述服务端传递的服务端的公钥，例如，当所述服务端基于pki(public key infrastructure)体系产生的私钥对所述待签名信息进行数字签名时，则所述服务端可以在向所述支付端下发所述离线支付额度时还包括下发所述服务端的数字证书，如此所述支付端从该数字证书中获取所述服务端的公钥，可以理解，实际应用过程中，还应当使用预置的根证书验证该服务端的数字证书是否合法。
189.其中，若所述服务端生成的所述待签名信息中包括所述离线支付额度，则所述第一待校验信息包括所述离线支付额度。
190.其中，若所述服务端生成的所述待签名信息中包括支付端识别信息，则所述支付端获取所述支付端的支付端识别信息，在生成的所述第一待校验信息中包括该支付端识别
信息；可以理解，所述支付端获取所述支付端的支付端识别信息，可以是所述支付端上预先保存有所述支付端的支付端识别信息，则所述支付端获取该预先保存的支付端识别信息；也可以是所述服务端在向所述支付端下发所述离线支付额度时还包括下发支付端识别信息，则所述支付端获取该包括的支付端识别信息，所述支付端将该包括的支付端识别信息与预先保存的支付端识别信息进行比较，如果一致，则说明所述离线支付额度合法，亦即说明所述离线支付额度是用于所述支付端的离线支付额度，继续执行后续步骤，否则，则不继续执行后续步骤。
191.其中，若所述服务端生成的所述待签名信息中包括所述第一到期时间，则所述支付端获取所述第一到期时间，并且在生成的所述第一待校验信息中包括所述第一到期时间。其中，所述支付端获取所述第一到期时间，可以包括多种获取方式，具体可以包括：
192.获取方式一，所述支付端还接收有所述服务端发送的所述第一到期时间，即上述步骤503所述服务端向所述支付端还发送有所述第一到期时间，则所述支付端获取所述第一到期时间。
193.获取方式二，所述支付端还接收有所述服务端返回的第一确认信息，所述第一确认信息表征所述服务端已经验证通过所述支付端发送的起始时间，则所述支付端根据预先保存的该起始时间和第二预设时长以确定所述第一到期时间，并且其确定方式与所述服务端上确定第一到期时间的确定方式相一致。
194.具体的，在所述支付端向所述服务端发送获取离线支付额度的操作请求时，所述支付端将所述支付端此时的当前系统时间作为起始时间，并且在该操作请求中包括该起始时间(对应于所述服务端而言，该起始时间相当于上述步骤502实施方式三中示例的所述服务端接收的所述支付端发送的起始时间)，同时所述支付端保存该起始时间；在所述服务端上，当所述服务端验证通过该起始时间，则所述服务端在向所述支付端下发所述离线支付额度时还包括向所述支付端返回第一确认信息，所述第一确认信息表征所述服务端已经验证通过该起始时间，因此，当所述支付端接收到所述第一确认信息，则所述支付端根据保存的该起始时间和第二预设时长以确定所述第一到期时间，其中，该第二预设时长为预先在所述支付端上保存的时长，其确定方式与所述服务端上确定第一到期时间的确定方式相一致，包括该第二预设时长与所述服务端上的第二预设时长相同，以此使得该确定的第一到期时间与所述服务端上确定的第一到期时间相一致，例如，与上述步骤502实施方式三中的示例相对应的，所述支付端保存的起始时间是“2020
‑
08
‑
08 08:00:00”、预先保存的第二预设时长是5天，则所述支付端将该起始时间加上该第二预设时长以生成所述第一到期时间，则所述第一到期时间为“2020
‑
08
‑
13 08:00:00”。
195.获取方式三，所述支付端还接收有所述服务端返回的第二确认信息，所述第二确认信息表征所述服务端已经验证通过所述支付端发送的到期时间，则所述支付端将预先保存的该到期时间确定为所述第一到期时间。
196.具体的，在所述支付端向所述服务端发送获取离线支付额度的操作请求时，所述支付端在该操作请求中包括到期时间(对应于所述服务端而言，该到期时间相当于上述步骤502实施方式四中示例的所述服务端接收的支付端发送的到期时间)，该到期时间既可以是所述支付端的用户输入的，也可以是所述支付端根据所述支付端此时的当前系统时间加上第五预设时长生成的，同时所述支付端保存该到期时间；在所述服务端上，当所述服务端
验证通过该到期时间，则所述服务端在向所述支付端下发所述离线支付额度时还包括向所述支付端返回第二确认信息，所述第二确认信息表征所述服务端已经验证通过该到期时间，因此，当所述支付端接收到所述第二确认信息，则所述支付端将保存的该到期时间确定为所述第一到期时间。
197.其中，若所述服务端生成的所述待签名信息中包括所述第二到期时间，则所述支付端获取所述第二到期时间，并且在生成的所述第一待校验信息中包括所述第二到期时间。其中，所述支付端获取所述第二到期时间，可以包括多种获取方式，例如，所述服务端在向所述支付端下发所述离线支付额度时还包括发送所述第二到期时间，则所述支付端获取该发送的所述第二到期时间；又例如，所述服务端在向所述支付端下发所述离线支付额度时还包括向所述支付端返回第一确认信息，所述第一确认信息表征所述服务端已经验证通过所述支付端发送的起始时间，则所述支付端根据预先保存的该起始时间和第七预设时长以确定所述第二到期时间，并且其确定方式与接收端上确定第二到期时间的确定方式相一致；还例如，在所述支付端获取到所述第一到期时间之后，将所述第一到期时间减去第八预设时长确定为所述第二到期时间，并且其确定方式与接收端上确定第二到期时间的确定方式相一致。可以理解，所述第二到期时间为所述第一到期时间之前的时间，而且要使得所述第二到期时间与接收端上获取的第二到期时间相一致。
198.步骤505.当所述支付端在进行离线支付时，如果支付数额不大于本地保存的所述离线支付额度，则生成离线支付凭证，在所述离线支付凭证中包括所述支付数额，并且从本地保存的所述离线支付额度中扣减所述支付数额。
199.当所述支付端在进行离线支付时，所述支付端判断支付数额是否大于本地保存的所述离线支付额度，如果所述支付数额不大于本地保存的所述离线支付额度，则生成离线支付凭证，在所述离线支付凭证中包括所述支付数额，并且从本地保存的所述离线支付额度中扣减所述支付数额。
200.可以理解，所述支付数额是指支付端要支付给接收端的数字资产的数额，所述支付数额可以是用户输入的，也可以是接收端传递给支付端的，也可以是以其他方式输入的，对此本发明实施例并不进行限定。
201.可以理解，所述判断支付数额是否大于本地保存的所述离线支付额度，是指判断所述支付端要支付给接收端的支付数额是否大于本地保存的所述离线支付额度，如果所述支付数额大于本地保存的所述离线支付额度，则不能进行离线支付；如果所述支付数额小于或等于本地保存的所述离线支付额度，则允许进行离线支付，并且从本地保存的所述离线支付额度中扣减所述支付数额。例如，以本地保存的所述离线支付额度为1000为例，如果所述支付数额为100，则会判断所述支付数额不大于本地保存的所述离线支付额度，则生成离线支付凭证。
202.所述从本地保存的所述离线支付额度中扣减所述支付数额，也可以理解为是，将本地保存的所述离线支付额度更新为更新前的离线支付额度减去所述支付数额之后的余额，例如，以本地保存的所述离线支付额度为1000、所述支付数额为100为例，从本地保存的所述离线支付额度中扣减所述支付数额之后，本地保存的所述离线支付额度更新为900。
203.可以理解，所述支付端可以进行多次离线支付，每进行一次离线支付时，则从本地保存的所述离线支付额度中扣减该次离线支付的支付数额，即将本地保存的所述离线支付
额度更新为更新前的离线支付额度减去该次离线支付的支付数额之后的余额，例如，在本地保存的所述离线支付额度为900之后，如果再进行一次离线支付，并且支付数额为200，则从本地保存的所述离线支付额度中减去支付数额200，则本地保存的所述离线支付额度更新为700；如果再进行一次离线支付，并且支付数额为300，则从本地保存的所述离线支付额度中减去支付数额300，则本地保存的所述离线支付额度更新为400。
204.进一步的，为了让所述服务端识别所述离线支付凭证为所述支付端生成的离线支付凭证，则支付端还可以在生成的所述离线支付凭证中包括所述支付端的支付端识别信息。
205.进一步的，所述支付端获取所述第一到期时间，当所述支付端的当前系统时间达到所述第一到期时间之后的时间，则将本地保存的所述离线支付额度进行释放，例如将本地保存的所述离线支付额度进行删除、清空、重置为零或失效处理等。其中，所述支付端获取所述第一到期时间的获取方式，可见上述步骤504中的获取方式，在此不再赘述。
206.进一步的，所述支付端获取所述第二到期时间，当所述支付端的当前系统时间达到所述第二到期时间之后的时间，则将本地保存的所述离线支付额度进行释放。其中，所述支付端获取所述第二到期时间的获取方式，可见上述步骤504中的获取方式，在此不再赘述。
207.上述将本地保存的所述离线支付额度进行释放的主要作用在于，所述支付端在将本地保存的所述离线支付额度进行释放之后，则所述支付端将不可以生成离线支付凭证，即所述支付端不能根据本地保存的所述离线支付额度进行离线支付，从而可以避免接收端在所述第一到期时间或所述第二到期时间之后接收到所述支付端生成的离线支付凭证。
208.可以理解，由于所述第二到期时间为所述第一到期时间之前的时间，因此，当实施了在所述第二到期时间之后释放所述离线支付额度，则相当于也达到了在所述第一到期时间之后释放所述离线支付额度的作用，因此也可以不用再实施在所述第一到期时间之后释放所述离线支付额度。
209.可以理解，本步骤505中所述支付端向所述接收端进行的离线支付，可以应用在单离线状态或/和双离线状态时的应用场景，但并非限定所述支付端必须处于离线状态，即也可以在所述支付端处于在线状态时进行本步骤505中的离线支付。
210.步骤506.所述支付端将所述离线支付凭证通过本地通信传递给接收端。
211.所述支付端通过本地通信向接收端传递所述离线支付凭证，如实施环境说明中所述，所述支付端可以通过局域网向所述接收端传递所述离线支付凭证，也可以通过蓝牙、红外线、nfc、wifi、声波、ble(低功耗蓝牙)或图形码等近距离通信方式向所述接收端传递所述离线支付凭证。
212.进一步的，所述支付端还将所述签名值通过本地通信传递给所述接收端。
213.相应地，所述接收端接收所述支付端通过本地通信传递的所述离线支付凭证，进一步的，还包括接收所述支付端传递的所述签名值。
214.步骤507.可选的，所述接收端对所述离线支付凭证进行验证，并且在验证所述离线支付凭证合法之后，确定所述支付端支付成功。
215.可选的，所述接收端对所述离线支付凭证进行验证，并且在验证所述离线支付凭证合法之后，确定所述支付端支付成功。
216.所述接收端对所述离线支付凭证进行验证的实施方式，可以包括检查所述离线支付凭证的数据格式是否有效、判断所述支付数额是否达到预设要求、对所述离线支付凭证中携带的认证信息或用户信息(如果涉及)进行验证等。可选的，所述接收端对所述离线支付凭证进行验证的实施方式还可以包括：
217.验证方式一，如果还接收到所述支付端传递的所述签名值，则所述接收端使用相应的数字签名验证方式对所述签名值进行数字签名验证，若验证所述签名值合法，则确定验证通过，否则，则确定验证不通过。
218.具体的，所述接收端生成第二待校验信息，并且生成方式与所述服务端生成待签名信息的生成方式相同，从而使得生成的所述第二待校验信息与所述服务端生成的所述待签名信息相同。
219.所述接收端获取所述服务端的公钥，使用该公钥解密所述签名值得到解密结果(即信息摘要)，并且所述接收端使用相同的哈希算法对所述第二待校验信息进行哈希计算得到哈希值(即校验值)，比较该解密结果(即信息摘要)与该校验值是否相同，若相同，则确定所述签名值合法，否则，则确定所述签名值不合法。
220.所述接收端获取所述服务端的公钥，可以是获取所述接收端预先保存的所述服务端的公钥，例如，所述接收端上预先保存所述服务端的公钥，则所述接收端获取该保存的公钥，可以理解，当所述服务端基于ibc(identity
‑
based cryptograph)产生的私钥对所述待签名信息进行数字签名，并且以所述服务端识别信息作为所述服务端的公钥时，则所述接收端预先保存的所述服务端的公钥为所述服务端的识别信息；又例如，当所述服务端基于pki(public key infrastructure)体系产生的私钥对所述待签名信息进行数字签名时，则所述接收端可以接收所述支付端转发的所述服务端的数字证书，如此所述接收端从该数字证书中获取所述服务端的公钥，可以理解，实际应用过程中，还应当使用预置的根证书验证该服务端的数字证书是否合法。
221.其中，若所述服务端生成的所述待签名信息中包括所述离线支付额度，则所述第二待校验信息包括所述离线支付额度。
222.其中，若所述服务端生成的所述待签名信息中还包括支付端识别信息，则所述接收端获取所述支付端的支付端识别信息，在生成的所述第二待校验信息中也包括该支付端识别信息；其中，所述接收端获取所述支付端的支付端识别信息，可以是所述支付端在生成的所述离线支付凭证中包括支付端识别信息，则所述接收端获取该包括的支付端识别信息；也可以是所述接收端接收所述支付端通过本地通信传递的所述离线支付凭证时，还包括接收所述支付端传递的所述支付端识别信息，则所述接收端获取所述支付端识别信息；还可以是所述接收端接收所述支付端通过本地通信传递的所述离线支付凭证时，还包括接收所述支付端传递的所述支付端的数字证书，所述接收端获取的所述支付端识别信息为该数字证书中的序列号(serialnumber)、主题(subject)、主题唯一标识(subjectuniqueid)或公钥等具有唯一性的标签值。
223.其中，若所述服务端生成的所述待签名信息中还包括所述第一到期时间，则所述接收端获取所述第一到期时间，并且在生成的所述第二待校验信息中包括所述第一到期时间。其中，所述接收端获取所述第一到期时间，可以包括多种获取方式，例如，所述接收端接收所述支付端通过本地通信传递的所述离线支付凭证时，还包括接收所述支付端传递的所
述第一到期时间，则所述接收端获取所述第一到期时间；又例如，所述接收端接收所述支付端通过本地通信传递的所述离线支付凭证时，还包括接收所述支付端传递的起始时间，该起始时间为上述步骤504获取方式二中所述支付端预先保存的起始时间，则所述接收端根据该起始时间和第二预设时长以确定所述第一到期时间，其中，该第二预设时长为预先在所述接收端上保存的时长，其确定方式与所述服务端上确定第一到期时间的确定方式相一致，包括该第二预设时长与所述服务端上的第二预设时长相同，以此使得该确定的第一到期时间与所述服务端上确定的第一到期时间相一致。
224.其中，若所述服务端生成的所述待签名信息中还包括所述第二到期时间，则所述接收端获取所述第二到期时间，并且在生成的所述第二待校验信息中包括所述第二到期时间。
225.验证方式二，所述接收端获取所述第一到期时间，判断所述接收端此时的当前系统时间是否为所述第一到期时间之前的时间，若是，则确定验证通过，否则，则确定验证不通过。
226.具体的，所述接收端获取所述第一到期时间，获取方式可以参见上述验证方式一中的获取方式，在此不再赘述。然后所述接收端判断所述接收端此时的当前系统时间是否为所述第一到期时间之前的时间，若是，则确定验证通过，否则，则确定验证不通过。
227.如此实施可以包括多个方面的作用，例如，可以使得所述支付端需在所述第一到期时间之前根据所述离线支付额度进行离线支付，否则，如果所述支付端在所述第一到期时间之后进行离线支付，亦即如果所述接收端在所述第一到期时间之后接收到所述离线支付凭证，则会确定所述离线支付凭证验证不通过；又例如，在所述第一到期时间之后，所述服务端会将存储的所述离线支付额度进行释放，其中一种可选的实施方式，所述服务端将会确定所述离线支付凭证不合法(具体可参见步骤509中的相关说明)，因此，所述接收端应当在所述第一到期时间之前接收到所述离线支付凭证，如此才可以在所述第一到期时间之前将所述离线支付凭证发送给所述服务端，否则，则确定所述离线支付凭证验证不通过。
228.验证方式三，获取所述第二到期时间，所述第二到期时间为所述第一到期时间之前的时间，判断所述接收端此时的当前系统时间是否为所述第二到期时间之前的时间，若是，则确定验证通过，否则，则确定验证不通过。
229.当所述接收端是在离线状态下接收所述离线支付凭证，及至所述接收端处于在线状态，会存在一定的时间差，因此，为了避免待所述接收端处于在线状态之后所述接收端此时的当前系统时间已经为所述第一到期时间之后的时间，则还应当预留一定的时间差，即所述接收端应当在所述第一到期时间之前的一定时间内接收到所述离线支付凭证，否则，则确定所述离线支付凭证验证不通过。因此，所述接收端还可以获取第二到期时间，并且所述第二到期时间为所述第一到期时间之前的时间，例如，以所述第一到期时间是“2020
‑
08
‑
13 08:00:00”为例，所述第二到期时间为所述第一到期时间之前1天的时间，则所述第二到期时间是“2020
‑
08
‑
12 08:00:00”。然后所述接收端判断所述接收端此时的当前系统时间是否为所述第二到期时间之前的时间，若是，则确定验证通过，否则，则确定验证不通过。
230.所述接收端获取所述第二到期时间，可以包括多种获取方式，例如，所述支付端向所述接收端传递所述第二到期时间，则所述接收端接收及获取所述支付端传递的所述第二到期时间；又例如，所述接收端接收所述支付端通过本地通信传递的所述离线支付凭证时，
还包括接收所述支付端传递的起始时间，该起始时间为上述步骤502实施方式三中所述支付端保存的起始时间，则所述接收端根据该起始时间和第七预设时长以确定所述第二到期时间，该第七预设时长是小于第二预设时长的时长，该第二预设时长是指上述步骤502实施方式三中所述服务端根据该起始时间和第二预设时长以确定所述第一到期时间中所述的第二预设时长，以该起始时间是“2020
‑
08
‑
08 08:00:00”、所述第七预设时长是4天为例，则将该起始时间加上该第七预设时长以生成所述第二到期时间，则所述第二到期时间为“2020
‑
08
‑
12 08:00:00”；还例如，在所述接收端获取到所述第一到期时间之后，将所述第一到期时间减去第八预设时长确定为所述第二到期时间，以所述第一到期时间是“2020
‑
08
‑
13 08:00:00”、所述第八预设时长为1天为例，则所述第二到期时间是“2020
‑
08
‑
12 08:00:00”。
231.可以理解，只有实施了验证方式三，则上述所述的在下发所述离线支付额度时还包括下发所述第二到期时间、或/和所述待签名信息中包括所述第二到期时间、或/和所述支付端的当前系统时间达到所述第二到期时间之后将本地保存的所述离线支付额度进行释放等多种实施方式，才有实施的必要，否则，如果没有实施验证方式三，则该多种实施方式也没有实施的必要。
232.可以理解，当同时实施上述多种验证方式时，只有每种验证方式都确定验证通过，才确定所述离线支付凭证合法，否则，若任一验证方式为验证不通过，则确定所述离线支付凭证不合法。也可以理解，当只实施上述验证方式中的一种验证方式时，若该一种验证方式确定验证通过，则确定所述离线支付凭证合法，否则，若该一种验证方式确定验证不通过，则确定所述离线支付凭证不合法。
233.可以理解，对于上述验证方式二和验证方式三，虽然可以同时实施上述验证方式二和验证方式三，但由于验证方式三中的所述第二到期时间为所述第一到期时间之前的时间，因此，当实施了验证方式三，相当于也达到了验证方式二的作用，因此也可以不用再实施验证方式二。
234.所述接收端在验证所述离线支付凭证合法之后，则确定所述支付端支付成功，也可以理解为认可该次支付。以行驶的飞机为例，例如，在确定所述支付端支付成功之后，则乘务员可以为支付成功的乘客提供相应的商品或服务；又例如，所述支付端在访问应用服务器时触发购买相应的服务(如购物、观影等)，并且向所述接收端发送所述离线支付凭证，则所述接收端在确定所述支付端支付成功之后，向应用服务器反馈表示支付成功的信息，则应用服务器确定所述支付端购买成功，并且向所述支付端提供该相应的服务。
235.可以理解，本步骤作为可选的实施步骤，所述接收端既可以在在线状态时实施本步骤，也可以在离线状态时实施本步骤，从而可以在所述接收端接收到所述离线支付凭证之后、以及在将所述离线支付凭证发送给所述服务端之前确定所述支付端是否支付成功。可以理解，这里所指的在线状态是指能够与数字资产服务端进行实时通信的应用场景，这里所指的离线状态是指不能够与数字资产服务端进行实时通信的应用场景。
236.步骤508.所述接收端将所述离线支付凭证发送给所述服务端。
237.所述接收端将所述离线支付凭证发送给所述服务端。具体的，既可以由所述接收端与所述服务端建立网络连接，由所述接收端直接将所述离线支付凭证发送给所述服务端，例如，以行驶的飞机为例，在飞机落地之后，所述接收端接入移动互联网并与所述服务
端建立网络连接，由所述接收端将所述离线支付凭证发送给所述服务端；也可以由所述接收端间接地将所述离线支付凭证发送给所述服务端，即所述接收端通过中间设备(如收款服务器等收款设备)将所述离线支付凭证发送给所述服务端，例如，在飞机上部署有收款设备，所述接收端将所述离线支付凭证同步给收款设备，当飞机落地之后，收款设备与所述服务端建立网络连接，收款设备将所述离线支付凭证发送给所述服务端；又例如，在飞机落地之后，所述接收端接入移动互联网并与航空公司的收款服务器建立网络连接，所述接收端将所述离线支付凭证同步给该收款服务器，该收款服务器将所述离线支付凭证通过网络发送给所述服务端。
238.可以理解，如果所述接收端是在离线状态下接收的所述离线支付凭证，则所述接收端或中间设备应当在处于在线状态之后才可以将所述离线支付凭证发送给所述服务端。
239.可以理解，如果上述步骤507验证所述离线支付凭证不合法，则所述接收端可以不将所述离线支付凭证发送给所述服务端，以此避免所述服务端对不合法的离线支付凭证进行验证；所述接收端也可以将所述离线支付凭证发送给所述服务端，以使得所述服务端进行进一步的验证或/和审核记录等。
240.相应地，所述服务端接收所述接收端发送的所述离线支付凭证。
241.步骤509.当所述服务端接收到所述接收端发送的所述离线支付凭证，则所述服务端对所述离线支付凭证进行验证，并且在验证所述离线支付凭证合法之后，所述服务端从所述支付端所在账户中将所述支付数额的数字资产划转给所述接收端所在账户，以及从所述服务端存储的所述离线支付额度中扣减所述支付数额。
242.在所述服务端，当所述服务端接收到所述接收端发送的所述离线支付凭证之后，则所述服务端对所述离线支付凭证进行验证，并且在验证所述离线支付凭证合法之后，从所述支付端所在账户中将所述支付数额的数字资产划转给所述接收端所在账户，以及从上述步骤501中存储的所述离线支付额度中扣减所述支付数额。
243.所述服务端对所述离线支付凭证进行验证的实施方式，可以包括检查所述离线支付凭证的数据格式是否有效、对所述离线支付凭证中携带的认证信息或用户信息(如果涉及)进行验证等。可选的，所述服务端对所述离线支付凭证进行验证的实施方式还可以包括：所述服务端判断所述支付数额是否大于所述服务端存储的所述离线支付额度，如果所述支付数额不大于存储的所述离线支付额度，则确定所述离线支付凭证合法，否则，则确定所述离线支付凭证不合法。可以理解，如果所述支付数额大于存储的所述离线支付额度，或者存储的所述离线支付额度被释放等，则可以确定所述离线支付凭证不合法。
244.可以理解，所述服务端从存储的所述离线支付额度中扣减所述支付数额，是指从上述步骤501中所述服务端确定并存储的所述离线支付额度中扣减所述支付数额，即将存储的所述离线支付额度更新为更新前的离线支付额度减去所述支付数额之后的余额，例如，以上述步骤501中所述服务端存储所述离线支付额度的示例为例，存储的所述离线支付额度为1000，如果所述支付数额为100，则从存储的所述离线支付额度中扣减所述支付数额之后，则存储的所述离线支付额度更新为900。
245.可以理解，所述服务端可以多次接收离线支付凭证，并且在确定接收的离线支付凭证合法之后，从存储的所述离线支付额度中扣减该离线支付凭证中的支付数额，例如，在上述存储的所述离线支付额度为900之后，如果再次接收到离线支付凭证，其中的支付数额
为200，则在验证该再次接收的离线支付凭证合法之后，从存储的所述离线支付额度中扣减支付数额200，则存储的所述离线支付额度更新为700；如果又一次接收到离线支付凭证，其中的支付数额为300，则在验证该又一次接收的离线支付凭证合法之后，从存储的所述离线支付额度中扣减支付数额300，则存储的所述离线支付额度更新为400。
246.所述服务端从所述支付端所在账户中将所述支付数额的数字资产划转给所述接收端所在账户，主要是指将所述支付数额所表征的数字资产从所述支付端所在的账户中划转至所述接收端所在的账户，根据数字资产的类型，可以采取相对应的划转方式，例如：
247.以数字资产为余额形式的数字资产为例，则从所述支付端所在账户中减去所述支付数额，在所述接收端所在的账户中增加所述支付数额。例如，以所述支付端所在账户的余额是500、所述接收端所在账户的余额是500、所述支付数额是100为例，则从所述支付端所在账户中将所述支付数额的数字资产划转给所述接收端所在账户之后，所述支付端所在账户的余额是400，所述接收端所在账户的余额是600；又例如，以所述服务端是第三方支付平台为例(如类似支付宝或微信支付的支付平台)，则还可以从所述支付端所在账户绑定的银行账户中划转所述支付数额(也可以理解为是相应的支付金额)给所述接收端所在的账户。
248.以数字资产为字符串形式的数字资产为例，则所述服务端将所述支付端所在账户下所述支付数额的数字资产更改为所述接收端所在账户下的数字资产。具体的，在所述服务端记录有每个数字资产的属主，即在所述服务端对表征数字资产的字符串记录有相应的属主，则将所述支付数额的数字资产的属主由所述支付端所在的账户更改为所述接收端所在的账户，亦即从属主为所述支付端所在账户的数字资产中，选取面值为所述支付数额的数字资产，或者选取面值总和为所述支付数额的数字资产，将其属主更改为所述接收端所在的账户。
249.可以理解，本发明实施例中所述支付端所在账户，可以以多种方式进行确定，例如，在所述支付端生成的所述离线支付凭证中包括所述支付端所在账户的账户识别信息(例如所述支付端所在账户的用户账号、所述支付端所在账户的用户身份信息、支付端识别信息等)，即该账户识别信息为可以用于识别所述支付端所在账户的识别信息，从而所述服务端可以根据该账户识别信息确定所述支付端所在账户。
250.可以理解，本发明实施例中所述接收端所在账户，可以以多种方式进行确定，例如，在所述支付端生成的所述离线支付凭证中包括所述接收端所在账户的账户识别信息(例如所述接收端所在账户的用户账号、所述接收端所在账户的用户身份信息、接收端识别信息等)，即该账户识别信息为可以用于识别所述接收端所在账户的识别信息，从而所述服务端可以根据该账户识别信息确定所述接收端所在账户；又例如，所述服务端在接收到所述离线支付凭证时，获取发送方的账户识别信息(例如用户账号、用户身份信息、接收端识别信息等)，该账户识别信息为可以用于识别所述接收端所在账户的识别信息，则所述服务端根据该账户识别信息确定所述接收端所在的账户。可以理解，所述接收端识别信息为用于识别接收端的信息，可以是终端设备标识、芯片卡标识、手机号码、账号、数字证书、公钥、基于公钥生成的地址或其他可用于唯一地识别接收端的信息。
251.可以理解，如果所述接收端所在账户是属于其他服务端上的账户，则所述服务端可以从所述支付端所在账户中将所述支付数额的数字资产划转给该其他服务端，然后再由该其他服务端将所述支付数额的数字资产划入所述接收端所在账户，如此实施的一个常见
应用场景为在不同银行系统的账户之间实现数字资产的划转。
252.进一步的，如上述步骤502中所述，为了使得所述服务端可以识别每个支付端对应的离线支付额度，所述服务端在存储所述离线支付额度时将所述离线支付额度存储为所述支付端对应的离线支付额度，因此，在本步骤509中所述服务端从所述服务端存储的所述离线支付额度中扣减所述支付数额时，所述服务端先根据支付端与离线支付额度的对应关系确定存储的对应的离线支付额度，例如，如果上述步骤502在实际实施时是建立所述支付端识别信息与所述离线支付额度的对应关系，则在本步骤中，所述服务端可以根据所述离线支付凭证中包括的支付端识别信息确定对应的离线支付额度，进一步的，如果上述步骤502在实际实施时是在所述支付端所在账户下建立用于离线支付的子账户或配置项，则在本步骤中，所述服务端可以在确定所述支付端所在账户之后，再通过所述支付端所在账户下建立的子账户或配置项确定对应的离线支付额度。
253.步骤510.当所述服务端的当前系统时间达到所述第一到期时间之后的时间，则所述服务端将存储的所述离线支付额度进行释放。
254.当所述服务端的当前系统时间达到所述第一到期时间之后的时间，则所述服务端将存储的所述离线支付额度进行释放，例如将存储的所述离线支付额度进行删除、清空、重置为零或失效处理等，使得存储的所述离线支付额度不再占用所述支付端用于进行离线支付的额度。
255.可以理解，如背景技术中所述，所述支付端有可能会出现离线支付额度丢失的情况，而一旦所述支付端出现离线支付额度丢失的情况，则会导致该丢失的离线支付额度在所述服务端对应存储的所述离线支付额度中会一直得不到扣减，即该丢失的离线支付额度会一直相应地在所述服务端占用所述支付端用于进行离线支付的额度，例如，假设当所述支付端本地保存的所述离线支付额度为400时，所述支付端出现离线支付额度丢失的情况，即丢失的离线支付额度为400，由于所述支付端不能再根据本地保存的所述离线支付额度生成离线支付凭证，则所述服务端也就一直不能从所述服务端存储的所述离线支付额度中进行支付数额的扣减，从而使得所述服务端存储的所述离线支付额度的余额最终会一直为该丢失的离线支付额度(即400)，而通过本步骤510，在所述第一到期时间之后将所述服务端存储的所述离线支付额度及时地进行释放，则可以有效地避免所述服务端存储的所述离线支付额度的余额一直占用所述支付端用于进行离线支付的额度。
256.进一步的，所述服务端还可以多次响应于所述支付端的操作，并为所述支付端授予相应的离线支付额度。具体可以包括多种实施方式，例如可以包括：
257.第一种实施方式，所述服务端响应于支付端的操作之后，以及所述确定所述支付端的离线支付额度之前还包括，所述服务端判断所述服务端是否存储有所述支付端的离线支付额度，若否，则执行所述确定支付端的离线支付额度及其后续步骤。
258.具体的，在上述步骤501中所述服务端响应于支付端的操作之后，以及在上述步骤501中所述确定所述支付端的离线支付额度之前还包括，所述服务端判断所述服务端是否存储有所述支付端的离线支付额度，若否，则执行所述确定支付端的离线支付额度及其后续步骤，若否，则不执行所述确定支付端的离线支付额度及其后续步骤。
259.可以理解，所述服务端判断所述服务端是否存储有所述支付端的离线支付额度，当所述服务端没有为所述支付端存储离线支付额度，或者存储的离线支付额度为零，或者
存储的离线支付额度已经被释放(如已经被删除、清空、重置为零或失效等)，则判断结果为否。
260.可以理解，如此实施的主要作用在于，所述服务端仅在没有存储所述支付端的离线支付额度，或者存储的离线支付额度为零，或者存储的所述离线支付额度被释放之后，才启动为所述支付端确定离线支付额度。同理，当所述服务端再次响应于为所述支付端确定离线支付额度的操作时，所述服务端先判断存储的所述支付端的离线支付额度是否为零或已经被释放，若否，则所述服务端不启动为所述支付端确定离线支付额度，若是，则所述服务端启动为所述支付端确定离线支付额度及其后续的步骤，即启动执行与上述步骤501至步骤510相同或相似的步骤。
261.还可以理解，如果包括多个甚至大量的支付端，则在存储所述离线支付额度时将所述离线支付额度存储为所述支付端对应的离线支付额度，从而使得在确定离线支付额度时能确定到所述支付端对应的离线支付额度，具体实施方式还可以参考上述步骤502、步骤509中的相关说明，在此不再赘述。
262.第二种实施方式，所述存储所述离线支付额度还包括新增存储所述离线支付额度，以及将所述第一到期时间设置为所述离线支付额度对应的到期时间。
263.具体的，上述步骤501中所述存储所述离线支付额度还包括新增存储所述离线支付额度，其中，新增存储是指在存储所述离线支付额度时不覆盖当前存储的离线支付额度，也可以理解为，当所述服务端再次响应于为所述支付端确定离线支付额度的操作时，对于所述服务端再次确定的所述支付端的离线支付额度，所述服务端是新增存储该再次确定的离线支付额度，并不替换或覆盖当前存储的离线支付额度。可以理解，在确定所述支付端的离线支付额度时，所述服务端还可以根据所述支付端当前存储的离线支付额度确定离线支付额度，例如，所述服务端对所述支付端进行综合评估后确定其总的离线支付额度为1000，而如果其当前存储的离线支付额度为400(相当于所述支付端总的离线支付额度被占用了400)，则再次确定的所述支付端的离线支付额度为600，实际实施过程中，所述服务端还可以根据所述支付端的支付记录、或/和信用等级、或/和用户信息、或/和当前存储的离线支付额度等综合确定离线支付额度。
264.可以理解，对于本第二种实施方式，当所述支付端再次接收到所述服务端下发的离线支付额度，所述支付端在本地保存该离线支付额度时，所述支付端可以以该下发的离线支付额度覆盖本地当前保存的离线支付额度，也可以理解为是将本地当前保存的离线支付额度更新为该下发的离线支付额度，如此，则可以理解，所述支付端上被覆盖的离线支付额度会成为丢失的离线支付额度，而在所述服务端上，一旦所述服务端的当前系统时间达到该被覆盖的离线支付额度在所述服务端上相对应的离线支付额度的第一到期时间，则所述服务端会将该被覆盖的离线支付额度在所述服务端上相对应的离线支付额度进行释放；所述支付端也可以新增保存该离线支付额度，如此，则所述支付端在进行离线支付时，可以设定相应的策略，从本地保存的多个离线支付额度中选用相应的离线支付额度来扣减支付数额。
265.可以理解，对于本第二种实施方式，如果包括多个甚至大量的支付端，则所述服务端在新增存储所述离线支付额度时将所述离线支付额度新增存储为所述支付端对应的离线支付额度，也可以理解为是新增建立所述支付端与所述离线支付额度的对应关系，并不
替换或覆盖所述支付端当前已经对应的离线支付额度，如此，则在所述服务端上，所述支付端可能有多个对应的离线支付额度，因此，所述服务端在从存储的离线支付额度中扣减所述支付数额时，所述服务端可以设定相应的策略，从所述支付端多个对应的离线支付额度中选用相应的离线支付额度来扣减所述支付数额。
266.可以理解，将所述第一到期时间设置为所述离线支付额度对应的到期时间，从而可以使得当所述服务端的当前系统时间达到所述第一到期时间之后的时间时，所述服务端能相应地将所述离线支付额度进行释放，而不是释放没有达到所述第一到期时间的其他离线支付额度。
267.进一步的，如上述步骤502中所述，为了使得所述服务端可以识别每个支付端对应的离线支付额度，所述服务端在存储所述离线支付额度时将所述离线支付额度存储为所述支付端对应的离线支付额度，因此，在上述步骤509中所述服务端从所述服务端存储的所述离线支付额度中扣减所述支付数额时，所述服务端先根据支付端与离线支付额度的对应关系确定对应存储的离线支付额度，例如，如果上述步骤502在实际实施时是在所述支付端所在账户下建立用于离线支付的子账户或配置项，则在本步骤中，所述服务端可以根据所述离线支付凭证中包括的支付端识别信息确定所述支付端所在的账户，再通过所述支付端所在账户下建立的子账户或配置项确定对应的离线支付额度。
268.进一步的，在上述步骤503所述服务端将所述离线支付额度下发给所述支付端之后，所述服务端不将存储的所述离线支付额度下发给支付端，例如不接收支付端重新获取存储的所述离线支付额度的请求，或者不接受后台管理指令以重新向支付端下发存储的所述离线支付额度，也可以是不提供将存储的离线支付额度下发给支付端的功能，以使得支付端不能重新获取所述服务端存储的所述离线支付额度。需要说明的是，这里限定的是不将存储的所述离线支付额度下发给支付端，以此避免支付端可以重复获取到所述离线支付额度，但并非限定所述服务端不再响应于为支付端确定离线支付额度的操作及其后续步骤。
269.对于所述支付端有可能会出现离线支付额度丢失的情况，还有一种可能的解决方法为根据所述支付端的请求或者根据后台管理指令等，所述服务端将存储的所述离线支付额度重新下发给所述支付端，从而使得所述支付端根据该重新下发的离线支付额度继续进行离线支付，但是，该种解决方法至少存在两个方面的问题，一是如果在所述支付端的某次离线支付之后，以及在接收端将该某次离线支付的离线支付凭证发送给所述服务端之前，所述服务端将存储的所述离线支付额度重新下发给所述支付端，则会导致所述支付端该重新获取的离线支付额度超过其实际支付限额的情况，例如，假设当所述支付端本地保存的所述离线支付额度为400、并且所述服务端存储的所述离线支付额度为400时，所述支付端再进行一次离线支付，其中的支付数额为100，则所述支付端从本地保存的所述离线支付额度中减去支付数额100，则本地保存的所述离线支付额度更新为300，即此时所述支付端的实际支付限额应为300，但如果在接收端将该次离线支付的离线支付凭证发送给所述服务端之前，所述服务端将存储的所述离线支付额度重新下发给所述支付端，则因为此时所述服务端还没有从存储的所述离线支付额度中扣减该次离线支付的支付数额100，则所述支付端重新获取的离线支付额度为400，从而导致所述支付端该重新获取的离线支付额度(即400)超过其实际支付限额(即300)的情况；二是所述支付端的用户有可能以其他的支付端
重新获取所述服务端存储的所述离线支付额度，从而导致同一个离线支付额度重复下发给了多个支付端，使得所述支付端的用户在多个支付端上根据该离线支付额度分别进行离线支付，进而导致其实际的离线支付有可能超过其实际支付限额的情况，例如，假设当所述支付端本地保存的所述离线支付额度为400、并且所述服务端存储的所述离线支付额度为400时，所述支付端的用户在其他支付端以账号、或手机号码、或数字证书等登录所述服务端，并且请求重新下发存储的所述离线支付额度，所述服务端将存储的所述离线支付额度(即400)重新下发给该其他支付端，则所述支付端和该其他支付端可以分别以400的离线支付额度进行离线支付，导致所述支付端的用户实际的离线支付有可能超过其实际支付限额的情况。而在本发明实施例中，为了解决支付端发生离线支付额度丢失的情况，如上所述，由于所述服务端可以不将存储的所述离线支付额度下发给所述支付端，因此可以避免所述支付端通过重复获取所述服务端存储的所述离线支付额度而导致其超过实际支付限额的情况。
270.由上实施过程可知，本发明实施例产生的技术效果至少包括，第一，由于在服务端上存储了支付端的离线支付额度，并且根据离线支付凭证从其中扣减支付数额，因此，在服务端上可以获知支付端的离线支付额度的使用情况，例如可以获知离线支付额度的余额、扣减记录等；第二，一旦在支付端发生离线支付额度丢失的情况，由于在一定时间之后(即第一到期时间之后)，服务端会将相应存储的离线支付额度进行释放，从而可以避免服务端上存储的离线支付额度一直得不到扣减的问题；第三，不但可以解决支付端发生离线支付额度丢失的问题，而且由于服务端可以不将存储的离线支付额度重新下发给支付端，因此可以避免支付端通过重复获取服务端存储的离线支付额度而导致其超过实际支付限额的情况；第四，进一步的，当服务端在下发离线支付额度时，还包括下发签名值，该签名值可以作为支付端验证该离线支付额度是否合法的验证信息，以及该签名值可以作为接收端验证离线支付凭证是否合法的验证信息；第五，进一步的，可以限制支付端需在限定的时间内(即第二到期时间之前)根据本地保存的离线支付额度进行离线支付，否则，将不能进行离线支付；第六，进一步的，可以限制接收端需在限定的时间内(即第一到期时间之前)及时地将离线支付凭证发送给服务端，否则，如果服务端在第一到期时间之后接收到离线支付凭证，则会确定该离线支付凭证不合法。
271.需要说明的是，在本文中，术语“包括”、“包含”、“传递”、“发送”或者任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者系统不仅包括那些要素，而且还可以包括没有明确列出的其他要素，或者是还可以包括为这种过程、方法、产品或者系统所固有的要素。
272.术语“第一”、“第二”、“第三”等(如果存在)仅用于将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。应该理解，这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。
273.上述本发明的各实施例序号仅仅为了描述，不代表实施例的优劣。
274.可以以许多方式来实现本发明的方法、支付端、接收端和服务端。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法、支付端、接收端和服务端。用于方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具
体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。
275.以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。