【

具体实施方式

】

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

一、实施环境说明

请参考图1，其示出了本发明所涉及的一种实施环境的结构示意图，其中：

接收端是指数字资产的接收端，用于接收支付端的离线支付，以及用于聚合多种双离线支付方式，例如聚合支付宝、微信支付、央行数字货币及各类银行支付业务等的双离线支付方式，也可以理解为接收端用于支持多种可用于双离线场景下的支付方式或支付通道。接收端既可以是软件程序，也可以是由软件和硬件组合实现的设备，例如，既可以是智能手机、销售终端(POS机)、扫描枪、读码器、PC(个人电脑)、服务器等设备，也可以是智能电视、平板电脑、笔记本电脑、智能手表、智能手环等终端设备，还可以是其他带有通信功能的设备。

对于接收端聚合的多种双离线支付方式，其中，每种支付方式分别有其对应的服务端和支付端，例如，支付宝有支付宝的服务端和支付端(或称为客户端)，微信支付有微信支付的服务端和支付端(或称为客户端)，央行数字货币有央行数字货币的服务端和支付端等。如图1所示示例，接收端连接的支付端包括支付端一和支付端二，接收端连接的服务端包括服务端一和服务端二，其中，支付端一和服务端一分别为支付方式一对应的支付端和服务端，支付端二和服务端二分别为支付方式二对应的支付端和服务端，可以理解，实际实施过程中，接收端还可以聚合支付方式三、支付方式四、支付方式五等更多的支付方式，相应的，每种支付方式分别有其对应的服务端和支付端。

支付端(例如如图1所示的支付端一或支付端二)与接收端之间的信息传递通过本地通信以实现，本地通信是相对与数字资产服务端(例如如图1所示的服务端一或服务端二)的通信方式而言的，即支付端与接收端之间不需经过数字资产服务端以实现相互的信息传递，例如可以包括局域网或近距离通信等方式，其中，近距离通信包括但不限于通过蓝牙、红外线、NFC、WIFI、声波、BLE(低功耗蓝牙)或图形码的通信方式。例如，在支付端和接收端不能与互联网实时通信的环境下，在该环境内建立局域网络，支付端和接收端接入该局域网络，支付端与接收端通过该局域网络相互通信；又例如，支付端与接收端通过蓝牙配对建立蓝牙通道以实现近距离通信；再例如，支付端与接收端通过NFC天线感应以实现近距离通信；还例如，支付端或接收端中的一端对要传递的信息进行编码生成图形码，另一端扫描并解析该图形码以获取要传递的信息，从而通过图形码实现支付端与接收端之间的近距离通信，图形码可以是二维码或条形码，也可以是其它可以通过扫描及解码方式获取其信息的图形。

接收端与服务端(例如如图1所示的服务端一或服务端二)之间的信息传递，既可以由接收端与服务端建立网络连接以实现直接的信息传递，该网络既可以是互联网，也可以是专用的网络；也可以由接收端通过中转设备与服务端实现间接的信息传递。

需要说明的是，本领域技术人员可以理解，图1中示出的实施环境结构并不构成对实施环境的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。图1中示出的实施环境结构仅用于加强对本发明技术的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术信息。

二、一种用于双离线场景下的聚合支付方法实施例一

请参考图2，其示出了本发明提供的一种用于双离线场景下的聚合支付方法实施例一的流程图。本实施例以该方法应用于图1所示实施环境中的接收端来举例说明，该方法可以包括：

步骤201.通过本地通信获取支付端的离线支付凭证，所述离线支付凭证包括相应的数字资产和验证信息。

步骤202.确定所述离线支付凭证对应的支付方式。

步骤203.调用所述支付方式对应的验证方式以根据所述验证信息对所述离线支付凭证进行验证。

步骤204.在验证所述离线支付凭证合法之后，确定所述支付端支付成功。

由此实施过程可知，本发明实施例可以在接收端上整合多种双离线支付方式，使得接收端在接收到离线支付凭证之后，可以在双离线场景下，即可以在支付端和接收端都不能与数字资产服务端进行实时通信的场景下，自动判断和调用该离线支付凭证对应的验证方式进行离线支付验证，不需要使用多个接收端分别接收和验证相应支付方式的离线支付凭证，简化了接收端的操作方式，提高了接收端的使用体验和使用效率。

三、一种用于双离线场景下的聚合支付方法实施例二

请参考图3，其示出了本发明提供的一种用于双离线场景下的聚合支付方法实施例二的流程图。本实施例以该方法应用于图1所示的实施环境中来举例说明，其中，应用于接收端的实施过程是结合了上述一种用于双离线场景下的聚合支付方法实施例一所形成的实施过程，该方法可以包括：

步骤301.支付端生成离线支付凭证，所述离线支付凭证包括相应的数字资产和验证信息。

支付端生成离线支付凭证，所述离线支付凭证包括相应的数字资产和验证信息。可以理解，支付端可以是如图1所示的支付端一或支付端二，为了便于说明，本实施例仅以其中一个支付端为例进行说明。

