CN110930138A - 一种虚拟支付方法及*** - Google Patents

一种虚拟支付方法及*** Download PDF

Info

Publication number
CN110930138A
CN110930138A CN201911154491.4A CN201911154491A CN110930138A CN 110930138 A CN110930138 A CN 110930138A CN 201911154491 A CN201911154491 A CN 201911154491A CN 110930138 A CN110930138 A CN 110930138A
Authority
CN
China
Prior art keywords
virtual
account
payment
reservation information
air ticket
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201911154491.4A
Other languages
English (en)
Inventor
张志丹
张素娟
辛颖
李艳娜
李雪
王晓亮
费笑峰
张永旺
蒋中林
宋欣卉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Travelsky Technology Co Ltd
Original Assignee
China Travelsky Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Travelsky Technology Co Ltd filed Critical China Travelsky Technology Co Ltd
Priority to CN201911154491.4A priority Critical patent/CN110930138A/zh
Publication of CN110930138A publication Critical patent/CN110930138A/zh
Priority to PCT/CN2020/126074 priority patent/WO2021098502A1/zh
Priority to KR1020227007929A priority patent/KR20220045016A/ko
Priority to US17/641,795 priority patent/US20220374889A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/227Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/02Reservations, e.g. for tickets, services or events
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/04Payment circuits
    • G06Q20/06Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/12Payment architectures specially adapted for electronic shopping systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/14Payment architectures specially adapted for billing systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/351Virtual cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/385Payment protocols; Details thereof using an alias or single-use codes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401Transaction verification
    • G06Q20/4014Identity check for transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/40Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405Establishing or using transaction specific rules

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Tourism & Hospitality (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

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

Description

一种虚拟支付方法及***
技术领域
本申请涉及控制领域,尤其涉及一种虚拟支付方法及***。
背景技术
航空公司B2B(Business-to-Business)网站,是航空公司面向机票代理人销售机票的渠道,代理人在网站上进行机票查询预订和支付,当前,航空公司B2B网站在线支付中,基于实体货币的第三方支付占很大比例,如:通过支付窗进行支付,或,通过串票平台支付。
目前,各航空公司B2B网站全年支付额大约1000亿左右,然而,2016年7月1日起,中国人民银行施行了《非银行支付机构网络支付业务管理办法》,限制了第三方支付平台账户的支付,比如:对个人客户使用支付账户付款的交易进行限额管理,其中单日累计交易限额1000元、5000元,年累计交易限额10万元、20万元。这就导致用户通过第三方平台在各航空公司B2B网站进行交易时,由于限额问题导致的交易不能顺利进行的问题。
发明内容
有鉴于此,本申请提供一种虚拟支付方法及***,其具体方案如下:
一种虚拟支付方法,包括:
获取机票预订信息;
依据所述机票预订信息确定发出所述机票预订信息的账户,以及,确定针对所述机票预订信息的支付方式为虚拟支付;
确定所述账户的虚拟账户,设定所述账户的虚拟账户为第一虚拟账户,所述第一虚拟账户与实体账户关联;
获取所述第一虚拟账户的虚拟支付密码,进行虚拟支付;
依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币;
在所述机票预订信息所在航空公司的虚拟账户中增加与所述机票预订信息中的消费金额等额的虚拟货币,其中,设定所述机票预订信息所在航空公司的虚拟账户为第二虚拟账户,所述第二虚拟账户与所述实体账户关联。
进一步的,所述依据所述机票预订信息确定发出所述机票预订信息的账户,以及,确定针对所述机票预订信息的支付方式为虚拟支付,包括:
依据所述机票预订信息确定发出所述机票预订信息的账户;
对所述账户的有效性进行验证,若验证通过,则确定针对所述机票预订信息的支付方式为虚拟支付。
进一步的,还包括:
对所述第一虚拟账户的虚拟货币余额进行查询,以确定所述第一虚拟账户的虚拟货币余额的值。
进一步的,所述依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币,包括:
确定所述机票预订信息中的消费金额的值;
若所述第一虚拟账户的虚拟货币余额的值大于所述机票预订信息中的消费金额的值,则将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币。
进一步的,还包括:
申请实体账户;
在申请通过后的所述实体账户的基础上,注册多个虚拟账户,所述多个虚拟账户分别属于不同的账户,所述不同的账户的虚拟账户分别与所述实体账户关联。
一种虚拟支付***,包括:
预订信息获取单元,用于获取机票预订信息;
第一确定单元,用于依据所述机票预订信息确定发出所述机票预订信息的账户,以及,确定针对所述机票预订信息的支付方式为虚拟支付;
虚拟账户确定单元,用于确定所述账户的虚拟账户,设定所述账户的虚拟账户为第一虚拟账户,所述第一虚拟账户与实体账户关联;
密码获取单元,用于获取所述第一虚拟账户的虚拟支付密码,进行虚拟支付;
扣除单元,用于依据所述虚拟支付将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币;
增加单元,用于在所述机票预订信息所在航空公司的虚拟账户中增加与所述机票预订信息中的消费金额等额的虚拟货币,其中,设定所述机票预订信息所在航空公司的虚拟账户为第二虚拟账户,所述第二虚拟账户与所述实体账户关联。
进一步的,所述第一确定单元用于:
依据所述机票预订信息确定发出所述机票预订信息的账户;对所述账户的有效性进行验证,若验证通过,则确定针对所述机票预订信息的支付方式为虚拟支付。
进一步的,还包括:
查询单元,用于对所述第一虚拟账户的虚拟货币余额进行查询,以确定所述第一虚拟账户的虚拟货币余额的值。
进一步的,所述扣除单元用于:
确定所述机票预订信息中的消费金额的值;若所述第一虚拟账户的虚拟货币余额的值大于所述机票预订信息中的消费金额的值,则将所述第一虚拟账户中的虚拟货币余额扣除与所述机票预订信息中的消费金额等额的虚拟货币。
进一步的,还包括:
申请单元,用于申请实体账户;在申请通过后的所述实体账户的基础上,注册多个虚拟账户,所述多个虚拟账户分别属于不同的账户,所述不同的账户的虚拟账户分别与所述实体账户关联。
从上述技术方案可以看出,本申请公开的虚拟支付方法及***,获取机票预订信息,依据机票预订信息确定发出机票预订信息的账户,以及,确定针对机票预订信息的支付方式为虚拟支付,确定账户的虚拟账户,设定账户的虚拟账户为第一虚拟账户,第一虚拟账户与实体账户关联,获取第一虚拟账户的虚拟支付密码,进行虚拟支付,依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币,在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟账户,设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户,第二虚拟账户与实体账户关联。本申请中,第一虚拟账户与实体账户关联,第二虚拟账户与实体账户关联,即不同账户的虚拟账户均与实体账户关联,在通过虚拟支付进行机票预订信息的支付时,实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换,在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化,但是与多个不同虚拟账户关联的实体账户的总金额不变,即实体账户中的实际货币金额未发生变化,那么,就不会受到央行施行办法的限制,不采用第三方交易平台,直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付,在同一个账户下进行不同虚拟账户间的余额交换,没有每日或每年的交易限额。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例公开的一种虚拟支付方法的流程图;
图2为本申请实施例公开的一种实体账户与虚拟账户之间的关系图;
图3为本申请实施例公开的一种虚拟支付方法的流程图;
图4为本申请实施例公开的一种虚拟支付装置的结构示意图;
图5为本申请实施例公开的一种虚拟支付***的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请公开了一种虚拟支付方法,其流程图如图1所示,包括:
步骤S11、获取机票预订信息;
步骤S12、依据机票预订信息确定发出机票预订信息的账户,以及,确定针对机票预订信息的支付方式为虚拟支付;
步骤S13、确定账户的虚拟账户,设定账户的虚拟账户为第一虚拟账户,第一虚拟账户与实体账户关联;
用户登录航空公司的网站的账户,之后在该网站上确定机票预订信息,以使得虚拟支付***可以接收到用户确定的机票预订信息,其中,机票预订信息中包括预订的机票的相关信息,消费金额,预订该机票预订信息的账户,预订该机票预订信息的时间等。
虚拟支付***在确定发出机票预订信息的账户后,还需要确定针对机票预订信息的支付方式,虚拟支付***发出支付方式询问的信息,即虚拟支付***向用户的账户发出询问信息,询问用户的账户采用哪一种支付方式进行虚拟支付。
其中,支付方式主要包括:网上银行支付、第三方支付平台支付以及虚拟支付。
用户通过账户反馈支付方式,若用户反馈的支付方式为虚拟支付,则虚拟支付***可以确定支付方式为虚拟支付。
在确定用户的账户之后,还需要进一步确定该用户的账户对应的虚拟账户,通常每一个账户下会有一个虚拟账户,但是并不排除一个账户对应多个虚拟账户。
为了方便表述,将账户的虚拟账户设定为第一虚拟账户,第一虚拟账户是与实体账户相关联的。
其中,实体账户是真实的银行账户,如:中国银行的6228 8888 8888 8888,如:中国农业银行的6228 4888 8888 8888 888。
而虚拟账户是实体账户中的虚拟账户,是在实体账户中划分出来的,虚拟账户在银行层面会有一个后缀子账户的划分,即虚拟账户是实体账户中的子账户,如:实体账户为:某银行的账号1234567890,第一虚拟账户可以为1234567890-0001,第二虚拟账户可以为1234567890-0002等。
实体账户中可以包括多个虚拟账户,即包括多个子账户,而每个虚拟账户可以分别属于不同的用户账户,如:第一虚拟账户属于第一用户账户,第二虚拟账户属于第二用户账户,第N虚拟账户属于航空公司名下的账户等。
由于一个实体账户中包括多个虚拟账户,每个虚拟账户中通常均会有一定的虚拟货币金额。具体的,可以为:用户账户若要实现虚拟交易,就需要首先在实体账户下注册一个虚拟账户,在注册虚拟账户后,可通过移动终端或者线下方式为该虚拟账户充值,使虚拟账户中有虚拟货币,在为虚拟账户充值后,实体账户中也会增加同样的充值金额;或者,在需要进行虚拟支付时,通过移动终端或者线下方式为该虚拟账户充值,以使该虚拟账户中有虚拟货币,能够进行虚拟支付。
例如:为第一虚拟账户充值1000元,由于第一虚拟账户是与实体账户相关联的,那么,与第一虚拟账户相关联的实体账户中也会被充值1000元。
由于一个实体账户下有多个虚拟账户,而每个虚拟账户分属于不同的用户账户,在为第一虚拟账户充值时,对其他虚拟账户没有任何影响,而实体账户的金额也会增加充值的金额;在为其他虚拟账户充值时,对第一虚拟账户也没有任何影响,而同时实体账户的金额也会增加充值的金额。
本实施例中的实体账户可以为:一个航空公司名下的实体账户,而与该实体账户关联的虚拟账户,则分别是与该航空公司有过交易的用户账户的虚拟账户,或者是将要与该航空公司有交易的用户的虚拟账户,一个实体账户下的多个虚拟账户可分属于不同的用户账户,当然,与实体账户有关联的多个虚拟账户中必然至少包括一个属于该航空公司名下的虚拟账户,用于与该实体账户下的其他用户账户的虚拟账户进行虚拟货币交易。
进一步的,若采用除虚拟支付外的其他支付方式时,如:选择第三方支付平台支付,如:支付宝支付,则不采用本实施例所公开的方案,而是继续沿用原有的支付方式,只是会存在支付限额的问题,同时也会存在第三方支付平台通过收取的手续差价赚取手续费的问题。
步骤S14、获取第一虚拟账户的虚拟支付密码,进行虚拟支付;
在确定采用虚拟支付的方式进行支付时,虚拟支付***会向用户账户所在端发送一个界面,该界面为输入支付密码的界面,以便用户输入支付密码,在用户输入支付密码后,虚拟支付***获取到该支付密码,对该支付密码进行有效性验证,如果有效,则继续执行后续步骤,进行虚拟支付,如果无效,则发送支付密码错误的提示窗口至用户账户端。
步骤S15、依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币;
步骤S16、在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟货币,其中,设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户,第二虚拟账户与实体账户关联。
在确定支付密码有效后,继续进行虚拟支付,虚拟支付过程中,将该用户账户对应的虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币,同时,在机票预订信息所在航空公司的虚拟账户中增加该消费金额等额的虚拟货币。
即首先确定机票预订信息中的消费金额,之后确定机票预订信息所在航空公司的虚拟账户,即第二虚拟账户,将第一虚拟账户中与消费金额等额的虚拟货币转移至第二虚拟账户中,其具体表现即为第一虚拟账户中被扣除了与消费金额等额的虚拟货币,而第二虚拟账户中增加了与消费金额等额的虚拟货币,即完成了虚拟支付。
在上述虚拟支付的过程中,无论是第一虚拟账户还是第二虚拟账户,均与同一个实体账户相关联,属于该实体账户的子账户,在虚拟货币从第一个子账户转移至第二个子账户的过程中,该实体账户的总金额并未发生变化,因此,在银行的真实账户金额并未发生变化,只是该真实账户中的一部分金额从一个子账户转移至另一个子账户,这属于真实账户内部的账户管理,并非是将真实账户中的金额增加或减少,因此,真实账户中的子账户之间虚拟货币的转移并不受到银行限额的限制。
如图2所示,图2为银行的实体账户,实体账户的账号为1234567890,与该实体账户相关联的虚拟账户包括:用户A的虚拟账户1234567890-0001,用户B的虚拟账户1234567890-0002,第一航空公司的虚拟账户1234567890-0011,第二航空公司的虚拟账户1234567890-0012,上述4个虚拟账户均与该实体账户相关联,属于该实体账户的子账户。
当用户A购买第一航空公司航班时,用户A将与该航班对应的消费金额从用户A的虚拟账户转移至第一航空公司的虚拟账户;当用户B购买第一航空公司航班时,用户B将与该航班对应的消费金额从用户B的虚拟账户转移至第一航空公司的虚拟账户;当然,用户A及用户B也可以购买第二航空公司的航班,在此只是举例说明,并不对哪一个用户购买哪一个公司的产品进行限定。
从图2中可以看出,无论是用户A购买第一航空公司的产品,还是用户B购买第二航空公司的产品,其均是在实体账户1234567890内部进行的交易,实体账户1234567890的总金额并不会变化。
本方案通过采用实体账户内部的子账户进行交易,避免采用第三方支付平台,即变了央行规定的限额的问题;其次,采用内部子账户之间的交易,无需交易手续费,节省了开支费用;另外,本方案在进行虚拟支付时,无需连接银行网关,只是航空公司B2B网站与虚拟支付***之间的交互,请求处理更高效,提高了用户体验。
本实施例公开的虚拟支付方法,获取机票预订信息,依据机票预订信息确定发出机票预订信息的账户,以及,确定针对机票预订信息的支付方式为虚拟支付,确定账户的虚拟账户,设定账户的虚拟账户为第一虚拟账户,第一虚拟账户与实体账户关联,获取第一虚拟账户的虚拟支付密码,进行虚拟支付,依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币,在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟账户,设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户,第二虚拟账户与实体账户关联。本申请中,第一虚拟账户与实体账户关联,第二虚拟账户与实体账户关联,即不同账户的虚拟账户均与实体账户关联,在通过虚拟支付进行机票预订信息的支付时,实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换,在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化,但是与多个不同虚拟账户关联的实体账户的总金额不变,即实体账户中的实际货币金额未发生变化,那么,就不会受到央行施行办法的限制,不采用第三方交易平台,直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付,在同一个账户下进行不同虚拟账户间的余额交换,没有每日或每年的交易限额。
本实施例公开了一种虚拟支付方法,其流程图如图3所示,包括:
步骤S31、获取机票预订信息;
步骤S32、依据机票预订信息确定发出机票预订信息的账户;
步骤S33、对账户的有效性进行验证,若验证通过,确定针对机票预订信息的支付方式为虚拟支付;
步骤S34、确定账户的虚拟账户,设定账户的虚拟账户为第一虚拟账户,第一虚拟账户与实体账户关联;
步骤S35、获取第一虚拟账户的虚拟支付密码,进行虚拟支付;
步骤S36、依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币;
步骤S37、在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟货币,其中,设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户,第二虚拟账户与实体账户关联。
在用户通过账户发出机票预订信息,并由虚拟支付***接收到该机票预订信息后,确定发出该机票预订信息的账户,之后,由虚拟支付***对账户的有效性进行验证。
对账户的有效性进行验证,可具体为:验证账户中的相关信息是否过期,或者,验证该账户发出的机票预订信息是否有效,或者,验证该账户对应的虚拟账户中是否有虚拟货币,或者,验证该账户对应的虚拟账户中的虚拟货币是否足够支付机票预订信息的消费金额。
无论对账户的有效性进行验证是验证的哪一方面的有效性,都是为了使机票预订信息能够被顺利支付,以及用户可正常进行其预订的行程。
另外,对虚拟账户中的虚拟货币余额进行查询的步骤,可以在对账户的有效性进行验证的时候进行,也可以单独进行,即用户的账户可通过虚拟支付***对虚拟账户的虚拟货币余额进行查询,以确定虚拟账户的虚拟货币的余额的值。
每一个用户的账户均可以对与其对应的虚拟账户中虚拟货币的余额的值进行查询,但是并不能对其他用户的账户中虚拟货币的余额的值进行查询,以保证用户的账户中信息的安全性。
其查询时机可以为:在用户登录账户后,进行其他操作之前,直接通过虚拟支付***对虚拟账户的虚拟货币余额进行查询;另外,也可以为:在进行机票预订时,在用户在账户中输入机票预订信息,但是将机票预订信息发送至虚拟支付***之前,通过虚拟支付***对虚拟账户的虚拟货币余额进行查询。
另外,还可以为:虚拟支付***确定机票预订信息中的消费金额的值,若第一虚拟账户的虚拟货币余额的值大于机票预订信息中的消费金额的值,则将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币。
即在进行虚拟支付时,首先确定第一虚拟账户中的虚拟货币余额,只有当第一虚拟账户中虚拟货币余额的值大于机票预订信息中的消费金额的值时,才会继续进行支付,而在第一虚拟账户中虚拟货币余额的值小于机票预订信息中的消费金额的值时,是不能完成支付的,因此,此时,停止继续支付,可以输出为第一虚拟账户充值虚拟货币的对话框,以便用户通过该对话框为第一虚拟账户进行充值,从而使得该虚拟支付能够顺利完成。
进一步的,还包括:申请实体账户;在申请通过后在实体账户的基础上,注册多个虚拟账户,多个虚拟账户分别属于不同的账户,不同的账户的虚拟账户分别于实体账户关联。
在实体账户及虚拟账户的关联关系上,可以为:首先申请实体账户,之后直接在该实体账户内注册多个分属于不同用户账户的虚拟账户,从而实现分属于不同用户账户的虚拟账户与同一个实体账户之间的关联;
还可以为:首先注册虚拟账户,之后申请实体账户,在虚拟账户与实体账户均存在之后,再建立虚拟账户与实体账户之间的关联关系,以使得多个分属于不同用户账户的虚拟账户可以作为同一个实体账户的子账户;
或者,在注册虚拟账户的同时,申请实体账户,之后再建立虚拟账户与实体账户之间的关联关系,以使得多个分属于不同用户账户的虚拟账户可以作为同一个实体账户的子账户。
本方案可以基于虚拟支付装置完成,具体的,该虚拟支付装置的结构示意图如图4所示,包括:虚拟账户管理组件41,航空公司销售组件42及支付执行组件43。
其中,虚拟账户管理组件,用于管理虚拟账户信息,包括:航空公司、用户等账户的主体信息,账户下虚拟货币余额信息以及虚拟货币交易明细信息,管理实体账户信息,支持向银行注册实体账户,并绑定相关交易实体,如:航空公司或用户等的虚拟账户。
航空公司销售组件,用于接收用户的机票预订信息,处理后解析机票预订信息中的支付方式,并将虚拟支付方式下的支付信息发送至支付执行组件,支付请求信息中包括航空公司的虚拟账户信息、用户的虚拟账户信息即订单消费金额等。
支付执行组件,用于对用户在航空公司B2B站点发起的交易中支付虚拟货币行为的业务处理,首先获取发出机票预订信息的用户账户在虚拟账户管理组件中的虚拟货币的余额,再根据机票预订信息判断该交易是否成立,若成立则执行虚拟支付流程,并将结果反馈至用户的终端。
本实施例公开的虚拟支付方法,获取机票预订信息,依据机票预订信息确定发出机票预订信息的账户,以及,确定针对机票预订信息的支付方式为虚拟支付,确定账户的虚拟账户,设定账户的虚拟账户为第一虚拟账户,第一虚拟账户与实体账户关联,获取第一虚拟账户的虚拟支付密码,进行虚拟支付,依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币,在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟账户,设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户,第二虚拟账户与实体账户关联。本申请中,第一虚拟账户与实体账户关联,第二虚拟账户与实体账户关联,即不同账户的虚拟账户均与实体账户关联,在通过虚拟支付进行机票预订信息的支付时,实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换,在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化,但是与多个不同虚拟账户关联的实体账户的总金额不变,即实体账户中的实际货币金额未发生变化,那么,就不会受到央行施行办法的限制,不采用第三方交易平台,直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付,在同一个账户下进行不同虚拟账户间的余额交换,没有每日或每年的交易限额。
本实施例公开了一种虚拟支付***,其结构示意图如图5所示,包括:
预订信息获取单元51,第一确定单元52,虚拟账户确定单元53,密码获取单元54,扣除单元55及增加单元56。
其中,预订信息获取单元51用于获取机票预订信息;
第一确定单元52用于依据机票预订信息确定发出机票预订信息的账户,以及,确定针对机票预订信息的支付方式为虚拟支付;
虚拟账户确定单元53用于确定账户的虚拟账户,设定账户的虚拟账户为第一虚拟账户,第一虚拟账户与实体账户关联;
密码获取单元54用于获取第一虚拟账户的虚拟支付密码,进行虚拟支付;
扣除单元55用于依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币;
增加单元56用于在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟货币,其中,设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户,第二虚拟账户与实体账户关联。
用户登录航空公司的网站的账户,之后在该网站上确定机票预订信息,以使得虚拟支付***可以接收到用户确定的机票预订信息,其中,机票预订信息中包括预订的机票的相关信息,消费金额,预订该机票预订信息的账户,预订该机票预订信息的时间等。
虚拟支付***在确定发出机票预订信息的账户后,还需要确定针对机票预订信息的支付方式,虚拟支付***发出支付方式询问的信息,即虚拟支付***向用户的账户发出询问信息,询问用户的账户采用哪一种支付方式进行虚拟支付。
其中,支付方式主要包括:网上银行支付、第三方支付平台支付以及虚拟支付。
用户通过账户反馈支付方式,若用户反馈的支付方式为虚拟支付,则虚拟支付***可以确定支付方式为虚拟支付。
在确定用户的账户之后,还需要进一步确定该用户的账户对应的虚拟账户,通常每一个账户下会有一个虚拟账户,但是并不排除一个账户对应多个虚拟账户。
为了方便表述,将账户的虚拟账户设定为第一虚拟账户,第一虚拟账户是与实体账户相关联的。
其中,实体账户是真实的银行账户,如:中国银行的6228 8888 8888 8888,如:中国农业银行的6228 4888 8888 8888 888。
而虚拟账户是实体账户中的虚拟账户,是在实体账户中划分出来的,虚拟账户在银行层面会有一个后缀子账户的划分,即虚拟账户是实体账户中的子账户,如:实体账户为:某银行的账号1234567890,第一虚拟账户可以为1234567890-0001,第二虚拟账户可以为1234567890-0002等。
实体账户中可以包括多个虚拟账户,即包括多个子账户,而每个虚拟账户可以分别属于不同的用户账户,如:第一虚拟账户属于第一用户账户,第二虚拟账户属于第二用户账户,第N虚拟账户属于航空公司名下的账户等。
由于一个实体账户中包括多个虚拟账户,每个虚拟账户中通常均会有一定的虚拟货币金额。具体的,可以为:用户账户若要实现虚拟交易,就需要首先在实体账户下注册一个虚拟账户,在注册虚拟账户后,可通过移动终端或者线下方式为该虚拟账户充值,使虚拟账户中有虚拟货币,在为虚拟账户充值后,实体账户中也会增加同样的充值金额;或者,在需要进行虚拟支付时,通过移动终端或者线下方式为该虚拟账户充值,以使该虚拟账户中有虚拟货币,能够进行虚拟支付。
例如:为第一虚拟账户充值1000元,由于第一虚拟账户是与实体账户相关联的,那么,与第一虚拟账户相关联的实体账户中也会被充值1000元。
由于一个实体账户下有多个虚拟账户,而每个虚拟账户分属于不同的用户账户,在为第一虚拟账户充值时,对其他虚拟账户没有任何影响,而实体账户的金额也会增加充值的金额;在为其他虚拟账户充值时,对第一虚拟账户也没有任何影响,而同时实体账户的金额也会增加充值的金额。
本实施例中的实体账户可以为:一个航空公司名下的实体账户,而与该实体账户关联的虚拟账户,则分别是与该航空公司有过交易的用户账户的虚拟账户,或者是将要与该航空公司有交易的用户的虚拟账户,一个实体账户下的多个虚拟账户可分属于不同的用户账户,当然,与实体账户有关联的多个虚拟账户中必然至少包括一个属于该航空公司名下的虚拟账户,用于与该实体账户下的其他用户账户的虚拟账户进行虚拟货币交易。
进一步的,若采用除虚拟支付外的其他支付方式时,如:选择第三方支付平台支付,如:支付宝支付,则不采用本实施例所公开的方案,而是继续沿用原有的支付方式,只是会存在支付限额的问题,同时也会存在第三方支付平台通过收取的手续差价赚取手续费的问题。
在确定采用虚拟支付的方式进行支付时,虚拟支付***会向用户账户所在端发送一个界面,该界面为输入支付密码的界面,以便用户输入支付密码,在用户输入支付密码后,虚拟支付***获取到该支付密码,对该支付密码进行有效性验证,如果有效,则继续执行后续步骤,进行虚拟支付,如果无效,则发送支付密码错误的提示窗口至用户账户端。
在确定支付密码有效后,继续进行虚拟支付,虚拟支付过程中,将该用户账户对应的虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币,同时,在机票预订信息所在航空公司的虚拟账户中增加该消费金额等额的虚拟货币。
即首先确定机票预订信息中的消费金额,之后确定机票预订信息所在航空公司的虚拟账户,即第二虚拟账户,将第一虚拟账户中与消费金额等额的虚拟货币转移至第二虚拟账户中,其具体表现即为第一虚拟账户中被扣除了与消费金额等额的虚拟货币,而第二虚拟账户中增加了与消费金额等额的虚拟货币,即完成了虚拟支付。
在上述虚拟支付的过程中,无论是第一虚拟账户还是第二虚拟账户,均与同一个实体账户相关联,属于该实体账户的子账户,在虚拟货币从第一个子账户转移至第二个子账户的过程中,该实体账户的总金额并未发生变化,因此,在银行的真实账户金额并未发生变化,只是该真实账户中的一部分金额从一个子账户转移至另一个子账户,这属于真实账户内部的账户管理,并非是将真实账户中的金额增加或减少,因此,真实账户中的子账户之间虚拟货币的转移并不受到银行限额的限制。
如图2所示,图2为银行的实体账户,实体账户的账号为1234567890,与该实体账户相关联的虚拟账户包括:用户A的虚拟账户1234567890-0001,用户B的虚拟账户1234567890-0002,第一航空公司的虚拟账户1234567890-0011,第二航空公司的虚拟账户1234567890-0012,上述4个虚拟账户均与该实体账户相关联,属于该实体账户的子账户。
当用户A购买第一航空公司航班时,用户A将与该航班对应的消费金额从用户A的虚拟账户转移至第一航空公司的虚拟账户;当用户B购买第一航空公司航班时,用户B将与该航班对应的消费金额从用户B的虚拟账户转移至第一航空公司的虚拟账户;当然,用户A及用户B也可以购买第二航空公司的航班,在此只是举例说明,并不对哪一个用户购买哪一个公司的产品进行限定。
从图2中可以看出,无论是用户A购买第一航空公司的产品,还是用户B购买第二航空公司的产品,其均是在实体账户1234567890内部进行的交易,实体账户1234567890的总金额并不会变化。
本方案通过采用实体账户内部的子账户进行交易,避免采用第三方支付平台,即变了央行规定的限额的问题;其次,采用内部子账户之间的交易,无需交易手续费,节省了开支费用;另外,本方案在进行虚拟支付时,无需连接银行网关,只是航空公司B2B网站与虚拟支付***之间的交互,请求处理更高效,提高了用户体验。
进一步的,第一确定单元52用于依据机票预订信息确定发出机票预订信息的账户;对账户的有效性进行验证,若验证通过,则确定针对机票预订信息的支付方式为虚拟支付。
在用户通过账户发出机票预订信息,并由虚拟支付***接收到该机票预订信息后,确定发出该机票预订信息的账户,之后,由虚拟支付***对账户的有效性进行验证。
对账户的有效性进行验证,可具体为:验证账户中的相关信息是否过期,或者,验证该账户发出的机票预订信息是否有效,或者,验证该账户对应的虚拟账户中是否有虚拟货币,或者,验证该账户对应的虚拟账户中的虚拟货币是否足够支付机票预订信息的消费金额。
无论对账户的有效性进行验证是验证的哪一方面的有效性,都是为了使机票预订信息能够被顺利支付,以及用户可正常进行其预订的行程。
另外,对虚拟账户中的虚拟货币余额进行查询的步骤,可以在对账户的有效性进行验证的时候进行,也可以单独进行,即:本实施例公开的虚拟支付***还包括:查询单元,用于对所述第一虚拟账户的虚拟货币余额进行查询,以确定所述第一虚拟账户的虚拟货币余额的值。
每一个用户的账户均可以对与其对应的虚拟账户中虚拟货币的余额的值进行查询,但是并不能对其他用户的账户中虚拟货币的余额的值进行查询,以保证用户的账户中信息的安全性。
其查询时机可以为:在用户登录账户后,进行其他操作之前,直接通过虚拟支付***对虚拟账户的虚拟货币余额进行查询;另外,也可以为:在进行机票预订时,在用户在账户中输入机票预订信息,但是将机票预订信息发送至虚拟支付***之前,通过虚拟支付***对虚拟账户的虚拟货币余额进行查询。
另外,还可以为:虚拟支付***确定机票预订信息中的消费金额的值,若第一虚拟账户的虚拟货币余额的值大于机票预订信息中的消费金额的值,则将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币。
即在进行虚拟支付时,首先确定第一虚拟账户中的虚拟货币余额,只有当第一虚拟账户中虚拟货币余额的值大于机票预订信息中的消费金额的值时,才会继续进行支付,而在第一虚拟账户中虚拟货币余额的值小于机票预订信息中的消费金额的值时,是不能完成支付的,因此,此时,停止继续支付,可以输出为第一虚拟账户充值虚拟货币的对话框,以便用户通过该对话框为第一虚拟账户进行充值,从而使得该虚拟支付能够顺利完成。
本实施例公开的虚拟支付***还包括:申请单元,用于申请实体账户;在申请通过后的实体账户的基础上,注册多个虚拟账户,多个虚拟账户分别属于不同的账户,不同的账户的虚拟账户分别与实体账户关联。
在实体账户及虚拟账户的关联关系上,可以为:首先申请实体账户,之后直接在该实体账户内注册多个分属于不同用户账户的虚拟账户,从而实现分属于不同用户账户的虚拟账户与同一个实体账户之间的关联;
还可以为:首先注册虚拟账户,之后申请实体账户,在虚拟账户与实体账户均存在之后,再建立虚拟账户与实体账户之间的关联关系,以使得多个分属于不同用户账户的虚拟账户可以作为同一个实体账户的子账户;
或者,在注册虚拟账户的同时,申请实体账户,之后再建立虚拟账户与实体账户之间的关联关系,以使得多个分属于不同用户账户的虚拟账户可以作为同一个实体账户的子账户。
本方案可以基于虚拟支付装置完成,具体的,该虚拟支付装置的结构示意图如图4所示,包括:虚拟账户管理组件41,航空公司销售组件42及支付执行组件43。
其中,虚拟账户管理组件,用于管理虚拟账户信息,包括:航空公司、用户等账户的主体信息,账户下虚拟货币余额信息以及虚拟货币交易明细信息,管理实体账户信息,支持向银行注册实体账户,并绑定相关交易实体,如:航空公司或用户等的虚拟账户。
航空公司销售组件,用于接收用户的机票预订信息,处理后解析机票预订信息中的支付方式,并将虚拟支付方式下的支付信息发送至支付执行组件,支付请求信息中包括航空公司的虚拟账户信息、用户的虚拟账户信息即订单消费金额等。
支付执行组件,用于对用户在航空公司B2B站点发起的交易中支付虚拟货币行为的业务处理,首先获取发出机票预订信息的用户账户在虚拟账户管理组件中的虚拟货币的余额,再根据机票预订信息判断该交易是否成立,若成立则执行虚拟支付流程,并将结果反馈至用户的终端。
本实施例公开的虚拟支付***,获取机票预订信息,依据机票预订信息确定发出机票预订信息的账户,以及,确定针对机票预订信息的支付方式为虚拟支付,确定账户的虚拟账户,设定账户的虚拟账户为第一虚拟账户,第一虚拟账户与实体账户关联,获取第一虚拟账户的虚拟支付密码,进行虚拟支付,依据虚拟支付将第一虚拟账户中的虚拟货币余额扣除与机票预订信息中的消费金额等额的虚拟货币,在机票预订信息所在航空公司的虚拟账户中增加与机票预订信息中的消费金额等额的虚拟账户,设定机票预订信息所在航空公司的虚拟账户为第二虚拟账户,第二虚拟账户与实体账户关联。本申请中,第一虚拟账户与实体账户关联,第二虚拟账户与实体账户关联,即不同账户的虚拟账户均与实体账户关联,在通过虚拟支付进行机票预订信息的支付时,实际是在与同一个实体账户相关联的不同虚拟账户之间的虚拟货币的交换,在这一过程中相互交换虚拟货币的虚拟账户中余额发生变化,但是与多个不同虚拟账户关联的实体账户的总金额不变,即实体账户中的实际货币金额未发生变化,那么,就不会受到央行施行办法的限制,不采用第三方交易平台,直接通过自身平台内部的一个实体账户下的多个虚拟账户实现消费金额的支付,在同一个账户下进行不同虚拟账户间的余额交换,没有每日或每年的交易限额。
本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言,由于其与实施例公开的方法相对应,所以描述的比较简单,相关之处参见方法部分说明即可。
专业人员还可以进一步意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、计算机软件或者二者的结合来实现,为了清楚地说明硬件和软件的可互换性,在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块,或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。
对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

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

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201911154491.4A CN110930138A (zh) 2019-11-22 2019-11-22 一种虚拟支付方法及***
PCT/CN2020/126074 WO2021098502A1 (zh) 2019-11-22 2020-11-03 一种虚拟支付方法及***
KR1020227007929A KR20220045016A (ko) 2019-11-22 2020-11-03 가상 결제 방법 및 시스템
US17/641,795 US20220374889A1 (en) 2019-11-22 2020-11-03 Virtual payment method and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911154491.4A CN110930138A (zh) 2019-11-22 2019-11-22 一种虚拟支付方法及***

Publications (1)

Publication Number Publication Date
CN110930138A true CN110930138A (zh) 2020-03-27

Family

ID=69851608

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911154491.4A Pending CN110930138A (zh) 2019-11-22 2019-11-22 一种虚拟支付方法及***

Country Status (4)

Country Link
US (1) US20220374889A1 (zh)
KR (1) KR20220045016A (zh)
CN (1) CN110930138A (zh)
WO (1) WO2021098502A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112579572A (zh) * 2020-12-18 2021-03-30 建信金融科技有限责任公司 一种关联账户维护方法、装置及电子设备
WO2021098502A1 (zh) * 2019-11-22 2021-05-27 中国民航信息网络股份有限公司 一种虚拟支付方法及***

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP1730750S (ja) * 2022-05-20 2022-11-28 コネクタ

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103971229A (zh) * 2014-03-11 2014-08-06 马云起 一种涉及虚拟货币的交易支付方法
CN108596589A (zh) * 2018-04-27 2018-09-28 张泽英 购买支付方法及装置
CN108830573A (zh) * 2018-06-22 2018-11-16 四川华翼共享区块链科技有限公司 用于民航服务支付的虚拟货币管理***
CN108960461A (zh) * 2018-06-22 2018-12-07 四川华翼共享区块链科技有限公司 一种基于虚拟货币的机票预定方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7716080B2 (en) * 1999-06-23 2010-05-11 Signature Systems, Llc Method and system for using multi-function cards for storing, managing and aggregating reward points
CN104584045A (zh) * 2012-08-21 2015-04-29 韩国信用生活株式会社 运用智能手机而不使用***刷卡单据的***交易方法
US9785940B2 (en) * 2014-03-27 2017-10-10 Bank of the Ozarks System and method for distributed real time authorization of payment transactions
US10664836B2 (en) * 2015-02-17 2020-05-26 Dave's Slingshot, LLC Payment system and method
CN108171501A (zh) * 2017-12-27 2018-06-15 青岛农村商业银行股份有限公司 一种市场支付结算管理***
US20190378224A1 (en) * 2018-06-11 2019-12-12 Walter Krych Blockchain-based distribution platform
CN109359965A (zh) * 2018-09-30 2019-02-19 中国银行股份有限公司 一种转账手续费支付方法及***
CN109615468A (zh) * 2018-12-03 2019-04-12 大汉电子商务有限公司 一种收支付管理***及方法
CN110930138A (zh) * 2019-11-22 2020-03-27 中国民航信息网络股份有限公司 一种虚拟支付方法及***

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103971229A (zh) * 2014-03-11 2014-08-06 马云起 一种涉及虚拟货币的交易支付方法
CN108596589A (zh) * 2018-04-27 2018-09-28 张泽英 购买支付方法及装置
CN108830573A (zh) * 2018-06-22 2018-11-16 四川华翼共享区块链科技有限公司 用于民航服务支付的虚拟货币管理***
CN108960461A (zh) * 2018-06-22 2018-12-07 四川华翼共享区块链科技有限公司 一种基于虚拟货币的机票预定方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021098502A1 (zh) * 2019-11-22 2021-05-27 中国民航信息网络股份有限公司 一种虚拟支付方法及***
CN112579572A (zh) * 2020-12-18 2021-03-30 建信金融科技有限责任公司 一种关联账户维护方法、装置及电子设备

Also Published As

Publication number Publication date
WO2021098502A1 (zh) 2021-05-27
US20220374889A1 (en) 2022-11-24
KR20220045016A (ko) 2022-04-12

Similar Documents

Publication Publication Date Title
US20220327590A1 (en) Secure execution of an exchange item acquisition request
KR101662579B1 (ko) 시스템 내 가입자에게 크레딧을 제공하는 방법 및 시스템
JP5882122B2 (ja) カード支払情報通知システム、カード支払情報通知方法及びカード支払情報通知プログラム
US8452683B2 (en) System and method for making a synthetic cash advance using a purchase payment exchange
US20140201067A1 (en) System and method for facilitating a transaction
US20150058109A1 (en) Systems and methods for financial data communications and data management
US20120215659A1 (en) Systems and Methods Relating to Bank Transactions, Prepaid Access, Payment Based Promotions, and Payment Networks
WO2021098502A1 (zh) 一种虚拟支付方法及***
WO2009108251A1 (en) System and method for making a synthetic cash advance using a purchase payment exchange
US20230206245A1 (en) Systems and methods for blocking credit card charges
US20190188659A1 (en) System to allocate payroll funds to prepaid instruments
KR102181925B1 (ko) 유저 배당 기반의 쇼핑몰 운영 시스템
KR20200055439A (ko) 셀러론 서비스 시스템 및 방법
KR100853907B1 (ko) 개인별 카드 포인트를 통합 관리하여 사용자의 결제 대금을할인해 주는 신용카드 결제 시스템 및 그 신용카드 결제방법
JP3863523B2 (ja) 料金割引システム
KR101026466B1 (ko) 적립카드 적립포인트 환급 시스템 및 방법
KR102197232B1 (ko) 급여 선사용 결제 방법
WO2018016658A1 (en) System and method of administering insurance scheme
KR101963751B1 (ko) 그룹 결제 서비스 제공 방법 및 시스템
KR102066341B1 (ko) 전자화폐의 신용 유통 시스템 및 그 방법
CN115082243A (zh) 基金快速赎回方法、装置、电子设备及存储介质
KR20090078413A (ko) 포인트를 이용한 대출 처리 정보를 저장하는 정보 저장매체
US20160203449A1 (en) Multiple Merchant Credit System and Method
KR20120098977A (ko) 국가별 금융사 식별 번호의 매핑을 이용하는 국제 선불 카드의 결제 시스템 및 국제 선불 카드의 결제 방법
KR20050042875A (ko) 신용거래에서 사용자의 포인트를 가맹점의 수수료 할인에이용함으로써 신용거래를 활성화시키는 방법과 이에 관한프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200327