一种虚拟支付方法及系统专利检索-虚拟货币数字货币银行与财务事项专利检索查询-专利查询网

一种虚拟支付方法及系统

阅读：808发布：2020-05-12

专利汇可以提供一种虚拟支付方法及系统专利检索，专利查询，专利分析的服务。并且本申请公开了一种虚拟支付方法及系统，第一虚拟账户与实体账户关联，第二虚拟账户与实体账户关联，即不同账户的虚拟账户均与实体账户关联，在通过虚拟支付进行机票预订信息的支付时，实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换，在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化，但是与多个不同虚拟账户关联的实体账户的总金额不变，即实体账户中的实际货币金额未发生变化，那么，就不会受到央行施行办法的限制，不采用第三方交易平台，直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付，在同一个账户下进行不同虚拟账户间的余额交换，没有每日或每年的交易限额。，下面是一种虚拟支付方法及系统专利的具体信息内容。

权利要求

1.一种虚拟支付方法，其特征在于，包括：
获取机票预订信息；
依据所述机票预订信息确定发出所述机票预订信息的账户，以及，确定针对所述机票预订信息的支付方式为虚拟支付；
确定所述账户的虚拟账户，设定所述账户的虚拟账户为第一虚拟账户，所述第一虚拟账户与实体账户关联；
获取所述第一虚拟账户的虚拟支付密码，进行虚拟支付；
依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币；
在所述机票预订信息所在航空公司的虚拟账户中增加与所述机票预订信息中的消费金额等额的虚拟货币，其中，设定所述机票预订信息所在航空公司的虚拟账户为第二虚拟账户，所述第二虚拟账户与所述实体账户关联。
2.根据权利要求1所述的方法，其特征在于，所述依据所述机票预订信息确定发出所述机票预订信息的账户，以及，确定针对所述机票预订信息的支付方式为虚拟支付，包括：
依据所述机票预订信息确定发出所述机票预订信息的账户；
对所述账户的有效性进行验证，若验证通过，则确定针对所述机票预订信息的支付方式为虚拟支付。
3.根据权利要求1所述的方法，其特征在于，还包括：
对所述第一虚拟账户的虚拟货币余额进行查询，以确定所述第一虚拟账户的虚拟货币余额的值。
4.根据权利要求3所述的方法，其特征在于，所述依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币，包括：
确定所述机票预订信息中的消费金额的值；
若所述第一虚拟账户的虚拟货币余额的值大于所述机票预订信息中的消费金额的值，则将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币。
5.根据权利要求1所述的方法，其特征在于，还包括：
申请实体账户；
在申请通过后的所述实体账户的基础上，注册多个虚拟账户，所述多个虚拟账户分别属于不同的账户，所述不同的账户的虚拟账户分别与所述实体账户关联。
6.一种虚拟支付系统，其特征在于，包括：
预订信息获取单元，用于获取机票预订信息；
第一确定单元，用于依据所述机票预订信息确定发出所述机票预订信息的账户，以及，确定针对所述机票预订信息的支付方式为虚拟支付；
虚拟账户确定单元，用于确定所述账户的虚拟账户，设定所述账户的虚拟账户为第一虚拟账户，所述第一虚拟账户与实体账户关联；
密码获取单元，用于获取所述第一虚拟账户的虚拟支付密码，进行虚拟支付；
扣除单元，用于依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币；
增加单元，用于在所述机票预订信息所在航空公司的虚拟账户中增加与所述机票预订信息中的消费金额等额的虚拟货币，其中，设定所述机票预订信息所在航空公司的虚拟账户为第二虚拟账户，所述第二虚拟账户与所述实体账户关联。
7.根据权利要求6所述的系统，其特征在于，所述第一确定单元用于：
依据所述机票预订信息确定发出所述机票预订信息的账户；对所述账户的有效性进行验证，若验证通过，则确定针对所述机票预订信息的支付方式为虚拟支付。
8.根据权利要求6所述的系统，其特征在于，还包括：
查询单元，用于对所述第一虚拟账户的虚拟货币余额进行查询，以确定所述第一虚拟账户的虚拟货币余额的值。
9.根据权利要求8所述的系统，其特征在于，所述扣除单元用于：
确定所述机票预订信息中的消费金额的值；若所述第一虚拟账户的虚拟货币余额的值大于所述机票预订信息中的消费金额的值，则将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币。
10.根据权利要求6所述的系统，其特征在于，还包括：
申请单元，用于申请实体账户；在申请通过后的所述实体账户的基础上，注册多个虚拟账户，所述多个虚拟账户分别属于不同的账户，所述不同的账户的虚拟账户分别与所述实体账户关联。

说明书全文

一种虚拟支付方法及系统

技术领域

[0001] 本申请涉及控制领域，尤其涉及一种虚拟支付方法及系统。

背景技术

[0002] 航空公司B2B(Business-to-Business)网站，是航空公司面向机票代理人销售机票的渠道，代理人在网站上进行机票查询预订和支付，当前，航空公司B2B网站在线支付中，基于实体货币的第三方支付占很大比例，如：通过支付窗进行支付，或，通过串票平台支付。