所述离线支付凭证中包括的相应的数字资产，是支付端支付给接收端的数字资产，在支付端确定要支付给接收端的支付数额之后，支付端根据该支付数额在生成的离线支付凭证中包括相应的数字资产。例如，本发明实施例中的数字资产可以是余额形式的数字资产，假设支付端确定要支付给接收端的支付数额为20，相当于支付端要支付给接收端相应的数字资产为20，则支付端在生成的离线支付凭证中包括20；又例如，本发明实施例中的数字资产还可以是字符串形式的数字资产，以数字货币为例，每个不同的加密字符串分别表示对应的数字货币，假设支付端确定要支付给接收端的支付数额为20，则支付端从支付端当前可用的数字资产中选取面值为20的加密字符串为所述相应的数字资产，或者选取面值总和为20的多个加密字符串为所述相应的数字资产，并且在支付端生成的离线支付凭证中包括该选取的一个或多个加密字符串。

所述离线支付凭证中包括的验证信息，是指用于验证离线支付凭证合法性的信息，例如所述验证信息可以包括商户识别信息、签名值等，以使得接收端根据所述验证信息验证所述离线支付凭证的合法性。

具体的，所述验证信息包括商户识别信息，商户识别信息主要用于在服务端确定数字资产划转时的接收账户，可以是终端设备标识、芯片卡标识、手机号码、账号、数字证书、公钥、基于公钥生成的地址或其他可用于在服务端唯一地确定接收账户的信息。对于接收端聚合的多种双离线支付方式，接收端在每种支付方式对应的服务端上注册的商户识别信息，既可以相同，例如，接收端以手机号码在每种支付方式对应的服务端上分别注册账号，即该手机号码是该接收端在每种支付方式对应的服务端上的商户识别信息，亦即该接收端在每种支付方式对应的服务端上注册的商户识别信息相同；也可以不相同，例如，接收端在服务端一上的注册账号为“UserA”，在服务端二上的注册账号为“UserB”，即接收端在服务端一和服务端二上的商户识别信息分别为“UserA”和“UserB”。

支付端可以有多种方式获取接收端的商户识别信息，具体可以包括：

例如，商户识别信息可以是用户输入的，比如在支付端触发显示操作界面，支付端的用户在支付端的操作界面上输入商户识别信息。

又例如，在生成的图形码中包括商户识别信息，支付端通过扫描及解析该图形码获取该商户识别信息。

还例如，接收端获取预先设置的商户识别信息返回给支付端，以使得支付端在生成的所述离线支付凭证中包括所述预先设置的商户识别信息，比如，支付端向接收端通过本地通信发送支付请求，接收端在接收到所述支付请求时，接收端获取在接收端预先设置的商户识别信息，并且将该预先设置的商户识别信息返回给支付端，从而使得支付端在生成的所述离线支付凭证中包括该预先设置的商户识别信息。其中，接收端获取预先设置的商户识别信息，可以包括：

获取方式一，如果接收端在每种支付方式对应的服务端上注册的商户识别信息相同，即接收端在每种支付方式对应的服务端上注册的是相同的商户识别信息，并且接收端预先设置该相同的商户识别信息，则接收端获取该预先设置的商户识别信息。例如，该商户识别信息既是接收端在服务端一上用于确定接收账户的信息，也是接收端在服务端二上用于确定接收账户的信息，则接收端获取该商户识别信息并且返回给支付端。进一步的，接收端还可以提供对多个商户的支持，具体的，接收端预先建立映射字符串与商户识别信息的对应关系，所述支付请求中还包括映射字符串，接收端根据该映射字符串通过该对应关系获取对应的商户识别信息，例如，接收端预先建立映射字符串一与商户识别信息“User1”的对应关系，以及建立映射字符串二与商户识别信息“User2”的对应关系，其中，商户识别信息“User1”为商户一在每种支付方式对应的服务端上注册的相同的商户识别信息，商户识别信息“User2”为商户二在每种支付方式对应的服务端上注册的相同的商户识别信息，当接收端从所述支付请求中获取的映射字符串为映射字符串一时，则接收端通过对应关系获取的商户识别信息为商户识别信息“User1”，当接收端从所述支付请求中获取的映射字符串为映射字符串二时，则接收端通过对应关系获取的商户识别信息为商户识别信息“User2”。

获取方式二，如果接收端在每种支付方式对应的服务端上注册的商户识别信息不相同，并且接收端预先建立有支付识别信息与商户识别信息的对应关系，根据所述支付请求获取支付识别信息，并且根据该支付识别信息通过该对应关系获取对应的商户识别信息。例如，接收端建立支付识别信息“Pay1”与商户识别信息“UserA”的对应关系，以及建立支付识别信息“Pay2”与商户识别信息“UserB”的对应关系，其中，支付识别信息“Pay1”为支付方式一的支付识别信息，支付识别信息“Pay2”为支付方式二的支付识别信息，商户识别信息“UserA”为接收端在服务端一上注册的商户识别信息，商户识别信息“UserB”为接收端在服务端二上注册的商户识别信息，当接收端从所述支付请求中获取的支付识别信息为“Pay1”时，则接收端根据该支付识别信息“Pay1”通过对应关系获取的对应的商户识别信息为“UserA”，当接收端从所述支付请求中获取的支付识别信息为“Pay2”时，则接收端根据该支付识别信息“Pay2”通过对应关系获取的对应的商户识别信息为“UserB”。进一步的，接收端还可以提供对多个商户的支持，具体的，接收端预先建立支付识别信息、映射字符串与商户识别信息的对应关系，在所述支付请求中还包括映射字符串，接收端根据所述支付识别信息和该映射字符串通过该对应关系获取对应的商户识别信息，例如，接收端预先建立映射字符串一、支付识别信息“Pay1”与商户识别信息“User1A”的对应关系，以及建立映射字符串一、支付识别信息“Pay2”与商户识别信息“User1B”的对应关系，其中，商户识别信息“User1A”为商户一在服务端一上注册的商户识别信息，商户识别信息“User1B”为商户一在服务端二上注册的商户识别信息，当接收端从所述支付请求中获取到映射字符串一和支付识别信息“Pay1”时，则接收端根据映射字符串一和支付识别信息“Pay1”通过对应关系获取到的对应的商户识别信息为“User1A”，当接收端从所述支付请求中获取到映射字符串一和支付识别信息“Pay2”时，则接收端根据映射字符串一和支付识别信息“Pay2”通过对应关系获取到的对应的商户识别信息为“User1B”；如此，接收端还可以为商户二预先建立映射字符串二、支付识别信息“Pay1”与商户识别信息“User2A”的对应关系，以及建立映射字符串二、支付识别信息“Pay2”与商户识别信息“User2B”的对应关系,其中，商户识别信息“User2A”为商户二在服务端一上注册的商户识别信息，商户识别信息“User2B”为商户二在服务端二上注册的商户识别信息等，依此类推，在此不再赘述。

