CN111815326A - 一种飞行状态下的支付方法及其装置、设备和存储介质 - Google Patents

Abstract

本申请实施例提供一种飞行状态下的支付方法及其装置、设备和存储介质，其中，所述方法包括：当在飞行状态下商户收单系统未与支付系统建立连接时，所述商户收单系统获取用户的支付信息；对所述支付信息进行验证，得到第一验证结果；如果所述第一验证结果为验证通过，基于所述支付信息生成订单信息，并基于所述订单信息完成与所述用户之间的交易；在所述商户收单系统与所述支付系统建立连接时，将所述订单信息发送给所述支付系统，以使得所述支付系统发起对所述用户的扣费。

Description

一种飞行状态下的支付方法及其装置、设备和存储介质

技术领域

本申请涉及计算机技术领域，涉及但不限于一种飞行状态下的支付方法及 其装置、设备和存储介质。

背景技术

随着移动通信技术以及电子商务的发展，人们的工作、生活以及娱乐也发 生了翻天覆地的变化。人们在购物、娱乐时不再仅仅依赖现金支付或刷卡支付， 而扫码支付成为应用越来越广泛的支付方式。

扫码支付可以是买家扫描商户提供的收款二维码，然后由用户输入支付金 额以进行支付。当然也可以是商户扫描买家出示的付款二维码，由商家输入收 款金额，进行收款。但是这两种方式一般情况下需要商户或买家与发码平台、 支付系统建立有通信连接，以能够进行订单信息的确认或者生成付款二维码。 但是例如飞机在航行过程中，用户处于无网环境下，又想要进行扫码支付。因 此如何在飞行状态所处的无网环境下提供一种安全的支付方法成为目前亟待解 决的技术问题。

发明内容

有鉴于此，本申请实施例期望提供一种飞行状态下的支付方法及其装置、 设备和存储介质，能够在商家收单系统和支付系统在断开连接的情况下，如果 商家收单系统对支付信息验证通过，则能够完成交易，从而实现安全支付。

本申请实施例提供一种飞行状态下的支付方法，所述方法包括：

当在飞行状态下商户收单系统未与支付系统建立连接时，所述商户收单系 统获取用户的支付信息；

对所述支付信息进行验证，得到第一验证结果；

如果所述第一验证结果为验证通过，基于所述支付信息生成订单信息，并 基于所述订单信息完成与所述用户之间的交易；

在所述商户收单系统与所述支付系统建立连接时，将所述订单信息发送给 所述支付系统，以使得所述支付系统发起对所述用户的扣费。

本申请实施例提供一种飞行状态下的支付方法，所述方法包括：

支付系统接收商户收单系统发送的订单信息；

对所述订单信息进行校验；

当所述订单信息校验通过后，将所述订单信息发送给发码平台，以通知发 码平台进行扣款；

基于接收到的扣款成功消息，所述支付系统进行对账和资金结算。

本申请实施例提供一种飞行状态下的支付方法，所述方法包括：

发码平台接收支付系统发送的订单信息，所述订单信息至少包括订单号、 支付金额、离线支付标识码信息；

对所述订单号和所述离线支付标识码信息进行验证；

如果所述订单号和所述离线支付标识码信息验证通过，基于所述支付金额， 对所述订单信息对应的用户账户进行扣款；

将扣款成功消息发送给所述订单信息对应的终端和支付系统。

本申请实施例提供一种支付装置，所述支付装置包括：第一获取模块、第 一验证模块、第一生成模块和第一发送模块，其中：

所述第一获取模块，用于当在飞行状态下自身未与支付系统建立连接时， 获取用户的支付信息；

所述第一验证模块，用于对所述支付信息进行验证，得到第一验证结果；

所述第一生成模块，用于如果所述第一验证结果为验证通过，基于所述支 付信息生成订单信息，并基于所述订单信息完成与所述用户之间的交易；

所述第一发送模块，用于在自身与所述支付系统建立连接时，将所述订单 信息发送给所述支付系统，以使得所述支付系统发起对所述用户的扣费。

本申请实施例提供一种支付装置，所述支付装置包括：第一接收模块、第 一校验模块、第二发送模块和结算模块，其中：

所述第一接收模块，用于接收商户收单系统发送的订单信息；

所述第一校验模块，用于对所述订单信息进行校验；

所述第二发送模块，用于当所述订单信息校验通过后，将所述订单信息发 送给发码平台，以通知发码平台进行扣款；

所述结算模块，用于基于接收到的扣款成功消息，进行对账和资金结算。

本申请实施例提供一种支付装置，所述支付装置包括：第二接收模块、第 二验证模块、扣款模块和第三发送模块，其中：

所述第二接收模块，用于接收支付系统发送的订单信息，所述订单信息至 少包括订单号、支付金额、离线支付标识码信息；

所述第二验证模块，用于对所述订单号和所述离线支付标识码信息进行验 证；

所述扣款模块，用于如果所述订单号和所述离线支付标识码信息验证通过， 基于所述支付金额，对所述订单信息对应的用户账户进行扣款；

所述第三发送模块，用于将扣款成功消息发送给所述订单信息对应的终端 和支付系统。

本申请实施例提供一种计算机设备，所述计算机设备至少包括：

存储器、通信总线和处理器，其中：

所述存储器，用于存储计算机程序；

所述通信总线，用于实现处理器和存储器之间的连接通信；

所述处理器，用于执行存储器中存储的计算机程序，以实现本申请实施例 提供的支付方法中的步骤。

本申请实施例提供一种存储介质，所述存储介质上存储有计算机程序，所 述计算机程序被处理器执行时实现如上所述的支付方法的步骤。

本申请实施例提供一种飞行状态下的支付方法及其装置、设备和存储介质， 其中，首先当在飞行状态下商户收单系统未与支付系统建立连接时，所述商户 收单系统获取用户的支付信息并对所述支付信息进行验证，得到第一验证结果， 如果所述第一验证结果为验证通过，基于所述支付信息生成订单信息，并基于 所述订单信息完成与所述用户之间的交易；在所述商户收单系统与所述支付系 统建立连接时，将所述订单信息发送给所述支付系统，以使得所述支付系统发 起对所述用户的扣费；如此，能够在飞行状态商家收单系统和支付系统在断开 连接的情况下，实现无网支付，并且由于在交易前对支付信息进行了验证，从 而实现无网场景下的安全支付。

附图说明

图1为本申请实施例飞行状态下支付方法的应用场景示意图；

图2为本申请实施例飞行状态下支付方法的实现流程示意图；

图3为本申请实施例飞行状态下支付方法的一个实现流程示意图；

图4为本申请实施例飞行状态下支付方法对应的系统架构图；

图5为本申请实施例飞行状态下支付方法的一实现流程示意图；

图6A为本申请实施例用户请求开通机上支付的界面示意图；