[0003] 目前，各航空公司B2B网站全年支付额大约1000亿左右，然而，2016年7月1日起，中国人民银行施行了《非银行支付机构网络支付业务管理办法》，限制了第三方支付平台账户的支付，比如：对个人客户使用支付账户付款的交易进行限额管理，其中单日累计交易限额1000元、5000元，年累计交易限额10万元、20万元。这就导致用户通过第三方平台在各航空公司B2B网站进行交易时，由于限额问题导致的交易不能顺利进行的问题。
发明内容

[0004] 有鉴于此，本申请提供一种虚拟支付方法及系统，其具体方案如下：

[0005] 一种虚拟支付方法，包括：

[0006] 获取机票预订信息；

[0007] 依据所述机票预订信息确定发出所述机票预订信息的账户，以及，确定针对所述机票预订信息的支付方式为虚拟支付；

[0008] 确定所述账户的虚拟账户，设定所述账户的虚拟账户为第一虚拟账户，所述第一虚拟账户与实体账户关联；

[0009] 获取所述第一虚拟账户的虚拟支付密码，进行虚拟支付；

[0010] 依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币；

[0011] 在所述机票预订信息所在航空公司的虚拟账户中增加与所述机票预订信息中的消费金额等额的虚拟货币，其中，设定所述机票预订信息所在航空公司的虚拟账户为第二虚拟账户，所述第二虚拟账户与所述实体账户关联。

[0012] 进一步的，所述依据所述机票预订信息确定发出所述机票预订信息的账户，以及，确定针对所述机票预订信息的支付方式为虚拟支付，包括：

[0013] 依据所述机票预订信息确定发出所述机票预订信息的账户；

[0014] 对所述账户的有效性进行验证，若验证通过，则确定针对所述机票预订信息的支付方式为虚拟支付。

[0015] 进一步的，还包括：

[0016] 对所述第一虚拟账户的虚拟货币余额进行查询，以确定所述第一虚拟账户的虚拟货币余额的值。

[0017] 进一步的，所述依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币，包括：

[0018] 确定所述机票预订信息中的消费金额的值；

[0019] 若所述第一虚拟账户的虚拟货币余额的值大于所述机票预订信息中的消费金额的值，则将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币。

[0020] 进一步的，还包括：

[0021] 申请实体账户；

[0022] 在申请通过后的所述实体账户的基础上，注册多个虚拟账户，所述多个虚拟账户分别属于不同的账户，所述不同的账户的虚拟账户分别与所述实体账户关联。

[0023] 一种虚拟支付系统，包括：

[0024] 预订信息获取单元，用于获取机票预订信息；

[0025] 第一确定单元，用于依据所述机票预订信息确定发出所述机票预订信息的账户，以及，确定针对所述机票预订信息的支付方式为虚拟支付；

[0026] 虚拟账户确定单元，用于确定所述账户的虚拟账户，设定所述账户的虚拟账户为第一虚拟账户，所述第一虚拟账户与实体账户关联；

[0027] 密码获取单元，用于获取所述第一虚拟账户的虚拟支付密码，进行虚拟支付；

[0028] 扣除单元，用于依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币；

[0029] 增加单元，用于在所述机票预订信息所在航空公司的虚拟账户中增加与所述机票预订信息中的消费金额等额的虚拟货币，其中，设定所述机票预订信息所在航空公司的虚拟账户为第二虚拟账户，所述第二虚拟账户与所述实体账户关联。

[0030] 进一步的，所述第一确定单元用于：

[0031] 依据所述机票预订信息确定发出所述机票预订信息的账户；对所述账户的有效性进行验证，若验证通过，则确定针对所述机票预订信息的支付方式为虚拟支付。

[0032] 进一步的，还包括：

[0033] 查询单元，用于对所述第一虚拟账户的虚拟货币余额进行查询，以确定所述第一虚拟账户的虚拟货币余额的值。

[0034] 进一步的，所述扣除单元用于：

[0035] 确定所述机票预订信息中的消费金额的值；若所述第一虚拟账户的虚拟货币余额的值大于所述机票预订信息中的消费金额的值，则将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币。

[0036] 进一步的，还包括：

[0037] 申请单元，用于申请实体账户；在申请通过后的所述实体账户的基础上，注册多个虚拟账户，所述多个虚拟账户分别属于不同的账户，所述不同的账户的虚拟账户分别与所述实体账户关联。

[0038] 从上述技术方案可以看出，本申请公开的虚拟支付方法及系统，获取机票预订信息，依据机票预订信息确定发出机票预订信息的账户，以及，确定针对机票预订信息的支付方式为虚拟支付，确定账户的虚拟账户，设定账户的虚拟账户为第一虚拟账户，第一虚拟账户与实体账户关联，获取第一虚拟账户的虚拟支付密码，进行虚拟支付，依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币，在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟账户，设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户，第二虚拟账户与实体账户关联。本申请中，第一虚拟账户与实体账户关联，第二虚拟账户与实体账户关联，即不同账户的虚拟账户均与实体账户关联，在通过虚拟支付进行机票预订信息的支付时，实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换，在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化，但是与多个不同虚拟账户关联的实体账户的总金额不变，即实体账户中的实际货币金额未发生变化，那么，就不会受到央行施行办法的限制，不采用第三方交易平台，直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付，在同一个账户下进行不同虚拟账户间的余额交换，没有每日或每年的交易限额。附图说明