具体的，为了防止离线支付凭证被篡改，支付端还可以对所述离线支付凭证中的关键信息进行数字签名以生成签名值，即所述验证信息还可以包括所述签名值，即支付端对待签名信息进行数字签名以生成签名值，所述待签名信息包括所述离线支付凭证中相应的数字资产，进一步的，所述待签名信息还可以包括商户识别信息等信息。

可以理解，数字签名是指附加在数据单元上的数据，或是对数据单元所作的密码变换，这种数据或变换允许数据单元的验证方(如接收端或服务端)用以确认数据单元的来源和完整性，并保护数据防止被伪造或抵赖。

在数字签名的一种实现方式中，使用非对称加密算法进行数字签名以生成所述签名值，例如，支付端使用哈希算法对所述待签名信息进行哈希计算得到哈希值(即信息摘要)，支付端使用支付端的私钥对该哈希值加密得到加密结果(即签名值)。

在实际实施过程中，可以有多种方式触发支付端生成离线支付凭证，例如，在行驶的飞机等不能与互联网实时通信的环境内建立局域网络，接收端为在该局域网络内用于接收离线支付的服务器，应用服务器为在该局域网络内用于提供应用服务(如购物、观影)的服务器，支付端为乘客的移动终端，支付端在访问应用服务器时触发购买相应的服务，应用服务器从接收端获取该接收端的商户识别信息，或者应用服务器获取在应用服务器上预先设置的商户识别信息，在应用服务器返回给支付端的调用指令中包括该商户识别信息和购买相应服务所需的支付数额，则支付端根据该调用指令生成离线支付凭证，该离线支付凭证中包括该商户识别信息和该支付数额(即相应的数字资产)；又例如，支付端在访问应用服务器时触发购买相应的服务时，应用服务器向支付端返回重定向指令，该重定向指令中包括购买相应服务所需的支付数额，并且将支付端重定向接收端，接收端向支付端返回商户识别信息，支付端据此生成离线支付凭证，该离线支付凭证中包括该商户识别信息和该支付数额(即相应的数字资产)；再例如，接收端生成包括商户识别信息的图形码，支付端通过扫描及解析该图形码获取到该商户识别信息，并且在支付端触发显示操作界面，支付端的用户在支付端的操作界面上输入支付数额，支付端根据该支付数额选取面值为该支付数额的加密字符串，并且生成离线支付凭证，该离线支付凭证中包括该商户识别信息和该选取的加密字符串(即相应的数字资产)；还例如，接收端通过NFC向支付端传递支付数额，支付端生成离线支付凭证，该离线支付凭证中包括该支付数额(即相应的数字资产)。此外，还可以以其他方式触发支付端生成离线支付凭证，对此本发明实施例并不进行限定。

步骤302.支付端将所述离线支付凭证通过本地通信传递给接收端。

支付端通过本地通信向接收端传递所述离线支付凭证，如实施环境说明中所述，支付端可以通过局域网向接收端传递所述离线支付凭证，也可以通过蓝牙、红外线、NFC、WIFI、声波、BLE(低功耗蓝牙)或图形码等近距离通信方式向接收端传递所述离线支付凭证。

需要说明的是，由于本地通信可以包括多种通信方式，即使步骤301中支付端获取的商户识别信息是由支付端通过本地通信方式向接收端获取的，本步骤所使用的本地通信方式也不一定需与步骤301中的本地通信方式相同。例如，在步骤301中支付端通过扫描及解析图形码的方式获取商户识别信息，而在本步骤中，支付端既可以通过图形码的方式向接收端传递所述离线支付凭证，也可以通过局域网、NFC等其他的通信方式向接收端传递所述离线支付凭证。

相应的，接收端通过本地通信接收及获取支付端传递的所述离线支付凭证。

步骤303.接收端确定所述离线支付凭证对应的支付方式。

接收端确定所述离线支付凭证对应的支付方式，也可以理解为是确定所述离线支付凭证所属的支付方式类型，即确定所述离线支付凭证是属于哪种支付方式的离线支付凭证。还可以理解，每种支付方式的支付端生成的离线支付凭证对应的支付方式属于该种支付方式，例如，支付端一生成的离线支付凭证对应的支付方式为支付方式一，支付端二生成的离线支付凭证对应的支付方式为支付方式二。