图6B为本申请实施例开通免密支付的界面示意图；

图6C为本申请实施例对用户身份进行验证的界面示意图；

图6D为本申请实施例机上支付开通成功的界面示意图；

图6E为本申请实施例生成离线支付二维码的界面示意图；

图7为本申请实施例发码平台进行扣款的实现流程示意图；

图8为本申请实施例支付装置的组成结构示意图；

图9为本申请实施例计算机设备的组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请 实施例中的附图，对发明的具体技术方案做进一步详细描述。以下实施例用于 说明本申请，但不用来限制本申请的范围。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术 领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申 请实施例的目的，不是旨在限制本申请。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集， 但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集， 并且可以在不冲突的情况下相互结合。

需要指出，本申请实施例所涉及的术语“第一\第二\第三”仅仅是是区别类 似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允 许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能 够以除了在这里图示或描述的以外的顺序实施。

图1为本申请实施例支付方法的应用场景示意图，如图1所示，在该应用 场景中，包括：终端101、商家收单系统102、支付系统103和发码平台104。 其中，终端101可以是移动电话(手机)、平板电脑、笔记本电脑等具有无线通 信能力的移动终端。终端101中可以安装能够扫码支付的支付应用程序 (Application，App)，用户可以通过这些App生成支付二维码，使得商家通过 扫码进行收款。商家收单系统102可以包括扫描设备和收单设备，其中，扫描 设备用于对用户付款时出示的支付二维码进行扫描，以获取支付信息，并且将 支付信息发送给收单设备，收单设备基于支付信息生成订单信息，再将订单信 息发送给支付系统103，支付系统103可以认为是商家的结算中心；支付系统 会将订单信息发送给发码平台104，以通知发码平台104进行扣款。发码平台 104除了进行扣款外，还会为终端提供生成支付二维码的证书数据，以使得终 端能够基于证书数据生成支付二维码。

本申请实施例提供的支付方法是应用在飞行状态下用户想要通过支付二维 码进行付款时，收单系统和终端都与发码平台和支付系统没有建立连接的场景 中，由于用户是事先了解在支付时不能联网的，因此用户在飞机起飞之前，可 以预先通过发码平台104生成离线支付二维码，以供商家收单系统进行扫描收 款。在本申请实施例中，为了防止恶意消费，商家收单系统中存储有能够对用 户的身份信息以及二维码信息进行验证的信息，例如，可以存储有用户的准确 身份信息、验证所需的公钥、加解密算法等，以对用户的身份信息和二维码的 真实性、有效性进行验证，在验证通过后，生成并保存订单信息，完成交易。商家收单系统102会在与支付系统103建立连接后，再将订单信息发送给支付 系统103，以使支付系统103对订单进行校验，并将订单信息发送给发码平台 104进行扣款。

结合图1所示的应用场景示意图，以下对飞行状态下的支付方法及支付装 置、设备的各实施例进行说明。

本申请实施例提供一种支付方法，图2为本申请实施例飞行状态下支付方 法的实现流程示意图，如图2所示，所述方法包括以下步骤：

步骤S201，当飞行状态下商户收单系统未与支付系统建立连接时，所述商 户收单系统获取用户的支付信息。

这里，飞行状态是指飞机在航行过程中所处的状态。当在飞机航行过程中， 终端用户想要购买商品，进行离线支付时，可以出示预先生成的离线支付标识 码，该离线支付标识码可以是二维码。商户可以利用扫描设备对终端显示屏上 显示的离线支付标识码进行扫描，以获取支付信息，并将支付信息传输至商户 收单系统。在一些实施例中，离线支付标识码还可以是字符串，此时可以是商 户的销售人员在商家收单系统手动输入用户的离线支付标识码，以及商品的标 识、支付金额等，以获取用户的支付信息。

在本申请实施例中，商户收单系统可以认为是机上局域网收单系统，用于 对用户的购物信息进行收集，并且在商户收单系统中存储有对用户身份信息以 及对离线支付标识码进行验证的验证信息，以验证用户身份信息的真实性和离 线支付标识码的有效性。

支付系统也可以认为是商家收款系统，主要用于对商户收单系统提供的订 单进行校验和入库，并将订单发送给发码平台以发起对用户的扣款。在收到发 码平台扣款成功的通知消息后还要进行资金结算和对账。

需要说明的是，由于在飞机航行过程中用户购买商品时，商户收单系统与 支付系统，以及商户收单系统和发码平台、终端和支付系统、终端和发码平台 都没有建立有通信连接。扫码设备和商户收单系统之间可以通过局域网建立有 通信连接，因此扫码设备可以将获取到的支付信息传输至商户收单系统。

在本申请实施例中，支付信息至少包括离线支付标识码信息和支付金额。

步骤S202，所述商户收单系统对所述支付信息进行验证，得到第一验证结 果。

这里，第一验证结果可以为验证通过和验证不通过。

步骤S202在实现时，商户收单系统会对支付信息中的离线支付标识码和支 付金额进行验证，只有当离线支付标识码和支付金额都验证通过时，第一验证 结果才为验证通过。

在其他实施例中，在步骤S202之后，所述方法还包括：判断第一验证结果 是否为验证通过；这里如果第一验证结果为验证通过，可以认为离线支付标识 码的是真实有效的，支付金额也没有超过预设的消费限额，此时可以进入步骤 S203；如果第一验证结果为验证不通过，则认为离线支付标识码不是真实有效 的，和/或支付金额超过了消费限额，此时结束流程。

步骤S203，如果所述第一验证结果为验证通过，所述商户收单系统基于所 述支付信息生成订单信息，并基于所述订单信息完成与所述终端之间的交易。

这里，订单信息中可以包括订单号、支付金额和离线支付二维码信息。如 果第一验证结果为验证通过，则认为可以在商户收单系统与支付系统建立连接 后正常完成扣款，因此可以完成与终端用户之间的交易。

步骤S204，在所述商户收单系统与所述支付系统建立连接时，所述商家收 单系统将所述订单信息发送给所述支付系统，以使得所述支付系统发起对所述 用户的延时扣费。

这里，在实际实现过程中，当飞机结束航行落地后，商户收单系统与支付 系统建立通信连接，此时商家收单系统会将订单信息发送给支付系统，由支付 系统对订单进行校验后，再将订单信息发送给离线支付标识码对应的发码平台， 以进行延时扣款。

发码平台在接收到订单信息后，会对订单信息中的订单号和离线支付标识 码信息进行校验，并在校验通过后进行扣款。扣款成功后，发码平台还会给终 端和支付系统发送扣款成功通知消息，以使得终端保存扣款凭证，支付系统基 于该扣款成功通知消息进行资金结算等工作。