[0039] 为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

[0040] 图1为本申请实施例公开的一种虚拟支付方法的流程图；

[0041] 图2为本申请实施例公开的一种实体账户与虚拟账户之间的关系图；

[0042] 图3为本申请实施例公开的一种虚拟支付方法的流程图；

[0043] 图4为本申请实施例公开的一种虚拟支付装置的结构示意图；

[0044] 图5为本申请实施例公开的一种虚拟支付系统的结构示意图。

具体实施方式

[0045] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

[0046] 本申请公开了一种虚拟支付方法，其流程图如图1所示，包括：

[0047] 步骤S11、获取机票预订信息；

[0048] 步骤S12、依据机票预订信息确定发出机票预订信息的账户，以及，确定针对机票预订信息的支付方式为虚拟支付；

[0049] 步骤S13、确定账户的虚拟账户，设定账户的虚拟账户为第一虚拟账户，第一虚拟账户与实体账户关联；

[0050] 用户登录航空公司的网站的账户，之后在该网站上确定机票预订信息，以使得虚拟支付系统可以接收到用户确定的机票预订信息，其中，机票预订信息中包括预订的机票的相关信息，消费金额，预订该机票预订信息的账户，预订该机票预订信息的时间等。

[0051] 虚拟支付系统在确定发出机票预订信息的账户后，还需要确定针对机票预订信息的支付方式，虚拟支付系统发出支付方式询问的信息，即虚拟支付系统向用户的账户发出询问信息，询问用户的账户采用哪一种支付方式进行虚拟支付。

[0052] 其中，支付方式主要包括：网上银行支付、第三方支付平台支付以及虚拟支付。

[0053] 用户通过账户反馈支付方式，若用户反馈的支付方式为虚拟支付，则虚拟支付系统可以确定支付方式为虚拟支付。

[0054] 在确定用户的账户之后，还需要进一步确定该用户的账户对应的虚拟账户，通常每一个账户下会有一个虚拟账户，但是并不排除一个账户对应多个虚拟账户。

[0055] 为了方便表述，将账户的虚拟账户设定为第一虚拟账户，第一虚拟账户是与实体账户相关联的。

[0056] 其中，实体账户是真实的银行账户，如：中国银行的6228 8888 8888 8888，如：中国农业银行的6228 4888 8888 8888 888。

[0057] 而虚拟账户是实体账户中的虚拟账户，是在实体账户中划分出来的，虚拟账户在银行层面会有一个后缀子账户的划分，即虚拟账户是实体账户中的子账户，如：实体账户为：某银行的账号1234567890，第一虚拟账户可以为1234567890-0001，第二虚拟账户可以为1234567890-0002等。

[0058] 实体账户中可以包括多个虚拟账户，即包括多个子账户，而每个虚拟账户可以分别属于不同的用户账户，如：第一虚拟账户属于第一用户账户，第二虚拟账户属于第二用户账户，第N虚拟账户属于航空公司名下的账户等。

[0059] 由于一个实体账户中包括多个虚拟账户，每个虚拟账户中通常均会有一定的虚拟货币金额。具体的，可以为：用户账户若要实现虚拟交易，就需要首先在实体账户下注册一个虚拟账户，在注册虚拟账户后，可通过移动终端或者线下方式为该虚拟账户充值，使虚拟账户中有虚拟货币，在为虚拟账户充值后，实体账户中也会增加同样的充值金额；或者，在需要进行虚拟支付时，通过移动终端或者线下方式为该虚拟账户充值，以使该虚拟账户中有虚拟货币，能够进行虚拟支付。

[0060] 例如：为第一虚拟账户充值1000元，由于第一虚拟账户是与实体账户相关联的，那么，与第一虚拟账户相关联的实体账户中也会被充值1000元。

[0061] 由于一个实体账户下有多个虚拟账户，而每个虚拟账户分属于不同的用户账户，在为第一虚拟账户充值时，对其他虚拟账户没有任何影响，而实体账户的金额也会增加充值的金额；在为其他虚拟账户充值时，对第一虚拟账户也没有任何影响，而同时实体账户的金额也会增加充值的金额。

[0062] 本实施例中的实体账户可以为：一个航空公司名下的实体账户，而与该实体账户关联的虚拟账户，则分别是与该航空公司有过交易的用户账户的虚拟账户，或者是将要与该航空公司有交易的用户的虚拟账户，一个实体账户下的多个虚拟账户可分属于不同的用户账户，当然，与实体账户有关联的多个虚拟账户中必然至少包括一个属于该航空公司名下的虚拟账户，用于与该实体账户下的其他用户账户的虚拟账户进行虚拟货币交易。

[0063] 进一步的，若采用除虚拟支付外的其他支付方式时，如：选择第三方支付平台支付，如：支付宝支付，则不采用本实施例所公开的方案，而是继续沿用原有的支付方式，只是会存在支付限额的问题，同时也会存在第三方支付平台通过收取的手续差价赚取手续费的问题。