具体的，接收端确定所述离线支付凭证对应的支付方式，可以包括多种实施方式：

实施方式一，获取所述离线支付凭证对应的支付识别信息，所述支付识别信息用于标识对应的支付方式。

支付识别信息是指可用于标识支付方式的识别信息，例如，对于支付方式一和支付方式二，可以通过支付识别信息“Pay1”和“Pay2”分别标识支付方式一和支付方式二。

接收端获取所述离线支付凭证对应的支付识别信息，具体可以包括：

例如，所述离线支付凭证中包括支付端的支付识别信息，从所述离线支付凭证中获取所述支付识别信息。具体的，支付端在生成的所述离线支付凭证中包括该支付端的支付识别信息，则接收端从所述离线支付凭证中获取该支付识别信息，该支付识别信息标识了所述离线支付凭证对应的支付方式。比如，支付端一在生成的离线支付凭证中包括的支付识别信息为“Pay1”，支付端二在生成的离线支付凭证中包括的支付识别信息为“Pay2”，则如果接收端从所述离线支付凭证中获取的支付识别信息为“Pay1”，则表明所述离线支付凭证是属于支付方式一的离线支付凭证，如果接收端从所述离线支付凭证中获取的支付识别信息为“Pay2”，则表明所述离线支付凭证是属于支付方式二的离线支付凭证。

又例如，支付端在通过局域网络发送所述离线支付凭证时还携带有支付端的客户端识别信息，则接收端根据该客户端识别信息获取所述支付识别信息，比如，UserAgent(用户代理)是在浏览器等客户端中携带的一种客户端识别信息，能够识别客户端所使用的操作系统及版本、CPU类型、浏览器及版本、浏览器语言、浏览器插件等，以支付宝为例，在支付宝客户端携带的客户端识别信息(UserAgent)中包含了“AlipayClient”，以微信支付为例，在微信客户端携带的客户端识别信息(UserAgent)中包含了“MicroMessenger”，因此，如果接收端从支付端发送所述离线支付凭证时携带的客户端识别信息中获取到“AlipayClient”，则表明所述离线支付凭证是属于支付宝支付方式的离线支付凭证，如果接收端从支付端发送所述离线支付凭证时携带的客户端识别信息中获取到“MicroMessenger”，则表明所述离线支付凭证是属于微信支付方式的离线支付凭证。

如此也可以理解，上述步骤301获取方式二中接收端根据所述支付请求获取支付识别信息，既可以是在所述支付请求中包括支付识别信息，接收端从所述支付请求中获取该支付识别信息，比如，支付端一在发送的支付请求中包括的支付识别信息为支付识别信息一，支付端二在发送的支付请求中包括的支付识别信息为支付识别信息二，则如果是支付端一发送所述支付请求，则接收端从所述支付请求中获取的支付识别信息为支付识别信息一，如果是支付端二发送所述支付请求，则接收端从所述支付请求中获取的支付识别信息为支付识别信息二；也可以是支付端在所述支付请求中携带客户端识别信息，接收端根据该携带的客户端识别信息获取支付识别信息。

还例如，根据接收端与支付端的会话状态获取关联的支付识别信息为所述支付识别信息，具体的，接收端与支付端保持有会话状态，该会话状态与支付识别信息相关联，接收端在接收到所述离线支付凭证时，根据该会话状态获取关联的支付识别信息。例如，以步骤301中的获取方式二为例，在支付端向接收端通过本地通信发送支付请求，以及在接收端根据该支付请求获取到支付识别信息之后，接收端保持与支付端的会话状态，并且将该会话状态与该支付识别信息相关联，则接收端在接收到支付端发送的所述离线支付凭证时，可以根据该会话状态获取到关联的支付识别信息，即根据所述会话状态获取到所述支付识别信息。

实施方式二，根据预先设定的数据格式规则对所述离线支付凭证的格式进行识别，从而确定所述离线支付凭证对应的支付方式。

具体的，每种支付方式的离线支付凭证在数据长度、或/和其中包含的字符类型、或/和其中包含的特定标识等方面有其特定的数据格式规则，则接收端可以根据预先设定的数据格式规则对所述离线支付凭证的格式进行识别，例如对所述离线支付凭证的数据长度、或/和包含的字符类型、或/和包含的特定标识等方面进行识别，从而确定所述离线支付凭证对应的支付方式。

步骤304.接收端调用所述支付方式对应的验证方式以根据所述验证信息对所述离线支付凭证进行验证。

在上述步骤303接收端确定所述离线支付凭证对应的支付方式之后，接收端调用所述支付方式对应的验证方式以根据所述验证信息对所述离线支付凭证进行验证，可以理解，本实施例中的验证方式是指对离线支付凭证进行离线验证的验证方式，由于每种支付方式所生成的离线支付凭证存在相应的区别，因此，每种支付方式有每种支付方式对应的验证方式，本步骤中接收端调用对应于所述支付方式的验证方式对所述离线支付凭证进行验证。例如，如果步骤303确定的所述支付方式为支付方式一，则调用第一种验证方式对所述离线支付凭证进行验证，该第一种验证方式为该支付方式一所对应的验证方式，如果步骤303确定的所述支付方式为支付方式二，则调用第二种验证方式对所述离线支付凭证进行验证，该第二种验证方式为该支付方式二所对应的验证方式；又以支付宝支付和微信支付为例，如果步骤303获取的支付识别信息为“AlipayClient”，则调用支付宝的验证方式对所述离线支付凭证进行验证，如果步骤303获取的支付识别信息为“MicroMessenger”，则调用微信支付的验证方式对所述离线支付凭证进行验证。