在本申请实施例提供的支付方法中，在飞行状态商户收单系统和支付系统 没有建立连接的情况下，在用户使用离线支付标识码进行支付时，商户收单系 统对支付信息进行验证，如果支付信息验证通过，可以认为用户出示的离线支 付标识码是真实有效的，且支付金额也在预设的消费限额之内，因此表明在商 户收单系统与支付系统建立连接后可以完成正常扣款，此时商户收单系统可以 生成订单信息并基于订单信息完成交易，不仅实现了无网支付，还能够保证支 付的安全性。

基于前述的实施例，本申请实施例再提供一种支付方法，图3为本申请实 施例飞行状态下支付方法的又一个实现流程示意图，如图3所示，所述方法包 括：

步骤S301，在飞行状态下终端基于用户的操作指令，生成并输出离线支付 标识码，供扫描设备进行扫描。

这里，步骤S301在实现时，由于是在飞行状态下，那么终端与离线支付标 识码对应的发码平台是没有建立有通信连接的，但是终端在飞机起飞前，也即 与发码平台断开连接之前，已经从发码平台获取到了生成离线支付标识码的证 书数据，从而可以在用户想要利用离线支付标识码进行支付时，即便没有与发 码平台建立连接，也可以根据自身已经存储的证书数据生成离线支付标识码。

在本申请实施例中，输出离线支付标识码可以是指在终端的显示屏上输出 显示所生成的离线支付标识码，以供扫描设备进行扫描。

步骤S302，扫描设备将通过扫描离线支付标识码获取到的支付信息传输给 商户收单系统。

这里，支付信息至少包括离线支付标识码信息和支付金额。

步骤S303，商户收单系统对支付信息中的离线支付标识码信息进行验证， 得到第二验证结果。

这里，离线支付标识码信息中至少包括证书数据、消息摘要数据和离线支 付标识码的生成时间，因此步骤S303在实现时，分别对证书数据、消息摘要数 据和离线支付标识码的生成时间进行验证，得到第二验证结果。

步骤S304，商户收单系统判断第二验证结果是否为验证通过。

这里，如果证书数据、消息摘要数据和离线支付标识码的生成时间都验证 通过，商户收单系统确定所述第二验证结果为验证通过，此时进入步骤S305； 如果证书数据、消息摘要数据和离线支付标识码的生成时间中只要有一个验证 不通过，那么确定第二验证结果为验证不通过，此时，确定第一验证结果也为 验证不通过，结束流程。

步骤S305，商户收单系统对所述支付金额进行验证，得到第一验证结果。

这里，步骤S305在实现时，首先获取离线支付标识码信息对应的限制消费 金额，并判断支付金额是否小于或者等于预设的限制消费金额，如果支付金额 小于或者等于所述限制消费金额，确定第一验证结果为验证通过。

步骤S306，如果所述第一验证结果为验证通过，商户收单系统基于所述支 付信息生成订单信息，并基于所述订单信息完成与所述用户之间的交易。

在本申请实施例中，是先对离线支付标识码信息进行验证，再对支付金额 进行验证，从而确定第一验证结果；在实际应用过程中，并不对离线支付标识 码和支付金额的验证顺序进行限定，只要是离线支付标识码信息和支付金额都 验证通过，那么就确定第一验证结果为验证通过，离线支付标识码信息和支付 金额中有一个验证不通过，则第一验证结果为验证不通过。

如果第一验证结果为验证通过，那么就可以认为离线支付标识码信息是真 实有效的，后续在商户收单系统和支付系统建立有通信连接后可以正常完成扣 款，此时商户收单系统可以基于支付信息生成订单信息，并完成与终端用户之 间的交易。

步骤S307，在飞机结束航行商户收单系统与支付系统建立连接时，商户收 单系统将订单信息发送给所述支付系统，以使得所述支付系统发起对所述用户 的延时扣费。

步骤S308，支付系统基于接收到的商户收单系统发送的订单信息，对所述 订单信息进行校验。

这里，订单信息中可以包括订单号、支付金额和商品标识。支付系统对订 单信息进行校验可以是判断订单号是否重复，以及判断商品标识和支付金额是 否对应。

步骤S309，当订单信息校验通过后，支付系统将订单信息发送给发码平台， 以通知发码平台进行扣款。

这里，如果订单号不重复，并且商品标识和支付金额是对应的，那么认为 订单信息校验通过，此时支付系统将订单信息发送给发码平台，以通知发码平 台进行扣款。

步骤S310，发码平台基于接收到的订单信息，对订单信息中的订单号和所 述离线支付标识码信息进行验证。

这里，订单信息除了包括订单号、支付金额和商品标识之外，还包括离线 支付标识码信息。发码平台在基于订单信息进行扣款时，需要对订单号和离线 支付标识码信息进行验证。在实现时，发码平台可以确定是否存在与所述订单 号相同的订单号；如果不存在与所述订单号相同的订单号，发码平台再进一步 对所述离线支付标识码信息中的交易认证码(Transaction Authorization Cryptogram，TAC)进行验证。

TAC密钥是由发码平台生成的，在生成TAC密码时可以依据但不限于证书 生效时间、证书失效时间和二维码生成时间以及用户标识信息。TAC为不被商 户所知的动态密钥，能够防止商户根据用户的证书数据来伪造二维码发起扣款。

步骤S311，如果所述订单号和所述离线支付标识码信息验证通过，发码平 台基于所述支付金额，对所述订单信息对应的用户账户进行扣款。

这里，只有订单号和离线支付标识码信息都验证通过时，才认为订单信息 验证通过，此时发码平台会基于支付金额对订单信息对应的用户账户进行扣款。

步骤S312，发码平台将扣款成功消息发送给所述订单信息对应的终端和支 付系统。

这里，当发码平台扣款成功后，会将扣款成功消息发送给终端和支付系统。

步骤S313，支付系统基于接收到的扣款成功消息，进行对账和资金结算。

在本实施例提供的支付方法中，当用户想要使用支付标识码进行离线支付 时，可以基于预先获取到的证书数据生成离线支付标识码，扫描设备通过扫描 该离线支付标识码后获取到支付信息并传输至商户收单系统，由商户收单系统 对支付信息中的离线支付标识码信息和支付金额进行验证，如果离线支付标识 码信息和支付金额都验证通过，那么可以认为该离线支付标识码是真实有效的， 且支付金额也没有超出限制消费金额，此时认为可以正常完成交易，在商户收 单系统和支付系统建立有通信连接之后，商户收单系统将订单信息发送给支付 系统，支付系统对商品和支付金额校验后，再将订单信息发送给发码平台进行 扣款，这样不仅满足了用户可以进行离线支付，并且商户收单系统还可以基于预先获取到的黑名单、验证公钥等对支付信息进行验证，以保证支付的安全性。

在其他实施例中，证书数据中至少包括用户信息、证书有效时间和签名数 据，对应地，商户收单系统对所述离线支付标识码信息中的证书数据进行验证 可以通过以下步骤实现：