[0064] 步骤S14、获取第一虚拟账户的虚拟支付密码，进行虚拟支付；

[0065] 在确定采用虚拟支付的方式进行支付时，虚拟支付系统会向用户账户所在端发送一个界面，该界面为输入支付密码的界面，以便用户输入支付密码，在用户输入支付密码后，虚拟支付系统获取到该支付密码，对该支付密码进行有效性验证，如果有效，则继续执行后续步骤，进行虚拟支付，如果无效，则发送支付密码错误的提示窗口至用户账户端。

[0066] 步骤S15、依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币；

[0067] 步骤S16、在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟货币，其中，设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户，第二虚拟账户与实体账户关联。

[0068] 在确定支付密码有效后，继续进行虚拟支付，虚拟支付过程中，将该用户账户对应的虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币，同时，在机票预订信息所在航空公司的虚拟账户中增加该消费金额等额的虚拟货币。

[0069] 即首先确定机票预订信息中的消费金额，之后确定机票预订信息所在航空公司的虚拟账户，即第二虚拟账户，将第一虚拟账户中与消费金额等额的虚拟货币转移至第二虚拟账户中，其具体表现即为第一虚拟账户中被扣除了与消费金额等额的虚拟货币，而第二虚拟账户中增加了与消费金额等额的虚拟货币，即完成了虚拟支付。

[0070] 在上述虚拟支付的过程中，无论是第一虚拟账户还是第二虚拟账户，均与同一个实体账户相关联，属于该实体账户的子账户，在虚拟货币从第一个子账户转移至第二个子账户的过程中，该实体账户的总金额并未发生变化，因此，在银行的真实账户金额并未发生变化，只是该真实账户中的一部分金额从一个子账户转移至另一个子账户，这属于真实账户内部的账户管理，并非是将真实账户中的金额增加或减少，因此，真实账户中的子账户之间虚拟货币的转移并不受到银行限额的限制。

[0071] 如图2所示，图2为银行的实体账户，实体账户的账号为1234567890，与该实体账户相关联的虚拟账户包括：用户A的虚拟账户1234567890-0001，用户B的虚拟账户1234567890-0002，第一航空公司的虚拟账户1234567890-0011，第二航空公司的虚拟账户
1234567890-0012，上述4个虚拟账户均与该实体账户相关联，属于该实体账户的子账户。

[0072] 当用户A购买第一航空公司航班时，用户A将与该航班对应的消费金额从用户A的虚拟账户转移至第一航空公司的虚拟账户；当用户B购买第一航空公司航班时，用户B将与该航班对应的消费金额从用户B的虚拟账户转移至第一航空公司的虚拟账户；当然，用户A及用户B也可以购买第二航空公司的航班，在此只是举例说明，并不对哪一个用户购买哪一个公司的产品进行限定。

[0073] 从图2中可以看出，无论是用户A购买第一航空公司的产品，还是用户B购买第二航空公司的产品，其均是在实体账户1234567890内部进行的交易，实体账户1234567890的总金额并不会变化。

[0074] 本方案通过采用实体账户内部的子账户进行交易，避免采用第三方支付平台，即变了央行规定的限额的问题；其次，采用内部子账户之间的交易，无需交易手续费，节省了开支费用；另外，本方案在进行虚拟支付时，无需连接银行网关，只是航空公司B2B网站与虚拟支付系统之间的交互，请求处理更高效，提高了用户体验。

[0075] 本实施例公开的虚拟支付方法，获取机票预订信息，依据机票预订信息确定发出机票预订信息的账户，以及，确定针对机票预订信息的支付方式为虚拟支付，确定账户的虚拟账户，设定账户的虚拟账户为第一虚拟账户，第一虚拟账户与实体账户关联，获取第一虚拟账户的虚拟支付密码，进行虚拟支付，依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币，在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟账户，设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户，第二虚拟账户与实体账户关联。本申请中，第一虚拟账户与实体账户关联，第二虚拟账户与实体账户关联，即不同账户的虚拟账户均与实体账户关联，在通过虚拟支付进行机票预订信息的支付时，实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换，在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化，但是与多个不同虚拟账户关联的实体账户的总金额不变，即实体账户中的实际货币金额未发生变化，那么，就不会受到央行施行办法的限制，不采用第三方交易平台，直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付，在同一个账户下进行不同虚拟账户间的余额交换，没有每日或每年的交易限额。

[0076] 本实施例公开了一种虚拟支付方法，其流程图如图3所示，包括：

[0077] 步骤S31、获取机票预订信息；

[0078] 步骤S32、依据机票预订信息确定发出机票预订信息的账户；

[0079] 步骤S33、对账户的有效性进行验证，若验证通过，确定针对机票预订信息的支付方式为虚拟支付；

[0080] 步骤S34、确定账户的虚拟账户，设定账户的虚拟账户为第一虚拟账户，第一虚拟账户与实体账户关联；

[0081] 步骤S35、获取第一虚拟账户的虚拟支付密码，进行虚拟支付；

[0082] 步骤S36、依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币；