可以理解，接收端还可以调用所述支付方式对应的验证SDK以根据所述验证信息对所述离线支付凭证进行验证。具体的，每种支付方式发布对自己支付方式的离线支付验证SDK(开发工具包)，例如微信支付发布用于微信离线支付凭证的验证SDK，支付宝发布用于支付宝离线支付凭证的验证SDK，则在接收端上集成该多种验证SDK，并且根据上述步骤303所确定的支付方式调用对应的验证SDK以对所述离线支付凭证进行验证。

具体的，每种支付方式对应的验证方式可以包括多种具体的验证方式，其中可以包括：

验证方式一，即商户验证方式，所述验证信息包括商户识别信息，获取接收端的商户识别信息，判断所述接收端的商户识别信息与所述包括的商户识别信息是否一致，若一致，则确定验证通过。

具体的，对于要验证的离线支付凭证，该离线支付凭证中的验证信息包括商户识别信息，如上述步骤301中所述，所述验证信息包括商户识别信息，接收端获取所述包括的商户识别信息，也可以理解为获取所述离线支付凭证中包括的商户识别信息，接收端将接收端的商户识别信息与所述包括的商户识别信息进行比较，若二者一致，则表明所述离线支付凭证是属于发送给该接收端的离线支付凭证，而不是用于发送给其他接收端的离线支付凭证，确定验证通过；否则，则表明所述离线支付凭证不是发送给该接收端的离线支付凭证，确定验证不通过。

可以理解，实际实施过程中，接收端的商户识别信息可以不限于一个，也可以包括多个商户识别信息，如此，接收端可以将该多个商户识别信息与所述包括的商户识别信息进行比较，如果有任意一个商户识别信息与所述包括的商户识别信息相一致，则确定验证通过。进一步的，还可以对商户识别信息确定相应的类型，则接收端还可以从该多个商户识别信息中确定与所述包括的商户识别信息的类型相一致的商户识别信息，再将两者进行比较等。

接收端获取接收端的商户识别信息，可以包括多种实施方式：

例如，如果接收端在每种支付方式对应的服务端上注册的商户识别信息相同，则接收端预先设置该相同的商户识别信息，接收端获取该预先设置的商户识别信息为所述接收端的商户识别信息。具体的实施方式还可以参考上述步骤301中获取方式一的相关说明和示例，在此不再赘述。

又例如，如果接收端在每种支付方式对应的服务端上注册的商户识别信息不相同，则接收端预先建立支付方式与商户识别信息的对应关系，接收端根据所述支付方式通过该对应关系获取对应的商户识别信息为所述接收端的商户识别信息。具体的实施方式还可以参考上述步骤301中获取方式二的相关说明和示例，在此不再赘述。

再例如，如果接收端在每种支付方式对应的服务端上注册的商户识别信息不相同，则每种支付方式对应的验证方式还设置对应的商户识别信息，以此使得每种支付方式对应的验证方式获取对应的商户识别信息为所述接收端的商户识别信息。比如，商户识别信息“UserA”为接收端在服务端一上注册的商户识别信息，商户识别信息“UserB”为接收端在服务端二上注册的商户识别信息，则第一种验证方式设置对应的商户识别信息为“UserA”，第二种验证方式设置对应的商户识别信息为“UserB”，因此，当接收端调用第一种验证方式进行验证时，则获取的接收端的商户识别信息为“UserA”，当接收端调用第二种验证方式进行验证时，则获取的接收端的商户识别信息为“UserB”。

还例如，接收端与支付端保持有会话状态，该会话状态与商户识别信息相关联，接收端在接收到所述离线支付凭证时，根据该会话状态获取关联的商户识别信息。例如，以步骤301中的支付端向接收端通过本地通信发送支付请求为例，在接收端将预先设置的商户识别信息返回给支付端时，接收端保持与支付端的会话状态，并且将该会话状态与该商户识别信息相关联，则接收端在接收到支付端发送的所述离线支付凭证时，可以根据该会话状态获取到关联的商户识别信息，即根据该会话状态获取到商户识别信息。

可以理解，如果上述步骤301中接收端获取预先设置的商户识别信息返回给支付端，则该获取的预先设置的商户识别信息与本步骤中获取的接收端的商户识别信息应当是一致的，如此才可以使得判断所述接收端的商户识别信息与所述包括的商户识别信息是一致的，也正因为如此，本步骤上述示例的获取接收端的商户识别信息的实施方式与步骤301中示例的接收端获取预先设置的商户识别信息的实施方式(如获取方式一、获取方式二)存在相同或相似。

验证方式二，即签名验证方式，所述验证信息包括签名值，所述签名值为所述支付端对待签名信息进行数字签名生成的签名值，所述待签名信息包括所述相应的数字资产，使用对应的数字签名验证方式根据所述签名值对所述离线支付凭证进行数字签名验证。

如上述步骤301中所述，支付端还可以对待签名信息进行数字签名以生成签名值，即所述验证信息包括签名值，则接收端使用对应的数字签名验证方式根据所述签名值对所述离线支付凭证进行数字签名验证。