步骤321，商户收单系统基于自身存储的用户校验信息，对所述证书数据 中的用户信息进行验证。

这里，用户信息可以包括用户的姓名、身份证号、账号ID掩码等信息。用 户校验信息至少包括黑名单和有效用户信息，有效用户信息是指真实有效的用 户信息。黑名单可以是在与发码平台断开连接之前，从发码平台获取的。

该有效用户信息可以是商户预先存储好的，例如当在飞机航行的场景下， 有效用户信息可以是从航空公司服务信息平台获取的本次航班的旅客信息，由 于航空公司服务信息平台中存储的旅客信息一般为在用户购票时用到的用户信 息，是准确的。当在就餐或购物场景下，有效用户信息可以是用户办理会员卡 时存储的用户信息。

步骤321在实现时，可以首先判断该用户信息是否存在于黑名单中，如果 用户信息不存在于所述黑名单中，基于所述有效用户信息，对所述用户信息进 行验证。在实际应用过程中，基于有效用户信息对离线支付标识码信息中的用 户信息进行验证时，可以是将离线支付标识码信息中的用户信息与有效用户信 息进行匹配，以确定用户信息中的姓名、身份证号等是否正确。

步骤322，商户收单系统基于自身的当前时间，对所述证书数据中的证书 有效时间进行验证。

这里，证书有效时间中可以包括证书生效的起始时间和证书失效时间，例 如证书有效时间可以为2019年3月15日至2019年4月15日，其中，2019年 3月15日为证书生效的起始时间，2019年4月15日为证书失效时间。或者证 书有效时间中可以包括证书生效的起始时间和证书有效时长，基于证书生效的 起始时间和证书有效时长，可以确定出证书失效时间，例如证书有效时间可以 为2019年3月15日，有效期30天，那么证书生效的起始时间为2019年3月 15日，失效时间为2019年4月14日。

对证书有效时间进行验证，可以认为是验证证书数据的有效性，当当前时 间在证书有效时间内，则认为证书有效时间通过验证，例如证书有效时间为 2019年3月15日至2019年4月15日，当前时间为2019年3月19日，那么 认为验证通过。

步骤323，商户收单系统基于预先获取的验证公钥，对所述证书数据中的 签名数据进行验证。

这里，如果用户信息、证书有效时间和签名数据都验证通过表征所述证书 数据验证通过。

在其他实施例中，商户收单系统对所述离线支付标识码信息中消息摘要数 据进行验证可以通过以下步骤实现：

步骤331，商户收单系统获取所述离线支付标识码的生成时间、证书有效 起始时间、证书失效时间；

步骤332，商户收单系统基于证书有效起始时间、证书失效时间和离线支 付标识码的生成时间，对所述消息摘要数据中的MAC摘要进行验证。

这里，由于消息摘要数据中的MAC摘要是对证书有效起始时间、证书失 效时间和离线支付标识码的生成时间进行摘要计算得到的，因此需要商户收单 系统基于证书有效起始时间、证书失效时间和离线支付标识码的生成时间也进 行相同的摘要计算，以对消息摘要数据中的MAC摘要进行验证。

在其他实施例中，在所述商户收单系统在与所述支付系统断开连接之前， 所述方法还包括：

步骤341，商户收单系统将自身的时钟与离线支付标识码的发码平台的时 钟进行校对。

这里，商户系统将自身时钟与发码平台的时钟进行校对是为了避免因为时 钟的差异，导致验证结果错误。

步骤342，商户收单系统获取发码平台发送的验证公钥和黑名单。

这里，在商户收单系统在与发码平台断开连接之前，需要获取验证公钥与 黑名单，以对离线支付标识码信息进行验证。

在其他实施例中，在终端与发码平台断开连接之前，会请求获取生成离线 支付标识码所需的证书数据，以在离线时生成离线支付标识码，终端获取证书 数据的过程可以包括：

步骤351，终端向发码平台发送请求消息，所述请求消息用于获取生成离 线支付标识码的证书数据。

步骤352，发码平台基于接收到的请求消息，对终端对应的身份信息进行 验证。

步骤353，当所述身份信息通过验证后，发码平台确定所述身份信息对应 的限制消费金额。

这里，步骤353在实现时，当所述身份信息通过验证后，首先获取用户选 择的扣款方式，并确定所述扣款方式对应的账户余额；然后基于所述账户余额 和信用等级，确定所述身份信息对应的限制消费金额。例如，当用户选择扣款 方式为“零钱”时，则获取“零钱”中的账户余额，并基于账户余额和用户的 信用等级，确定限制消费金额，很显然，限制消费金额是不能大于账户余额的， 具体限制消费金额比账户余额低多少，可以由用户的信用等级决定，其中，用 户的信用等级越高，那么限制消费金额就与账户余额越接近。

步骤354，发码平台至少基于所述身份信息和所述限制消息金额确定证书 数据。

这里，证书数据可以包括卡证书、证书有效时间和签名数据。步骤354在 实现时，首先发码平台基于所述身份信息和所述限制消费金额生成卡证书，进 而再基于用户发送请求消息的时间点及预设的证书有效时长，确定所述证书数 据的证书有效时间；基于验证私钥至少对所述身份信息进行签名，得到签名数 据；最后至少基于所述卡证书、证书数据的有效时长和所述签名数据，生成证 书数据。

步骤355，发码平台将所述证书数据发送给所述终端，以使所述终端基于 所述证书数据生成离线支付标识码。

在本申请实施例中，发码平台还会基于身份信息生成该身份信息对应的分 散密钥，并将该分散密钥发送给终端，终端生成的离线支付标识码中包括该分 散密钥，从而可以保证离线支付标识码不可被商户伪造。

这样，通过步骤351至步骤355，终端就能获取到用于生成离线支付标识 码的证书数据，在用户想要进行离线支付时即可生成离线支付标识码。

在其他实施例中，在发码平台接收到请求消息之后，所述方法还包括：

步骤361，发码平台获取所述身份信息对应的征信数据。

步骤362，发码平台基于所述征信数据确定信用等级。

这里，信用等级越高说明用户的信用度越好，信用等级越低说明用户的信 用度越差。

步骤363，当所述信用等级低于预设等级阈值时，向所述终端发送生成失 败的响应消息。

这里，如果用户的信用等级低于预设等级阈值，那么说明该用户的信用度 很差，有可能不能完成正常扣款，因此此时向终端发送获取失败的响应消息， 避免用户使用离线支付标识码进行离线支付。

本申请实施例提供一种支付方法，应用于航空乘客在飞行航行过程中完全 无网的场景中，图4为本申请实施例飞行状态下支付方法对应的系统架构图， 如图4所示，所述系统架构包括：用户终端401、账户系统402、机上局域网收 单系统403、统一收单系统404、计费平台405和统一发码平台406，其中：