[0083] 步骤S37、在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟货币，其中，设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户，第二虚拟账户与实体账户关联。

[0084] 在用户通过账户发出机票预订信息，并由虚拟支付系统接收到该机票预订信息后，确定发出该机票预订信息的账户，之后，由虚拟支付系统对账户的有效性进行验证。

[0085] 对账户的有效性进行验证，可具体为：验证账户中的相关信息是否过期，或者，验证该账户发出的机票预订信息是否有效，或者，验证该账户对应的虚拟账户中是否有虚拟货币，或者，验证该账户对应的虚拟账户中的虚拟货币是否足够支付机票预订信息的消费金额。

[0086] 无论对账户的有效性进行验证是验证的哪一方面的有效性，都是为了使机票预订信息能够被顺利支付，以及用户可正常进行其预订的行程。

[0087] 另外，对虚拟账户中的虚拟货币余额进行查询的步骤，可以在对账户的有效性进行验证的时候进行，也可以单独进行，即用户的账户可通过虚拟支付系统对虚拟账户的虚拟货币余额进行查询，以确定虚拟账户的虚拟货币的余额的值。

[0088] 每一个用户的账户均可以对与其对应的虚拟账户中虚拟货币的余额的值进行查询，但是并不能对其他用户的账户中虚拟货币的余额的值进行查询，以保证用户的账户中信息的安全性。

[0089] 其查询时机可以为：在用户登录账户后，进行其他操作之前，直接通过虚拟支付系统对虚拟账户的虚拟货币余额进行查询；另外，也可以为：在进行机票预订时，在用户在账户中输入机票预订信息，但是将机票预订信息发送至虚拟支付系统之前，通过虚拟支付系统对虚拟账户的虚拟货币余额进行查询。

[0090] 另外，还可以为：虚拟支付系统确定机票预订信息中的消费金额的值，若第一虚拟账户的虚拟货币余额的值大于机票预订信息中的消费金额的值，则将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币。

[0091] 即在进行虚拟支付时，首先确定第一虚拟账户中的虚拟货币余额，只有当第一虚拟账户中虚拟货币余额的值大于机票预订信息中的消费金额的值时，才会继续进行支付，而在第一虚拟账户中虚拟货币余额的值小于机票预订信息中的消费金额的值时，是不能完成支付的，因此，此时，停止继续支付，可以输出为第一虚拟账户充值虚拟货币的对话框，以便用户通过该对话框为第一虚拟账户进行充值，从而使得该虚拟支付能够顺利完成。

[0092] 进一步的，还包括：申请实体账户；在申请通过后在实体账户的基础上，注册多个虚拟账户，多个虚拟账户分别属于不同的账户，不同的账户的虚拟账户分别于实体账户关联。

[0093] 在实体账户及虚拟账户的关联关系上，可以为：首先申请实体账户，之后直接在该实体账户内注册多个分属于不同用户账户的虚拟账户，从而实现分属于不同用户账户的虚拟账户与同一个实体账户之间的关联；

[0094] 还可以为：首先注册虚拟账户，之后申请实体账户，在虚拟账户与实体账户均存在之后，再建立虚拟账户与实体账户之间的关联关系，以使得多个分属于不同用户账户的虚拟账户可以作为同一个实体账户的子账户；

[0095] 或者，在注册虚拟账户的同时，申请实体账户，之后再建立虚拟账户与实体账户之间的关联关系，以使得多个分属于不同用户账户的虚拟账户可以作为同一个实体账户的子账户。

[0096] 本方案可以基于虚拟支付装置完成，具体的，该虚拟支付装置的结构示意图如图4所示，包括：虚拟账户管理组件41，航空公司销售组件42及支付执行组件43。

[0097] 其中，虚拟账户管理组件，用于管理虚拟账户信息，包括：航空公司、用户等账户的主体信息，账户下虚拟货币余额信息以及虚拟货币交易明细信息，管理实体账户信息，支持向银行注册实体账户，并绑定相关交易实体，如：航空公司或用户等的虚拟账户。

[0098] 航空公司销售组件，用于接收用户的机票预订信息，处理后解析机票预订信息中的支付方式，并将虚拟支付方式下的支付信息发送至支付执行组件，支付请求信息中包括航空公司的虚拟账户信息、用户的虚拟账户信息即订单消费金额等。

[0099] 支付执行组件，用于对用户在航空公司B2B站点发起的交易中支付虚拟货币行为的业务处理，首先获取发出机票预订信息的用户账户在虚拟账户管理组件中的虚拟货币的余额，再根据机票预订信息判断该交易是否成立，若成立则执行虚拟支付流程，并将结果反馈至用户的终端。

[0100] 本实施例公开的虚拟支付方法，获取机票预订信息，依据机票预订信息确定发出机票预订信息的账户，以及，确定针对机票预订信息的支付方式为虚拟支付，确定账户的虚拟账户，设定账户的虚拟账户为第一虚拟账户，第一虚拟账户与实体账户关联，获取第一虚拟账户的虚拟支付密码，进行虚拟支付，依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币，在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟账户，设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户，第二虚拟账户与实体账户关联。本申请中，第一虚拟账户与实体账户关联，第二虚拟账户与实体账户关联，即不同账户的虚拟账户均与实体账户关联，在通过虚拟支付进行机票预订信息的支付时，实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换，在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化，但是与多个不同虚拟账户关联的实体账户的总金额不变，即实体账户中的实际货币金额未发生变化，那么，就不会受到央行施行办法的限制，不采用第三方交易平台，直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付，在同一个账户下进行不同虚拟账户间的余额交换，没有每日或每年的交易限额。