具体的，对于要验证的离线支付凭证，该离线支付凭证中的验证信息包括签名值，如上述步骤301中所述，所述验证信息包括签名值，接收端生成待校验信息，并且生成方式与支付端生成待签名信息的生成方式相同，从而使得该生成的待校验信息与支付端生成的待签名信息相同。可以理解，该生成的待校验信息至少包括所述相应的数字资产，如果支付端生成的待签名信息中还包括所述商户识别信息或/和其他的信息，则该生成的待校验信息中也包括所述商户识别信息或/和相同的其他信息，从而使得该生成的待校验信息与支付端生成的待签名信息相同。

接收端获取所述支付端的公钥，接收端使用该公钥解密所述签名值得到解密结果(即信息摘要)，并且接收端使用相同的哈希算法对所述待校验信息进行哈希计算得到哈希值(即校验值)，比较该解密结果(即信息摘要)与该校验值是否相同，若相同，则确定数字签名验证通过，否则，则确定验证不通过。

接收端可以有多种方式获取支付端的公钥，例如，当支付端基于IBC(Identity-Based Cryptograph)产生的私钥对所述待签名信息进行数字签名，并且以支付端识别信息作为支付端的公钥时，在所述离线支付凭证中包括该支付端识别信息，则接收端获取该支付端识别信息作为支付端的公钥；又例如，当支付端基于PKI(Public KeyInfrastructure)体系产生的私钥对所述待签名信息进行数字签名时，支付端可以在向接收端传递所述离线支付凭证时还包括传递支付端的数字证书，如此接收端从该数字证书中获取支付端的公钥，可以理解，实际应用过程中，还应当使用预置的根证书验证该支付端的数字证书是否合法。

需要说明的是，由于每种支付方式在数字签名的验证方式上可能存在的不同，例如数字签名验证相关的加密算法、待校验信息的生成方式、公钥、根证书和公共参数等都可能存在不同，因此，本验证方式二中使用对应的数字签名验证方式根据所述签名值对所述离线支付凭证进行数字签名验证的验证方式，亦即调用所述支付方式对应的数字签名验证方式进行验证，该数字签名验证方式中包括的数字签名验证相关的加密算法、或/和待校验信息生成方式、或/和公钥、或/和根证书、或/和公共参数等都是与所述支付方式对应的，从而使得可以对所述离线支付凭证进行数字签名验证。

可以理解，对于上述每种支付方式对应的验证方式，只有实施的验证方式都确定验证通过，才确定所述离线支付凭证合法，否则，若任一验证方式为验证不通过，则确定所述离线支付凭证不合法。可以理解，当某支付方式对应的验证方式只实施上述验证方式一或验证方式二时，若验证方式一或验证方式二确定验证通过，则确定所述离线支付凭证合法，否则，若验证方式一或验证方式二验证不通过，则确定所述离线支付凭证不合法。也可以理解，当某支付方式对应的验证方式同时实施上述验证方式一和验证方式二时，只有验证方式一和验证方式二都确定验证通过，才确定所述离线支付凭证合法，否则，若验证方式一或验证方式二为验证不通过，则确定所述离线支付凭证不合法。

步骤305.在验证所述离线支付凭证合法之后，确定所述支付端支付成功。

接收端在验证所述离线支付凭证合法之后，则确定所述支付端支付成功，也可以理解为认可该次支付。以行驶的飞机为例，例如，在确定支付端支付成功之后，则乘务员可以为支付成功的乘客提供相应的商品或服务；又例如，支付端在访问应用服务器时触发购买相应的服务，并且向接收端发送所述离线支付凭证，则接收端在确定支付端支付成功之后，向应用服务器反馈表示支付成功的信息，则应用服务器确定支付端购买成功，并且向支付端提供该相应的服务。

可选的，接收端将所述离线支付凭证发送给所述支付方式对应的服务端，以使得所述对应的服务端根据所述离线支付凭证进行数字资产的划转。

接收端将所述离线支付凭证发送给所述支付方式对应的服务端，例如，如果步骤303确定的所述支付方式为支付方式一，则将所述离线支付凭证发送给支付方式一对应的服务端(即服务端一)，如果步骤303确定的所述支付方式为支付方式二，则将所述离线支付凭证发送给支付方式二对应的服务端(即服务端二)；又例如，以支付宝支付和微信支付为例，如果步骤303获取的支付识别信息为“AlipayClient”，则将所述离线支付凭证发送给支付宝的服务端，如果步骤303获取的支付识别信息为“MicroMessenger”，则将所述离线支付凭证发送给微信支付的服务端。

接收端将所述离线支付凭证发送给所述支付方式对应的服务端，既可以由接收端与服务端建立网络连接，由接收端直接将所述离线支付凭证发送给所述对应的服务端，例如，以行驶的飞机为例，在飞机落地之后，接收端接入移动互联网并与所述对应的服务端建立网络连接，由接收端将所述离线支付凭证发送给所述对应的服务端；也可以由接收端间接地将所述离线支付凭证发送给所述对应的服务端，即接收端通过中转设备(如收款服务器等收款设备)将所述离线支付凭证发送给所述对应的服务端，例如，在飞机上部署有收款设备，接收端将所述离线支付凭证同步给收款设备，当飞机落地之后，收款设备与所述对应的服务端建立网络连接，收款设备将所述离线支付凭证发送给所述对应的服务端；又例如，在飞机落地之后，接收端接入移动互联网并与航空公司的收款服务器建立网络连接，接收端将所述离线支付凭证同步给该收款服务器，该收款服务器将所述离线支付凭证通过网络发送给所述对应的服务端。