用户终端401，在乘机之前向发码平台申请开通机上离线支付，已生成离 线支付二维码。

账户系统402，进一步包括航司账户系统4021、综合风控数据模型4022 和统一用户账户平台4023，其中，航司账户系统4021提供基本用户资料核验， 统一用户账户平台4023综合风控数据模型4022对用户进行区分授信，对于信 用不合格用户，可以不予开通离线支付。

机上局域网收单系统403，包含移动扫码设备4031以及机上局域网中台控 制系统4032。机上局域网中台控制系统4032提供发码平台的验证公钥，以验 证二维码的真实性和有效性；并提供黑名单数据杜绝恶意用户；另外还提供机 上旅客数据，进一步校对用户身份真实性。机上局域网中台控制系统4032还用 于存储相关订单信息，以待通信网络恢复后自动推单到统一收单系统404。该 机上局域网收单系统403对应其他实施例中的商家收单系统。

统一收单系统404和计费平台405，主要用于对上传的机上订单提供校验 和入库，并发起对用户的延时扣款。计费平台405还提供资金结算、对账功能。 本申请实施例中的统一收单系统404和计费平台405对应其他实施例中的支付 系统。

统一发码平台406，用于提供用户开通离线支付流程、卡证书统一管理下 发能力，统一配置能力。同时统一发码平台还基于接收到的订单发起扣款，扣 款成功之后自动通知用户相关扣款信息。本申请实施例中的统一发码平台406 对应其他实施例中的发码平台。

图5为本申请实施例飞行状态下支付方法的再一实现流程示意图，如图5 所示，所述支付方法涉及三个阶段，即飞机起飞前、飞机航行中和飞机到达后， 以下基于这三个阶段对本申请实施例提供的支付方法进行说明。

如图5所示，在起飞前，终端和发码平台完成的步骤包括：

步骤S501，终端向发码平台发送开通机上支付的请求消息。

这里，图6A为本申请实施例用户请求开通机上支付的界面示意图，如图 6A所示，在该界面示意图中，提供了开通机上支付的按钮控件601，当终端在 按钮控件601所在的屏幕区域接收到触控操作或点击操作时，终端向发码平台 发送开通机上支付的请求消息。该请求消息中至少包括用户的身份信息，还可 以包括航班信息。

步骤S502，发码平台为该终端开通服务。

这里，发码平台在接收到请求开通机上支付的请求消息后，可以根据请求 消息中的航班信息从航空公司服务信息平台获取与航班信息对应的用户数据， 并生成用户账号。

在该阶段，如图6B所示，发码平台会提示用户与航空公司签署相关代扣 签约关系，并在终端界面显示阅读并同意《扣款授权确认书》的选择按钮控件 611，用户需要选择同意才能开通。并为用户提供扣款方式的选择，用户可以选 择零钱方式，还可以选择绑定的银行卡方式。同时，发码平台通过对用户身份 做实名校验，如图6C所示，发码平台可以请求用户输入支付密码以确认是本 人操作，并根据后台征信数据对用户进行区别授信。

步骤S503，发码平台向终端发送开通成功的通知消息。

这里，当发码平台向终端发送开通成功的通知消息后，终端会显示如图6D 所示的界面。

步骤S504，终端向发码平台发送获取卡证书的请求消息。

步骤S505，发码平台基于该请求消息生成卡证书。

步骤S506，发码平台向终端返回卡证书。

这里，终端在获取到卡证书后，在与发码平台没有建立通信连接的情况下 也可以生成如图6E所示的支付二维码。

如图5所示，在起飞前航空公司的机上局域网中台控制系统也需要获取验 证支付二维码的公钥、MAC根密钥以及黑名单，实现过程包括：

步骤S507，航空公司服务信息平台从发码平台定期下载卡证书公钥列表。

步骤S508，发码平台返回公钥列表给航空公司服务信息平台。

步骤S509，航空公司服务信息平台将公钥列表下发给机上局域网中台控制 系统。

步骤S510，航空公司服务信息平台从发码平台定期下载MAC根密钥列表。

步骤S511，发码平台返回MAC根密钥列表给航空公司服务信息平台。

步骤S512，航空公司服务信息平台将MAC根密钥列表下发给机上局域网 中台控制系统。

步骤S513，航空公司服务信息平台从发码平台定期下载黑名单列表。

步骤S514，发码平台返回黑名单列表给航空公司服务信息平台。

步骤S515，航空公司服务信息平台将黑名单列表下发给机上局域网中台控 制系统。

这里，经过步骤S507至步骤S515，机上局域网中台控制系统就获取到了 卡证书公钥、MAC根密钥列及黑名单列表，从而在无网的情况下，能够对用户 的支付信息进行验证，以保证安全支付。

需要说明的是，步骤S501至步骤S506和步骤S507至步骤S515的执行不 区分先后顺序，可以是先执行步骤S501至步骤S506，也可以是先执行步骤S507 至步骤S515，当然还可以是在步骤S501至步骤S506的执行过程中，同时执行 步骤S507至步骤S515。

如图5所示，在飞机航行过程中，用户想要通过支付二维码进行支付时的 实现过程包括：

步骤S516，终端基于卡证书，离线生成机上支付码。

步骤S517，终端出示支付码，以供机上局域网中台控制系统中的扫码设备 进行离线扫码。

步骤S518，机上局域网中台控制系统读取二维码。

步骤S519，机上局域网中台控制系统向机具SDK发送获取二维码元素的 请求消息。

步骤S520，机具SDK返回二维码元素给机上局域网中台控制系统。

步骤S521，机上局域网中台控制系统向机具SDK发送验证二维码的请求 消息。

步骤S522，机具SDK验证二维码的合法性和有效性。

步骤S523，机具SDK在二维码验证通过后，生成扫码记录。

步骤S524，机具SDK将扫码记录返回给机上局域网中台控制系统。

步骤S525，机上局域网中台控制系统检查黑名单。

这里，如果用户不在黑名单列表中，则进入步骤S526，验证支付金额是否 超过消费额度。

步骤S526，机上局域网中台控制系统检查是否超过消费额度。

这里，如果支付金额没有超过消费额度，则表明可以完成交易，此时进入 步骤S527。

步骤S527，机上局域网中台控制系统保存交易记录。

通过步骤S516至步骤S527，旅客在机上消费时，展示手机上的离线二维 码，空乘人员通过特定移动设备扫描二维码，并由机具SDK校验二维码真实性 和时效性，并验证用户姓名身份证与机上旅客信息是否匹配，是否满足限额要 求。通过则做支付成功，并保存相关订单信息于机上局域网中台控制系统。由 于机上局域网中台控制系统与航空公司服务信息平台没有建立通信连接，不能 实现即时扣款。但是由于机上局域网中台控制系统已经对二维码的合法性和有 效性、支付金额进行了验证，能够保证在飞机落地后与航空公司服务信息平台 建立通信连接后，进行订单推送和扣款，保证了支付的安全性和有效性。