[0101] 本实施例公开了一种虚拟支付系统，其结构示意图如图5所示，包括：

[0102] 预订信息获取单元51，第一确定单元52，虚拟账户确定单元53，密码获取单元54，扣除单元55及增加单元56。

[0103] 其中，预订信息获取单元51用于获取机票预订信息；

[0104] 第一确定单元52用于依据机票预订信息确定发出机票预订信息的账户，以及，确定针对机票预订信息的支付方式为虚拟支付；

[0105] 虚拟账户确定单元53用于确定账户的虚拟账户，设定账户的虚拟账户为第一虚拟账户，第一虚拟账户与实体账户关联；

[0106] 密码获取单元54用于获取第一虚拟账户的虚拟支付密码，进行虚拟支付；

[0107] 扣除单元55用于依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币；

[0108] 增加单元56用于在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟货币，其中，设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户，第二虚拟账户与实体账户关联。

[0109] 用户登录航空公司的网站的账户，之后在该网站上确定机票预订信息，以使得虚拟支付系统可以接收到用户确定的机票预订信息，其中，机票预订信息中包括预订的机票的相关信息，消费金额，预订该机票预订信息的账户，预订该机票预订信息的时间等。

[0110] 虚拟支付系统在确定发出机票预订信息的账户后，还需要确定针对机票预订信息的支付方式，虚拟支付系统发出支付方式询问的信息，即虚拟支付系统向用户的账户发出询问信息，询问用户的账户采用哪一种支付方式进行虚拟支付。

[0111] 其中，支付方式主要包括：网上银行支付、第三方支付平台支付以及虚拟支付。

[0112] 用户通过账户反馈支付方式，若用户反馈的支付方式为虚拟支付，则虚拟支付系统可以确定支付方式为虚拟支付。

[0113] 在确定用户的账户之后，还需要进一步确定该用户的账户对应的虚拟账户，通常每一个账户下会有一个虚拟账户，但是并不排除一个账户对应多个虚拟账户。

[0114] 为了方便表述，将账户的虚拟账户设定为第一虚拟账户，第一虚拟账户是与实体账户相关联的。

[0115] 其中，实体账户是真实的银行账户，如：中国银行的6228 8888 8888 8888，如：中国农业银行的6228 4888 8888 8888 888。

[0116] 而虚拟账户是实体账户中的虚拟账户，是在实体账户中划分出来的，虚拟账户在银行层面会有一个后缀子账户的划分，即虚拟账户是实体账户中的子账户，如：实体账户为：某银行的账号1234567890，第一虚拟账户可以为1234567890-0001，第二虚拟账户可以为1234567890-0002等。

[0117] 实体账户中可以包括多个虚拟账户，即包括多个子账户，而每个虚拟账户可以分别属于不同的用户账户，如：第一虚拟账户属于第一用户账户，第二虚拟账户属于第二用户账户，第N虚拟账户属于航空公司名下的账户等。

[0118] 由于一个实体账户中包括多个虚拟账户，每个虚拟账户中通常均会有一定的虚拟货币金额。具体的，可以为：用户账户若要实现虚拟交易，就需要首先在实体账户下注册一个虚拟账户，在注册虚拟账户后，可通过移动终端或者线下方式为该虚拟账户充值，使虚拟账户中有虚拟货币，在为虚拟账户充值后，实体账户中也会增加同样的充值金额；或者，在需要进行虚拟支付时，通过移动终端或者线下方式为该虚拟账户充值，以使该虚拟账户中有虚拟货币，能够进行虚拟支付。

[0119] 例如：为第一虚拟账户充值1000元，由于第一虚拟账户是与实体账户相关联的，那么，与第一虚拟账户相关联的实体账户中也会被充值1000元。

[0120] 由于一个实体账户下有多个虚拟账户，而每个虚拟账户分属于不同的用户账户，在为第一虚拟账户充值时，对其他虚拟账户没有任何影响，而实体账户的金额也会增加充值的金额；在为其他虚拟账户充值时，对第一虚拟账户也没有任何影响，而同时实体账户的金额也会增加充值的金额。

[0121] 本实施例中的实体账户可以为：一个航空公司名下的实体账户，而与该实体账户关联的虚拟账户，则分别是与该航空公司有过交易的用户账户的虚拟账户，或者是将要与该航空公司有交易的用户的虚拟账户，一个实体账户下的多个虚拟账户可分属于不同的用户账户，当然，与实体账户有关联的多个虚拟账户中必然至少包括一个属于该航空公司名下的虚拟账户，用于与该实体账户下的其他用户账户的虚拟账户进行虚拟货币交易。