在接收端将所述离线支付凭证发送给所述支付方式对应的服务端之后，则所述对应的服务端可以根据所述离线支付凭证进行数字资产的划转。例如，所述对应的服务端获取所述离线支付凭证发送方(如接收端或中转设备等)的身份识别信息，将所述相应的数字资产划转给该身份识别信息所在的账户；又例如，如果所述离线支付凭证中包括商户识别信息，则可以将所述相应的数字资产划转给该商户识别信息所在的账户。

上述实施过程，接收端通过本地通信获取支付端的离线支付凭证，并且确定所述离线支付凭证对应的支付方式，调用所述支付方式对应的验证方式对所述离线支付凭证进行验证，在验证所述离线支付凭证合法之后，确定所述支付端支付成功。由此实施过程可知，本发明实施例可以在接收端上整合多种双离线支付方式，使得接收端在接收到离线支付凭证之后，可以在双离线场景下，即可以在支付端和接收端都不能与数字资产服务端进行实时通信的场景下，自动判断和调用该离线支付凭证对应的验证方式以进行离线支付验证，不需要使用多个接收端分别接收和验证相应支付方式的离线支付凭证，简化了接收端的操作方式，提高了接收端的使用体验和使用效率。

四、一种用于双离线场景下的聚合支付装置实施例一、实施例二

请参考图4，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例一的结构示意图。为了便于说明，仅示出了与本发明实施例相关的部份。所述装置包括：

获取模块，用于通过本地通信获取支付端的离线支付凭证，所述离线支付凭证包括相应的数字资产和验证信息；

识别模块，用于确定所述离线支付凭证对应的支付方式；

调用模块，用于调用所述支付方式对应的验证模块以根据所述验证信息对所述离线支付凭证进行验证，其中包括，若所述支付方式为支付方式一，则调用验证模块一，若所述支付方式为支付方式二，则调用验证模块二；

所述验证模块一，用于对支付方式为所述支付方式一的离线支付凭证进行验证；

所述验证模块二，用于对支付方式为所述支付方式二的离线支付凭证进行验证；

接受模块，用于在验证所述离线支付凭证合法之后，确定所述支付端支付成功。

优选的，所述识别模块包括：

获取识别单元，用于获取所述离线支付凭证对应的支付识别信息，所述支付识别信息用于标识对应的支付方式；或者，

格式识别单元，用于根据预先设定的数据格式规则对所述离线支付凭证的格式进行识别，从而确定所述离线支付凭证对应的支付方式。

优选的，所述获取识别单元包括：

获取识别子单元一，用于从所述离线支付凭证中获取所述支付识别信息，所述离线支付凭证中包括所述支付端的支付识别信息；或者，

获取识别子单元二，用于根据所述支付端在发送所述离线支付凭证时携带的客户端识别信息获取所述支付识别信息；或者，

获取识别子单元三，用于根据所述接收端与所述支付端的会话状态获取关联的支付识别信息为所述支付识别信息。

请参考图5，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例二的结构示意图，该装置是在上述一种用于双离线场景下的聚合支付装置实施例一提供的装置上，所述验证模块一包括商户验证单元一和签名验证单元一，以及所述验证模块二包括商户验证单元二和签名验证单元二，其中：

所述商户验证单元一，用于若所述验证信息包括商户识别信息，则获取该包括的商户识别信息，以及获取所述接收端的商户识别信息，判断所述接收端的商户识别信息与该包括的商户识别信息是否一致，若一致，则确定验证通过；

所述签名验证单元一，用于若所述验证信息包括签名值，该签名值为所述支付端对待签名信息进行数字签名生成的签名值，该待签名信息包括所述相应的数字资产，则根据该签名值对所述离线支付凭证进行数字签名验证，其中，该数字签名验证的验证方式为所述支付方式一所对应的数字签名验证方式；

所述商户验证单元二，用于若所述验证信息包括商户识别信息，则获取该包括的商户识别信息，以及获取所述接收端的商户识别信息，判断所述接收端的商户识别信息与该包括的商户识别信息是否一致，若一致，则确定验证通过；

所述签名验证单元二，用于若所述验证信息包括签名值，该签名值为所述支付端对待签名信息进行数字签名生成的签名值，该待签名信息包括所述相应的数字资产，则根据该签名值对所述离线支付凭证进行数字签名验证，其中，该数字签名验证的验证方式为所述支付方式二所对应的数字签名验证方式；

对于所述验证模块一或所述验证模块二，只有当包括的验证单元在执行时都确定验证通过，才确定所述离线支付凭证合法，否则，若任一验证单元为验证不通过，则确定所述离线支付凭证不合法。

可以理解，实际实施过程中，所述验证模块一可以选用所述商户验证单元一或/和所述签名验证单元一进行实施，所述验证模块二可以选用所述商户验证单元二或/和所述签名验证单元二进行实施，即所述验证模块一包括商户验证单元一或/和签名验证单元一，或/和，所述验证模块二包括商户验证单元二或/和签名验证单元二。

五、一种用于双离线场景下的聚合支付装置实施例三、实施例四

对于上述一种用于双离线场景下的聚合支付装置实施例二所提供的装置，当所述验证模块一包括所述商户验证单元一，以及所述验证模块二包括所述商户验证单元二，并且若所述接收端在所述支付方式一和所述支付方式二对应的服务端上注册的是相同的商户识别信息，该装置还可以包括存储单元一或者存储单元二。

请参考图6，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例三的结构示意图，该结构示意图中所述装置还包括所述存储单元一，其中：