为了更好地理解如何对二维码的有效性和合法性进行验证，首先对二维码 数据的组成进行说明。

二维码的整体数据组成及说明，如表1所示：

表1二维码数据组成内容及说明

证书数据的组成内容及说明如表2所示：

表2二维码数据组成内容及说明

由于二维码数据包含用户姓名信息、用户身份ID掩码信息，因此可以在机 上扫码设备扫码时，与机上局域网系统的旅客名单进行比对，进一步确认用户 的真实身份。

在本申请实施例中，在获取到二维码信息后，机上局域网中台控制系统通 过验证以下信息，以验证二维码的真实性和有效性。

1、黑名单检查：检查用户是否处于机上局域网系统黑名单中，黑名单在飞 机起飞前更新至机上局域网系统。

2、证书有效期检查。

在实现时，判断机上局域网服务器时间是否小于证书生效的起始时间或者 是否大于证书失效时间，如果机上局域网服务器时间小于证书生效的起始时间 或者大于证书失效时间，则不允许支付。局域网服务器的时钟在起飞前与二维 码发码平台进行校对，确保时间准确。

3、证书验签。

在实现时，用二维码发码平台下发的公钥对证书签名进行验证，如果签名 验证通过，则允许支付。发码平台在飞机起飞前将公钥下发至机上局域网中台 控制系统。

4、二维码生成时间检查。

在实现时，如果二维码生成时间在证书生效的起始时间和证书失效时间范 围之外，则验证失败，不允许支付；还可以是如果机上局域网服务器的时间减 去二维码生成时间的值大于证书里的二维码失效时间时，验证失败，不允许支 付；或者，如果机上局域网服务器时间加上时钟误差允许时间小于二维码生成 时间时，验证失败，不允许支付。

5、MAC摘要验证。

在实现时，基于证书生效的起始时间、证书失效时间、二维码生成时间对 MAC摘要进行验证，如果MAC摘要不正确，则验证失败，不允许支付。

6、限额检查。

在实现时，判断交易金额是否大于限额，如果交易金额大于限额则验证失 败，不允许支付。

7、姓名身份证信息校对。

在实现时，将二维码中的用户姓名、身份证掩码信息与机上局域网服务器 中本次航班旅客信息比对，匹配成功则认为合法，有效保证身份信息真实性。

在上述信息验证通过之后，保存相关订单信息到机上局域网中台控制系统， 其中订单信息包括订单号，交易详情、二维码字符串等。飞机落地之后，系统 恢复联网则自动将本地收储的订单上传至后台收单系统。

在飞机落地，机上局域网中台控制系统与航空公司信息服务平台建立通信 连接后，进行延时扣款的实现过程包括：

步骤S528，机上局域网中台控制系统上传扫码数据至航空公司信息服务平 台。

步骤S529，航空公司服务信息平台上传订单数据至航空公司结算中心。

步骤S530，航空公司结算中心上传订单信息至发码平台，以通知发码平台 进行扣款。

步骤S531，发码平台基于订单信息进行扣款。

步骤S532，发码平台在扣款成功后，向航空公司结算中心通知扣款成功。

步骤S533，航空公司结算中心通知航空公司服务信息平台支付成功。

步骤S534，发码平台通知终端扣款成功。

步骤S535，终端接收并显示扣款成功通知。

在步骤S528至步骤S535中，飞机落地后，机上中台系统恢复联网之后， 自动传输相关订单信息至航空公司服务信息平台，经过财务计费平台确认无误 后，发送给二维码发码平台，对用户发起延时扣款。

图7为本申请实施例发码平台进行扣款的实现流程示意图，如图7所示， 发码平台基于订单信息进行扣款可以通过以下步骤实现：

步骤S701，判断订单号是否重复。

这里，如果订单号重复，则结束流程；如果订单号不重复，则进入步骤S702。

步骤S702，验证二维码证书是否有效。

这里，发码平台可以对二维码证书中的签发有效期、用户信息等进行验证， 判断二维码证书是否有效，如果二维码证书有效，则进入步骤S703，如果二维 码证书无效，则结束流程。

步骤S703，验证二维码的TAC签名是否正确。

这里，发码平台基于用户身份信息、证书的有效期和二维码的生成时间对 TAC签名进行验证，如果TAC签名正确，则进入步骤S704；如果TAC签名不 正确，则结果流程。

在本实施例提供的机上支付方法中，用户通过展示其不可伪造的唯一身份 二维码，并被空乘人员手持设备扫描并记录，然后与机上局域网中台控制系统 中的旅客信息进行比对，以确认用户身份的真实性，还会对二维码信息进行校 验，校验通过则存储订单信息，二维码作为支付凭证。待飞机落地恢复网络后， 机上局域网中台控制系统自动上传订单信息，并通知进行扣款。这样，当机上 旅客在购买机上商品如升舱服务、免税商品时，只需展示二维码即可完成机上 支付，无需任何实体卡，非常方便快捷。另外用户需要持有发码平台颁发的卡 证书才能生成二维码，卡证书经过发码平台的私钥签名，用户不可伪造，能够 有效保证交易的真实性。

验码流程会校验二维码的时效性，并提取二维码中的姓名和身份证掩码， 和机上局域网中台控制系统中的旅客信息做比对，可以保证即便卡证书被盗别 人也无法刷码。加之二维码中含有用户的分散密钥，航空公司无法伪造，这样 就保证了用户和商户的双方皆不可伪造，保证交易的真实性。

另外，用户在开通卡证书时，发码平台会针对用户信用数据给与用户不同授信 额度；在飞机起飞前更新实时黑名单给机上局域网中台控制系统，以在用户刷 码时，将用户信息与机上局域网中台控制系统的黑名单做比对，能够有效防止 恶意消费，从而提高延时扣款的成功率，保护商家利益。

基于前述的实施例，本申请实施例提供一种支付装置，该装置包括所包括 的各模块、以及各单元所包括的各单元，可以通过计算机设备中的处理器来实 现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央 处理器(CPU)、微处理器(MPU)、数字信号处理器(DSP)或现场可编程门 阵列(FPGA)等。

图8为本申请实施例支付装置的组成结构示意图，如图8所示，所述支付 装置800包括：第一获取模块801、第一验证模块802、第一生成模块503和第 一发送模块804，其中：

所述第一获取模块801，用于当在飞行状态下自身未与支付系统建立连接 时，获取用户的支付信息；

所述第一验证模块802，用于对所述支付信息进行验证，得到第一验证结 果；

所述第一生成模块803，用于如果所述第一验证结果为验证通过，基于所 述支付信息生成订单信息，并基于所述订单信息完成与所述用户之间的交易；

所述第一发送模块804，用于在自身与所述支付系统建立连接时，将所述 订单信息发送给所述支付系统，以使得所述支付系统发起对所述用户的扣费。