[0122] 进一步的，若采用除虚拟支付外的其他支付方式时，如：选择第三方支付平台支付，如：支付宝支付，则不采用本实施例所公开的方案，而是继续沿用原有的支付方式，只是会存在支付限额的问题，同时也会存在第三方支付平台通过收取的手续差价赚取手续费的问题。

[0123] 在确定采用虚拟支付的方式进行支付时，虚拟支付系统会向用户账户所在端发送一个界面，该界面为输入支付密码的界面，以便用户输入支付密码，在用户输入支付密码后，虚拟支付系统获取到该支付密码，对该支付密码进行有效性验证，如果有效，则继续执行后续步骤，进行虚拟支付，如果无效，则发送支付密码错误的提示窗口至用户账户端。

[0124] 在确定支付密码有效后，继续进行虚拟支付，虚拟支付过程中，将该用户账户对应的虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币，同时，在机票预订信息所在航空公司的虚拟账户中增加该消费金额等额的虚拟货币。

[0125] 即首先确定机票预订信息中的消费金额，之后确定机票预订信息所在航空公司的虚拟账户，即第二虚拟账户，将第一虚拟账户中与消费金额等额的虚拟货币转移至第二虚拟账户中，其具体表现即为第一虚拟账户中被扣除了与消费金额等额的虚拟货币，而第二虚拟账户中增加了与消费金额等额的虚拟货币，即完成了虚拟支付。

[0126] 在上述虚拟支付的过程中，无论是第一虚拟账户还是第二虚拟账户，均与同一个实体账户相关联，属于该实体账户的子账户，在虚拟货币从第一个子账户转移至第二个子账户的过程中，该实体账户的总金额并未发生变化，因此，在银行的真实账户金额并未发生变化，只是该真实账户中的一部分金额从一个子账户转移至另一个子账户，这属于真实账户内部的账户管理，并非是将真实账户中的金额增加或减少，因此，真实账户中的子账户之间虚拟货币的转移并不受到银行限额的限制。

[0127] 如图2所示，图2为银行的实体账户，实体账户的账号为1234567890，与该实体账户相关联的虚拟账户包括：用户A的虚拟账户1234567890-0001，用户B的虚拟账户1234567890-0002，第一航空公司的虚拟账户1234567890-0011，第二航空公司的虚拟账户
1234567890-0012，上述4个虚拟账户均与该实体账户相关联，属于该实体账户的子账户。

[0128] 当用户A购买第一航空公司航班时，用户A将与该航班对应的消费金额从用户A的虚拟账户转移至第一航空公司的虚拟账户；当用户B购买第一航空公司航班时，用户B将与该航班对应的消费金额从用户B的虚拟账户转移至第一航空公司的虚拟账户；当然，用户A及用户B也可以购买第二航空公司的航班，在此只是举例说明，并不对哪一个用户购买哪一个公司的产品进行限定。

[0129] 从图2中可以看出，无论是用户A购买第一航空公司的产品，还是用户B购买第二航空公司的产品，其均是在实体账户1234567890内部进行的交易，实体账户1234567890的总金额并不会变化。

[0130] 本方案通过采用实体账户内部的子账户进行交易，避免采用第三方支付平台，即变了央行规定的限额的问题；其次，采用内部子账户之间的交易，无需交易手续费，节省了开支费用；另外，本方案在进行虚拟支付时，无需连接银行网关，只是航空公司B2B网站与虚拟支付系统之间的交互，请求处理更高效，提高了用户体验。

[0131] 进一步的，第一确定单元52用于依据机票预订信息确定发出机票预订信息的账户；对账户的有效性进行验证，若验证通过，则确定针对机票预订信息的支付方式为虚拟支付。

[0132] 在用户通过账户发出机票预订信息，并由虚拟支付系统接收到该机票预订信息后，确定发出该机票预订信息的账户，之后，由虚拟支付系统对账户的有效性进行验证。

[0133] 对账户的有效性进行验证，可具体为：验证账户中的相关信息是否过期，或者，验证该账户发出的机票预订信息是否有效，或者，验证该账户对应的虚拟账户中是否有虚拟货币，或者，验证该账户对应的虚拟账户中的虚拟货币是否足够支付机票预订信息的消费金额。

[0134] 无论对账户的有效性进行验证是验证的哪一方面的有效性，都是为了使机票预订信息能够被顺利支付，以及用户可正常进行其预订的行程。

[0135] 另外，对虚拟账户中的虚拟货币余额进行查询的步骤，可以在对账户的有效性进行验证的时候进行，也可以单独进行，即：本实施例公开的虚拟支付系统还包括：查询单元，用于对所述第一虚拟账户的虚拟货币余额进行查询，以确定所述第一虚拟账户的虚拟货币余额的值。

[0136] 每一个用户的账户均可以对与其对应的虚拟账户中虚拟货币的余额的值进行查询，但是并不能对其他用户的账户中虚拟货币的余额的值进行查询，以保证用户的账户中信息的安全性。

[0137] 其查询时机可以为：在用户登录账户后，进行其他操作之前，直接通过虚拟支付系统对虚拟账户的虚拟货币余额进行查询；另外，也可以为：在进行机票预订时，在用户在账户中输入机票预订信息，但是将机票预订信息发送至虚拟支付系统之前，通过虚拟支付系统对虚拟账户的虚拟货币余额进行查询。