所述存储单元一用于预先存储所述相同的商户识别信息，所述调用模块还用于从所述存储单元一中获取所述相同的商户识别信息，在所述调用验证模块一时，将所述相同的商户识别信息传递给所述商户验证单元一，以使得所述商户验证单元一获取所述相同的商户识别信息为所述接收端的商户识别信息，在所述调用验证模块二时，将所述相同的商户识别信息传递给所述商户验证单元二，以使得所述商户验证单元二获取所述相同的商户识别信息为所述接收端的商户识别信息。

请参考图7，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例四的结构示意图，该结构示意图中所述装置还包括所述存储单元二，其中：

所述存储单元二用于预先存储所述相同的商户识别信息，所述商户验证单元一和所述商户验证单元二从所述存储单元二中获取所述相同的商户识别信息为所述接收端的商户识别信息。

六、一种用于双离线场景下的聚合支付装置实施例五、实施例六

对于上述一种用于双离线场景下的聚合支付装置实施例二所提供的装置，当所述验证模块一包括所述商户验证单元一，以及所述验证模块二包括所述商户验证单元二，并且若所述接收端在所述支付方式一和所述支付方式二对应的服务端上注册的是不相同的商户识别信息，其中，所述接收端在所述支付方式一对应的服务端上注册的商户识别信息为商户识别信息一，所述接收端在所述支付方式二对应的服务端上注册的商户识别信息为商户识别信息二，则所述装置还可以包括存储单元三，或者所述装置还可以包括存储单元四和存储单元五。

请参考图8，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例五的结构示意图，该结构示意图中所述装置还包括所述存储单元三，其中：

所述存储单元三用于预先存储支付方式与商户识别信息的对应关系，具体包括，预先存储所述支付方式一与所述商户识别信息一的对应关系，以及预先存储所述支付方式二与所述商户识别信息二的对应关系；

所述调用模块还用于根据所述支付方式在所述存储单元三中通过该对应关系获取对应的商户识别信息为所述接收端的商户识别信息，具体包括，当所述支付方式为所述支付方式一时，则获取的商户识别信息为所述商户识别信息一，并且在所述调用验证模块一时，将所述商户识别信息一传递给所述商户验证单元一，以使得所述商户验证单元一获取所述商户识别信息一为所述接收端的商户识别信息，当所述支付方式为所述支付方式二时，则获取的商户识别信息为所述商户识别信息二，并且在所述调用验证模块二时，将所述商户识别信息二传递给所述商户验证单元二，以使得所述商户验证单元二获取所述商户识别信息二为所述接收端的商户识别信息。

请参考图9，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例六的结构示意图，该结构示意图中所述装置还包括所述存储单元四和所述存储单元五，其中：

所述存储单元四用于存储所述商户识别信息一，所述存储单元五用于存储所述商户识别信息二，所述商户验证单元一从所述存储单元四中获取所述商户识别信息一为所述接收端的商户识别信息，所述商户验证单元二从所述存储单元五中获取所述商户识别信息二为所述接收端的商户识别信息。

七、一种用于双离线场景下的聚合支付装置实施例七

对于上述一种用于双离线场景下的聚合支付装置实施例二所提供的装置，当所述验证模块一包括所述商户验证单元一，所述验证模块二包括所述商户验证单元二时，所述装置还可以包括商户返回模块。

请参考图10，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例七的结构示意图，该结构示意图中所述装置还包括所述商户返回模块，其中：

所述商户返回模块用于获取预先设置的商户识别信息返回给所述支付端，以使得所述支付端在生成的所述离线支付凭证中包括所述预先设置的商户识别信息。

上述一种用于双离线场景下的聚合支付装置实施例七还可以与上述一种用于双离线场景下的聚合支付装置实施例三至实施例六中的任一实施例组成可选的实施例，即上述一种用于双离线场景下的聚合支付装置实施例三至实施例六中的任一实施例还包括所述商户返回模块。

八、一种用于双离线场景下的聚合支付装置实施例八

请参考图11，其示出了本发明提供的一种用于双离线场景下的聚合支付装置实施例八的结构示意图。该装置在上述一种用于双离线场景下的聚合支付装置实施例一提供的装置上，还包括如下模块：

发送模块，用于将所述离线支付凭证发送给所述支付方式对应的服务端，以使得所述对应的服务端根据所述离线支付凭证进行数字资产的划转。

上述一种用于双离线场景下的聚合支付装置实施例八还可以与上述一种用于双离线场景下的聚合支付装置实施例二至实施例七中的任一实施例组成可选的实施例，即上述一种用于双离线场景下的聚合支付装置实施例二至实施例七中的任一实施例还包括所述发送模块。

上述一种用于双离线场景下的聚合支付装置实施例一至实施例八提供的装置与上述一种一种用于双离线场景下的聚合支付方法实施例二中应用于接收端的实施过程属于同一构思，其具体实现原理和效果可详见方法实施例，在此不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”、“传递”、“发送”或者任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者系统不仅包括那些要素，而且还可以包括没有明确列出的其他要素，或者是还可以包括为这种过程、方法、产品或者系统所固有的要素。

术语“第一”、“第二”、“第三”等(如果存在)仅用于将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。应该理解，这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。

上述本发明的各实施例序号仅仅为了描述，不代表实施例的优劣。

可以以许多方式来实现本发明的方法、装置及接收端。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法、装置及接收端。用于方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。