在其他实施例中，所述支付信息至少包括离线支付标识码信息和支付金额， 相应地，所述第一验证模块，包括：

第一验证单元，用于对所述离线支付标识码信息进行验证，得到第二验证 结果；

第二验证单元，用于如果第二验证结果为验证通过，对所述支付金额进行 验证，得到第一验证结果。

在其他实施例中，所述第一验证单元，包括：

第一验证子单元，用于分别对所述离线支付标识码信息中的证书数据、消 息摘要数据和所述离线支付标识码的生成时间进行验证；

第一确定子单元，用于如果所述证书数据、消息摘要数据和所述离线支付 标识码的生成时间都验证通过，确定所述第二验证结果为验证通过。

在其他实施例中，所述证书数据中至少包括用户信息、证书有效时间和签 名数据，对应地，所述第一验证子单元还用于：

基于自身存储的用户校验信息，对所述证书数据中的用户信息进行验证；

基于自身的当前时间，对所述证书数据中的证书有效时间进行验证；

基于预先获取的验证公钥，对所述证书数据中的签名数据进行验证，其中， 如果所述用户信息、证书有效时间和签名数据都验证通过表征所述证书数据验 证通过。

在其他实施例中，所述第一验证子单元，还用于：

获取所述离线支付标识码的生成时间、证书有效起始时间、证书失效时间；

基于证书有效起始时间、证书失效时间和离线支付标识码的生成时间，对 所述消息摘要数据中的MAC摘要进行验证。

在其他实施例中，所述第二验证单元，包括：

第一获取子单元，用于如果所述离线支付标识码信息验证通过，获取所述 离线支付标识码信息对应的限制消费金额；

第二确定子单元，用于如果所述支付金额小于或者等于所述限制消费金额， 确定所述第一验证结果为验证通过。

需要说明的是，上述支付装置实施例的描述，与上述方法实施例的描述是 类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露 的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例再提供一种支付装置，所述支付装置包括：第一接收模块、 第一校验模块、第二发送模块和结算模块，其中：

所述第一接收模块，用于接收商户收单系统发送的订单信息；

所述第一校验模块，用于对所述订单信息进行校验；

所述第二发送模块，用于当所述订单信息校验通过后，将所述订单信息发 送给发码平台，以通知发码平台进行扣款；

所述结算模块，用于基于接收到的扣款成功消息，进行对账和资金结算。

需要说明的是，上述支付装置实施例的描述，与上述方法实施例的描述是 类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露 的技术细节，请参照本申请方法实施例的描述而理解。

本申请实施例再提供一种支付装置，所述支付装置包括：第二接收模块、 第二验证模块、扣款模块和第三发送模块，其中：

所述第二接收模块，用于接收支付系统发送的订单信息，所述订单信息至 少包括订单号、支付金额、离线支付标识码信息；

所述第二验证模块，用于对所述订单号和所述离线支付标识码信息进行验 证；

所述扣款模块，用于如果所述订单号和所述离线支付标识码信息验证通过， 基于所述支付金额，对所述订单信息对应的用户账户进行扣款；

所述第三发送模块，用于将扣款成功消息发送给所述订单信息对应的终端 和支付系统。

在其他实施例中，所述支付装置还包括：

第三验证模块，用于基于接收到的请求消息，对终端对应的身份信息进行 验证；所述请求消息用于请求获取生成离线支付标识码的证书数据；

第一确定模块，用于当所述身份信息通过验证后，确定所述身份信息对应 的限制消费金额；

第二确定模块，用于至少基于所述身份信息和所述限制消息金额确定证书 数据；

第四发送模块，用于将所述证书数据发送给所述终端，以使所述终端基于 所述证书数据生成离线支付标识码。

在其他实施例中，所述第二确定模块，包括：

第一生成单元，用于基于所述身份信息和所述限制消费金额生成卡证书；

第一确定单元，用于基于用户发送请求消息的时间点及预设的证书有效时 长，确定所述证书数据的有效时长；

签名单元，用于基于验证私钥至少对所述身份信息进行签名，得到签名数 据；

第二生成单元，用于至少基于所述卡证书、证书数据的有效时长和所述签 名数据，生成证书数据。

需要说明的是，上述支付装置实施例的描述，与上述方法实施例的描述是 类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露 的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的 支付方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取 存储介质中。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申 请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例再提供一种存储介质，所述存储介质上存储有计算 机程序，所述计算机程序被处理器执行时实现上述的支付方法的步骤。

对应地，本申请实施例提供一种计算机设备，图9为本申请实施例计算机 设备的组成结构示意图，如图9所示，所述计算机设备900包括：至少一个处 理器901、至少一个通信总线902、用户接口903、至少一个外部通信接口904 和存储器905。其中：

计算机设备900中的各个组件通过通信总线902耦合在一起。可理解，通 信总线902用于实现这些组件之间的连接通信。通信总线902除包括数据总线 之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见， 在图9中将各种总线都标为通信总线902。

用户接口903可以包括显示器、键盘、鼠标、轨迹球、点击轮、按键、按 钮、触感板或者触摸屏等。

外部通信接口904可以包括标准的有线接口和无线接口。

存储器905可以是易失性存储器或非易失性存储器，也可包括易失性和非 易失性存储器两者。其中，非易失性存储器可以是只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read-Only Memory)、可 擦除可编程只读存储器(EPROM，Erasable Programmable Read-Only Memory)、 闪存(Flash Memory)等。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多 形式的RAM可用，例如静态随机存取存储器(SRAM，Static RandomAccess Memory)、同步静态随机存取存储器(SSRAM，Synchronous Static Random AccessMemory)。本申请实施例描述的存储器905旨在包括这些和任意其它适 合类型的存储器。

作为本申请实施例提供的方法采用软硬件结合实施的示例，本申请实施例 所提供的方法可以直接体现为由处理器901执行的软件模块组合，软件模块可 以位于存储介质中，存储介质位于存储器905，处理器901读取存储器905中 软件模块包括的可执行指令，结合必要的硬件(例如，包括处理器901以及连 接到通信总线902的其他组件)以实现上述实施例中提供的支付方法。

作为示例，处理器901可以是一种集成电路芯片，具有信号的处理能力， 例如通用处理器、数字信号处理器(DSP，Digital Signal Processor)，或者其他 可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等，其中，通用 处理器可以是微处理器或者任何常规的处理器等。

以上计算机设备和存储介质实施例的描述，与上述方法实施例的描述是类 似的，具有同方法实施例相似的有益效果。对于本申请计算机设备和存储介质 实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实 施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此， 在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指 相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合 在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序 号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻 辑确定，而不应对本申请实施例的实施过程构成任何限定。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意 在涵盖非排他性的包含。在没有更多限制的情况下，由语句“包括一个……” 限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另 外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可 以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所 述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。 另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接 可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机 械的或其它形式的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中， 也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一 个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软 件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可 以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储 介质中，该程序在执行时，执行包括上述方法实施例的步骤。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立 的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样 的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分可 以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包 括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络 设备等)执行本申请各个实施例所述方法的全部或部分。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于 此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到 变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应 以所述权利要求的保护范围为准。