[0138] 另外，还可以为：虚拟支付系统确定机票预订信息中的消费金额的值，若第一虚拟账户的虚拟货币余额的值大于机票预订信息中的消费金额的值，则将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币。

[0139] 即在进行虚拟支付时，首先确定第一虚拟账户中的虚拟货币余额，只有当第一虚拟账户中虚拟货币余额的值大于机票预订信息中的消费金额的值时，才会继续进行支付，而在第一虚拟账户中虚拟货币余额的值小于机票预订信息中的消费金额的值时，是不能完成支付的，因此，此时，停止继续支付，可以输出为第一虚拟账户充值虚拟货币的对话框，以便用户通过该对话框为第一虚拟账户进行充值，从而使得该虚拟支付能够顺利完成。

[0140] 本实施例公开的虚拟支付系统还包括：申请单元，用于申请实体账户；在申请通过后的实体账户的基础上，注册多个虚拟账户，多个虚拟账户分别属于不同的账户，不同的账户的虚拟账户分别与实体账户关联。

[0141] 在实体账户及虚拟账户的关联关系上，可以为：首先申请实体账户，之后直接在该实体账户内注册多个分属于不同用户账户的虚拟账户，从而实现分属于不同用户账户的虚拟账户与同一个实体账户之间的关联；

[0142] 还可以为：首先注册虚拟账户，之后申请实体账户，在虚拟账户与实体账户均存在之后，再建立虚拟账户与实体账户之间的关联关系，以使得多个分属于不同用户账户的虚拟账户可以作为同一个实体账户的子账户；

[0143] 或者，在注册虚拟账户的同时，申请实体账户，之后再建立虚拟账户与实体账户之间的关联关系，以使得多个分属于不同用户账户的虚拟账户可以作为同一个实体账户的子账户。

[0144] 本方案可以基于虚拟支付装置完成，具体的，该虚拟支付装置的结构示意图如图4所示，包括：虚拟账户管理组件41，航空公司销售组件42及支付执行组件43。

[0145] 其中，虚拟账户管理组件，用于管理虚拟账户信息，包括：航空公司、用户等账户的主体信息，账户下虚拟货币余额信息以及虚拟货币交易明细信息，管理实体账户信息，支持向银行注册实体账户，并绑定相关交易实体，如：航空公司或用户等的虚拟账户。

[0146] 航空公司销售组件，用于接收用户的机票预订信息，处理后解析机票预订信息中的支付方式，并将虚拟支付方式下的支付信息发送至支付执行组件，支付请求信息中包括航空公司的虚拟账户信息、用户的虚拟账户信息即订单消费金额等。

[0147] 支付执行组件，用于对用户在航空公司B2B站点发起的交易中支付虚拟货币行为的业务处理，首先获取发出机票预订信息的用户账户在虚拟账户管理组件中的虚拟货币的余额，再根据机票预订信息判断该交易是否成立，若成立则执行虚拟支付流程，并将结果反馈至用户的终端。

[0148] 本实施例公开的虚拟支付系统，获取机票预订信息，依据机票预订信息确定发出机票预订信息的账户，以及，确定针对机票预订信息的支付方式为虚拟支付，确定账户的虚拟账户，设定账户的虚拟账户为第一虚拟账户，第一虚拟账户与实体账户关联，获取第一虚拟账户的虚拟支付密码，进行虚拟支付，依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币，在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟账户，设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户，第二虚拟账户与实体账户关联。本申请中，第一虚拟账户与实体账户关联，第二虚拟账户与实体账户关联，即不同账户的虚拟账户均与实体账户关联，在通过虚拟支付进行机票预订信息的支付时，实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换，在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化，但是与多个不同虚拟账户关联的实体账户的总金额不变，即实体账户中的实际货币金额未发生变化，那么，就不会受到央行施行办法的限制，不采用第三方交易平台，直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付，在同一个账户下进行不同虚拟账户间的余额交换，没有每日或每年的交易限额。

[0149] 本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

[0150] 专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

[0151] 结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

[0152] 对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

标题	发布/更新时间	阅读量
IC卡、处理方法以及信息处理系统	2020-05-13	302
基于区块链架构和物理标记的虚拟货币系统	2020-05-17	189
提供装置、处理系统以及通信方法	2020-05-14	106
一种采用虚拟辅币限制交易的方法及服务器系统	2020-05-16	852
网络系统、以及用于该网络系统的服务器装置、服务器装置的控制方法	2020-05-17	316
一种服务器挖矿病毒防护的系统和方法	2020-05-18	539
商品购买价款支付的损益的通知系统、方法以及程序	2020-05-08	905
数字孪生世界基于区块链的物联网身份认证系统与方法	2020-05-13	215
一种代码静态分析方法和装置	2020-05-16	672
虛擬貨幣之儲存及交易裝置	2020-05-16	654

一种虚拟支付方法及系统

一种虚拟支付方法及系统

技术领域

背景技术

具体实施方式

该功能需要专业版企业版VIP权限，您可以：