Claims (15)

1.一种飞行状态下的支付方法，其特征在于，所述方法包括：

当在飞行状态下商户收单系统未与支付系统建立连接时，所述商户收单系统获取用户的支付信息；

对所述支付信息进行验证，得到第一验证结果；

如果所述第一验证结果为验证通过，基于所述支付信息生成订单信息，并基于所述订单信息完成与所述用户之间的交易；

在所述商户收单系统与所述支付系统建立连接时，将所述订单信息发送给所述支付系统，以使得所述支付系统发起对所述用户的扣费。

2.根据权利要求1中所述的方法，其特征在于，所述支付信息至少包括离线支付标识码信息和支付金额，相应地，所述对所述支付信息进行验证，得到第一验证结果，包括：

对所述离线支付标识码信息进行验证，得到第二验证结果；

如果第二验证结果为验证通过，对所述支付金额进行验证，得到第一验证结果。

3.根据权利要求2中所述的方法，其特征在于，所述对所述离线支付标识码信息进行验证，得到第二验证结果，包括：

分别对所述离线支付标识码信息中的证书数据、消息摘要数据和所述离线支付标识码的生成时间进行验证；

如果所述证书数据、消息摘要数据和所述离线支付标识码的生成时间都验证通过，确定所述第二验证结果为验证通过。

4.根据权利要求3中所述的方法，其特征在于，所述证书数据中至少包括用户信息、证书有效时间和签名数据，对应地，所述对所述离线支付标识码信息中的证书数据进行验证，包括：

基于自身存储的用户校验信息，对所述证书数据中的用户信息进行验证；

基于自身的当前时间，对所述证书数据中的证书有效时间进行验证；

基于预先获取的验证公钥，对所述证书数据中的签名数据进行验证，其中，如果所述用户信息、证书有效时间和签名数据都验证通过表征所述证书数据验证通过。

5.根据权利要求3中所述的方法，其特征在于，所述对所述离线支付标识码信息中消息摘要数据进行验证，包括：

获取所述离线支付标识码的生成时间、证书有效起始时间、证书失效时间；

基于证书有效起始时间、证书失效时间和离线支付标识码的生成时间，对所述消息摘要数据中的MAC摘要进行验证。

6.根据权利要求2中所述的方法，其特征在于，所述如果所述离线支付标识码信息验证通过，对所述支付金额进行验证，得到验证结果，包括：

如果所述离线支付标识码信息验证通过，获取所述离线支付标识码信息对应的限制消费金额；

如果所述支付金额小于或者等于所述限制消费金额，确定所述支付信息的验证结果为验证通过。

7.一种飞行状态下的支付方法，其特征在于，所述方法包括：

支付系统接收商户收单系统发送的订单信息；

对所述订单信息进行校验；

当所述订单信息校验通过后，将所述订单信息发送给发码平台，以通知发码平台进行扣款；

基于接收到的扣款成功消息，所述支付系统进行对账和资金结算。

8.一种飞行状态下的支付方法，其特征在于，所述方法包括：

发码平台接收支付系统发送的订单信息，所述订单信息至少包括订单号、支付金额、离线支付标识码信息；

对所述订单号和所述离线支付标识码信息进行验证；

如果所述订单号和所述离线支付标识码信息验证通过，基于所述支付金额，对所述订单信息对应的用户账户进行扣款；

将扣款成功消息发送给所述订单信息对应的终端和支付系统。

9.根据权利要求8中所述的方法，其特征在于，所述方法还包括：

基于接收到的请求消息，对终端对应的身份信息进行验证；所述请求消息用于请求获取离线支付标识码的证书数据；

当所述身份信息通过验证后，确定所述身份信息对应的限制消费金额；

至少基于所述身份信息和所述限制消息金额确定证书数据；

将所述证书数据发送给所述终端，以使所述终端基于所述证书数据生成离线支付标识码。

10.根据权利要求9中所述的方法，其特征在于，所述至少基于所述身份信息和所述限制消费金额确定证书数据，包括：

基于所述身份信息和所述限制消费金额生成卡证书；

基于用户发送请求消息的时间点及预设的证书有效时长，确定所述证书数据的证书有效时时间；

基于验证私钥至少对所述身份信息进行签名，得到签名数据；

至少基于所述卡证书、证书有效时间和所述签名数据，生成证书数据。

11.一种支付装置，其特征在于，所述支付装置包括：第一获取模块、第一验证模块、第一生成模块和第一发送模块，其中：

所述第一获取模块，用于当在飞行状态下自身未与支付系统建立连接时，获取用户的支付信息；

所述第一验证模块，用于对所述支付信息进行验证，得到第一验证结果；

所述第一生成模块，用于如果所述第一验证结果为验证通过，基于所述支付信息生成订单信息，并基于所述订单信息完成与所述用户之间的交易；

所述第一发送模块，用于在自身与所述支付系统建立连接时，将所述订单信息发送给所述支付系统，以使得所述支付系统发起对所述用户的扣费。

12.一种支付装置，其特征在于，所述支付装置包括：第一接收模块、第一校验模块、第二发送模块和结算模块，其中：

所述第一接收模块，用于接收商户收单系统发送的订单信息；

所述第一校验模块，用于对所述订单信息进行校验；

所述第二发送模块，用于当所述订单信息校验通过后，将所述订单信息发送给发码平台，以通知发码平台进行扣款；

所述结算模块，用于基于接收到的扣款成功消息，进行对账和资金结算。

13.一种支付装置，其特征在于，所述支付装置包括：第二接收模块、第二验证模块、扣款模块和第三发送模块，其中：

所述第二接收模块，用于接收支付系统发送的订单信息，所述订单信息至少包括订单号、支付金额、离线支付标识码信息；

所述第二验证模块，用于对所述订单号和所述离线支付标识码信息进行验证；

所述扣款模块，用于如果所述订单号和所述离线支付标识码信息验证通过，基于所述支付金额，对所述订单信息对应的用户账户进行扣款；

所述第三发送模块，用于将扣款成功消息发送给所述订单信息对应的终端和支付系统。

14.一种计算机设备，其特征在于，所述计算机设备至少包括：存储器、通信总线和处理器，其中：

所述存储器，用于存储计算机程序；

所述通信总线，用于实现处理器和存储器之间的连接通信；

所述处理器，用于执行存储器中存储的计算机程序，以实现权利要求1至10中任一项所述的支付方法的步骤。

15.一种存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至10中任一项中所述的支付方法的步骤。

Images