CN104700267B - 一种基于银行虚拟***的移动支付***和方法 - Google Patents

一种基于银行虚拟***的移动支付***和方法 Download PDF

Info

Publication number
CN104700267B
CN104700267B CN201510130816.0A CN201510130816A CN104700267B CN 104700267 B CN104700267 B CN 104700267B CN 201510130816 A CN201510130816 A CN 201510130816A CN 104700267 B CN104700267 B CN 104700267B
Authority
CN
China
Prior art keywords
bank
server
payment
card number
virtual
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.)
Active
Application number
CN201510130816.0A
Other languages
English (en)
Other versions
CN104700267A (zh
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.)
The Shanghai Mdt InfoTech Ltd
Original Assignee
Shanghai Mdt Infotech 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 Shanghai Mdt Infotech Ltd filed Critical Shanghai Mdt Infotech Ltd
Priority to CN201510130816.0A priority Critical patent/CN104700267B/zh
Publication of CN104700267A publication Critical patent/CN104700267A/zh
Application granted granted Critical
Publication of CN104700267B publication Critical patent/CN104700267B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3221—Access to banking information through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本发明涉及一种基于银行虚拟***的移动支付***和方法，***包括支付设备、发卡行服务器、第三方支付服务器、POS、收单行服务器、卡组织服务器、商户服务器和BVA SP服务器，支付设备生成用于作为支付请求或圈存请求的主账号的银行虚拟***，支付请求通过POS、收单行服务器、卡组织服务器的中转传输或者圈存请求通过BVA SP服务器发送给发卡行服务器，发卡行服务器完成支付或圈存，当支付设备使用第三方支付账号进行支付或圈存时，则发卡行服务器通过BVA SP服务器与第三方支付服务器通信，在验证支付请求或圈存请求后完成支付或圈存。与现有技术相比，本发明具有提高移动支付安全性、兼容性强、方便用户操作等优点。

Description

一种基于银行虚拟***的移动支付***和方法
技术领域
本发明涉及一种移动支付的***和方法，尤其是涉及一种基于银行虚拟***的移动支付***和方法。
背景技术
现有的移动支付方法从支付场景来说分为支付设备不在支付现场的远程支付和支付设备在支付现场的近程支付，用户当前使用较多的远程支付主要有支付宝、银联及其他第三方支付公司提供的账号余额支付或银行***支付等支付方式，近程支付主要有传统的销售终端(Point Of Sale，POS)磁条、接触式IC、非接触式闪付(Quick Pass)、支付宝的扫码付及声波付等支付方式。
相较已经发展较为稳定的远程支付，目前近程支付发展非常迅速，尤其是2014年9月苹果发布的Apple Pay功能，仅发布了2个多月用户数就突破了300万。而在中国，银联的非接触式闪付占据了近程支付领域的绝对领先地位，经改造支持闪付的POS已经超过了360万台。Apple Pay和闪付均属于近场通信(Near Field Communication，NFC)技术，又称近距离无线通信，是一种短距离的高频无线通信技术，允许电子设备之间进行非接触式点对点数据传输交换数据。这个技术由免接触式射频识别(Radio Frequency Identification，RFID)演变而来，由飞利浦半导体(现恩智浦半导体)、诺基亚和索尼共同研制开发，其基础是RFID及互连技术。与我们目前使用较多的蓝牙技术相比，NFC使用更加方便，成本更低，能耗更低，建立连接的速度也更快，只需0.1秒钟，因此在手机、门禁、一卡通、银行卡领域也逐渐被广泛应用。
但随着黑客及钓鱼网站的盛行，现有的远程支付和近程支付均存在较大的安全隐患，特别是银行***及第三方支付账号的泄露，会给用户资金带来极大的安全风险。
而且无论是新兴的NFC还是传统的磁条及IC均只支持自有标准的用户识别标识，如中国境内的POS只支持符合银联要求的16-19位银行***，无法兼容非银行体系的第三方支付账号，从而造成第三方支付账号可使用范围非常狭小，无法在近程支付领域普及使用。
发明内容
本发明的目的就是为了解决移动支付的安全性和兼容性问题，而提供一种基于银行虚拟***的移动支付***和方法，可兼容非银行体系第三方支付账号进行高安全性的移动支付操作。
本发明的目的可以通过以下技术方案来实现：
一种基于银行虚拟***的移动支付***，包括支付设备、发卡行服务器、第三方支付服务器、POS、收单行服务器、卡组织服务器、商户服务器和BVA SP(Bank VirtualAccount Service Provider，银行虚拟账号服务提供商)服务器，所述支付设备分别连接POS、发卡行服务器、商户服务器和BVA SP服务器，所述POS连接收单行服务器，所述收单行服务器连接卡组织服务器，所述卡组织服务器连接发卡行服务器，所述发卡行服务器连接BVA SP服务器，所述BVA SP服务器分别连接第三方支付服务器和商户服务器；
支付设备直接接受POS近程发起的支付请求(近程表示支付设备在支付现场)，或者经BVA SP服务器接受商户服务器远程发起的支付请求(远程表示支付设备不在支付现场)，或者直接远程向BVA SP服务器发起的圈存请求，支付设备生成用于作为支付请求或圈存请求的主账号(Primary Account Number，PAN)的银行虚拟***，支付请求通过POS、收单行服务器、卡组织服务器的中转传输或者圈存请求通过BVA SP服务器的中转传输发送给发卡行服务器，发卡行服务器处理后反馈至支付设备，完成支付或圈存；
当支付设备使用第三方支付账号进行支付或圈存时，发卡行服务器通过BVA SP服务器的中转传输与第三方支付服务器通信，在验证支付请求或圈存请求后反馈至支付设备，完成支付或圈存。
所述支付设备为支持移动支付的电子终端设备，包括以下功能模块：
用于控制各个模块和计算密钥的CPU；
用于与POS交换支付数据的近程支付模块，所述近程支付模块包括但不限于NFC模块、磁条模块、接触式IC模块及蓝牙模块；
用于存储密钥数据的嵌入式安全元件；
用于与发卡行服务器、BVA SP服务器、商户服务器通信的通信模块。
所述发卡行服务器包括以下功能模块：
用于控制各个模块和计算密钥的CPU；
用于存储密钥数据的密钥数据库；
用于存储支付数据的支付数据库；
用于与支付设备、卡组织服务器、BVA SP服务器通信的通信模块；
所述第三方支付服务器包括以下功能模块：
用于控制各个模块的CPU；
用于存储支付数据的支付数据库；
用于与BVA SP服务器通信的通信模块；
所述商户服务器包括以下功能模块：
用于控制各个模块的CPU；
用于存储支付数据的支付数据库；
用于与支付设备、BVA SP服务器通信的通信模块；
所述BVA SP服务器、POS、收单行服务器和卡组织服务器均包括以下功能模块：
用于控制各个模块的CPU；
用于存储中转数据的中转数据库；
用于建立通信网络的通信模块；
所述POS还包括用于与支付设备通信的近程支付模块。
一种根据上述的***实现基于银行虚拟***的移动支付方法，包括以下步骤：
步骤S1：支付设备绑定至少一张银行真实***，并通过该银行柜面人工存储或在线下载存储的方式获得基于该银行真实***的密钥，同时根据第三方支付服务器的认证绑定流程继续绑定其他第三方支付账号，在绑定完成时，按顺序生成绑定***或账号的序号，序号标识该绑定***或账号；
步骤S2：支付设备直接接受POS近程发起的支付请求，或者经BVA SP服务器接受商户服务器远程发起的支付请求，或者直接远程向BVA SP服务器发起的圈存请求，支付设备对银行真实***进行加密，随机生成本次支付或圈存的银行虚拟***，并通过近程支付方式或远程支付方式向发卡行服务器发送将该银行虚拟***作为主账号的支付请求或圈存请求，其中，近程支付方式包括近程在线支付方式和近程离线支付方式，远程支付方式包括远程在线支付方式和远程圈存电子现金支付方式；
步骤S3：发卡行服务器接受支付请求或圈存请求，对银行虚拟***进行解密后获得银行真实***，判断本次支付或圈存是否使用该发卡行服务器的银行真实***，若否，执行步骤S4，若是，发卡行服务器生成支付或圈存请求验证结果，执行步骤S5；
步骤S4：发卡行服务器通过BVA SP服务器将支付请求转发给相应的第三方支付服务器，第三方支付服务器生成支付或圈存请求验证结果，并经BVA SP服务器转发给发卡行服务器；
步骤S5：发卡行服务器将支付或圈存请求验证结果反馈至支付设备，完成本次支付或圈存。
所述近程在线支付方式包括以下步骤：
101：POS发起支付请求，支付设备生成本次支付的银行虚拟***，通过近程通信方式以该银行虚拟***作为主账号来响应POS发起的支付请求，近程通信方式包括但不限于NFC通信方式、磁条通信方式、接触式IC通信方式及蓝牙通信方式；
102：POS通过网络专线将支付请求转发给收单行服务器；
103：收单行服务器通过网络专线将支付请求转发给卡组织服务器；
104：卡组织服务器根据银行虚拟***中的BIN将支付请求转发给相应的发卡行服务器，发卡行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***及序号，判断本次支付是否使用该发卡行服务器的银行真实***，若否，执行步骤105，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤109；
105：发卡行服务器将支付请求、与该银行真实***绑定的用户标识及序号转发给BVA SP服务器；
106：BVA SP服务器根据用户标识及序号将支付请求转发给相应的第三方支付服务器；
107：第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器；
108：BVA SP服务器将支付请求验证结果反馈至发卡行服务器；
109：发卡行服务器将支付请求验证结果反馈至卡组织服务器；
110：卡组织服务器将支付请求验证结果反馈至收单行服务器；
111：收单行服务器将支付请求验证结果反馈至POS；
112：POS本地完成支付请求验证，并将支付请求验证结果反馈至支付设备，完成本次支付。
所述近程离线支付方式包括以下步骤：
201：POS发起支付请求，支付设备生成本次支付的银行虚拟***，并通过近程通信方式以该银行虚拟***作为主账号来响应POS发起的支付请求，近程通信方式包括但不限于NFC通信方式、磁条通信方式、接触式IC通信方式及蓝牙通信方式；
202：POS本地完成支付请求验证，并将支付请求验证结果反馈至支付设备，完成本次支付；
203：POS通过网络专线异步将离线时间段内的所有支付请求批量转发给收单行服务器；
204：收单行服务器通过专线异步将批量的支付请求转发给卡组织服务器；
205：卡组织服务器根据银行虚拟***中的BIN将支付请求转发给相应的发卡行服务器，发卡行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***及序号，判断本次支付是否使用该发卡行服务器的银行真实***，若否，执行步骤206，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤210；
206：发卡行服务器将支付请求、与该银行真实***绑定的用户标识及序号转发给BVA SP服务器；
207：BVA SP服务器根据用户标识及序号将支付请求转发给相应第三方支付服务器；
208：第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器；
209：BVA SP服务器将支付请求验证结果反馈至发卡行服务器；
210：发卡行服务器将支付请求验证结果反馈至卡组织服务器；
211：卡组织服务器将支付请求验证结果反馈至收单行服务器；
212：收单行服务器将支付请求验证结果反馈至POS。
所述远程圈存电子现金支付方式包括以下步骤：
301：支付设备生成本次支付的银行虚拟***，并通过无线通信方式以该银行虚拟***作为主账号来向BVA SP服务器发起圈存请求；
302：BVA SP服务器根据银行虚拟***中的BIN将圈存请求转发给相应的发卡行，发卡行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***及序号，判断本次支付是否使用该发卡行服务器的银行真实***，若否，执行步骤303，若是，则发卡行服务器对圈存请求进行有效性验证，并执行步骤307；
303：发卡行服务器将与该银行真实***绑定的用户标识及序号转发给BVA SP服务器；
304：BVA SP服务器根据用户标识及序号将圈存请求转发给相应的第三方支付服务器；
305：第三方支付服务器对圈存请求进行有效性验证，并将圈存请求验证结果反馈至BVA SP服务器；
306：BVA SP服务器将圈存请求验证结果反馈至发卡行服务器；
307：发卡行服务器将圈存请求验证结果反馈给支付设备，完成本次圈存。
所述远程在线支付方式包括以下步骤：
401：用户在商户服务器的支付平台向BVA SP服务器发起支付请求；
402：BVP SP服务器通过无线通信方式发送至支付设备；
403：支付设备生成本次支付的银行虚拟***，并通过无线通信方式以该银行虚拟***作为主账号来向BVA SP服务器响应由商户服务器发起的支付请求；
404：BVA SP服务器根据银行虚拟***中的BIN将支付请求转发给相应发卡行服务器，发卡行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***及序号，判断本次支付是否使用该发卡行服务器的银行真实***，若否，执行步骤405，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤409；
405：发卡行服务器将与该银行真实***绑定的用户标识及序号转发给BVA SP服务器；
406：BVA SP服务器根据用户标识及序号将支付请求转发给相应的第三方支付服务器；
407：第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器；
408：BVA SP服务器将支付请求验证结果反馈至发卡行服务器；
409：发卡行服务器将支付请求验证结果反馈给商户服务器；
410：商户服务器将支付请求验证结果反馈给支付设备，完成本次支付。
所述银行虚拟***是在绑定的银行真实***的基础上加密生成，银行真实***的位数Q1和银行虚拟***的位数Q2符合卡组织规定的位数集Q，即Q1,Q2∈Q，Q∈{16,17,18,19}。
所述银行真实***的内容包括BIN、识别码、固定值、客户流水号及校验码，其中：
所述BIN字段包括n1位数字，记为B，n1＝6；
所述识别码字段包括n2位数字，记为S，若BIN字段用于识别是否为银行虚拟***，n2＝0，即***中不显示识别码字段，否则，n2＝1，识别码用于识别是否为银行虚拟***；
所述固定值字段包括n3位数字，记为G，n3∈{0,1,...,4}，由发卡行设定，可用于识别发卡的分行及支行，也可用于识别银行卡支持的币种及其他自定义识别功能，若n3＝0，即***中不显示固定值字段；
所述客户流水号字段包括n4位数字，记为L，n4∈{4,5,...,12}，用于识别客户身份，当发卡行设定***中有固定值字段时，与固定值字段对应；
所述校验码字段为按卡组织标准由该位之前的(n1+n2+n3+n4)位数字通过Luhn算法计算得出的1位数字，记为J，则Q1＝n1+n2+n3+n4+1，银行真实***即为B+S+G+L+J；
所述银行虚拟***的内容包括BIN、识别码、固定值、加密客户流水号及校验码，其中：
所述BIN字段包括n1位数字，记为B；
所述识别码字段包括n2位数字，记为S，若BIN字段用于识别是否为银行虚拟***，n2＝0，即***中不显示识别码字段，否则，n2＝1，识别码用于识别是否为银行虚拟***；
所述固定值字段包括n3位数字，记为G，n3∈{0,1,...,4}，由发卡行设定，可用于识别发卡的分行及支行，也可用于识别银行卡支持的币种及其他自定义识别功能，在银行虚拟***中按发卡行设定进行舍去或保留，若舍去，则在银行虚拟***中不显示固定值字段，在解密银行虚拟***时根据客户流水号还原固定值；
所述加密客户流水号字段包括n5位数字，记为L'，n5∈{5,6,...,12}，且n5＞n4；
所述校验码字段为按卡组织标准由该位之前的(n1+n2+n3+n5)或(n1+n2+n5)位数字通过Luhn算法计算得出的1位数字，记为J'，则Q2＝n1+n2+n3+n5+1或Q2＝n1+n2+n5+1，银行虚拟***即为B+S+G+L'+J'或B+S+L'+J'，银行虚拟***的B、S、G字段与银行真实***的B、S、G字段相同，因为固定值字段在加密为银行虚拟***时可能会按发卡行设定舍去，所以银行虚拟***存在上述两种情况；
所述支付设备和发卡行服务器均设有用于加密、解密的密钥，包括支付密钥T1和鉴权密钥T2，T1为所有用户一致的密钥，用于将银行真实***加密为银行虚拟***，T2为每个用户唯一使用的密钥，作为定期通过在线下载的方式更新T1时的身份鉴权密钥；
所述支付设备加密银行真实***的步骤包括：
A：每次支付或圈存，支付设备获得此次所使用的X的值，X的值为用于标明此次所用的银行真实***或第三方支付账号在支付设备中绑定的1-2位序号，0<X<99，再将L及X顺序排列，并由T1加密生成L'
B：根据发卡行设定进行舍去或保留G，再通过Luhn算法计算后获得J'，将B+S+G+L'+J'或B+S+L'+J'进行组合，获得用于此次支付的银行虚拟***，完成加密；
所述发卡行服务器解密银行虚拟***的步骤包括：
a：发卡行服务器接收到银行虚拟***后，先通过Luhn算法校验J'是否合法，若是，则执行步骤b，若否，则反馈支付请求失败信息；
b：用T1解密L'，从而获得L及X；
c：通过Luhn算法将B+S+G+L计算后获得J，若G在加密时按发卡行设定被舍去，则根据L获得相对应的G，再将B+S+G+L+J组合，获得用于此次支付的银行真实***，完成解密。
与现有技术相比，本发明具有以下优点：
1)通过使用密钥加密方式在每次交易均生成一个随机的银行虚拟***，从而避免了银行***及第三方支付账号泄露的风险，大幅提高了移动支付的安全性。银行虚拟***在加密过程中，使用T1对客户流水号及此次支付交易所使用的银行账号或第三方账号的序号进行随机加密，从而实现生成不重复的银行虚拟***。
2)通过为第三方支付账号的近程支付请求生成符合卡组织规范的银行虚拟***，从而使得第三方支付账号可以通过POS的磁条、接触式IC及闪付功能来进行移动支付。在不改造POS的前提下，极大提高了POS与非银行体系第三方支付账号的兼容性。
3)通过对第三方支付账号远程圈存请求的支持，使得用户的第三方支付账号可以在离线状态下进行各类快捷支付，提高了用户的体验并增加了第三方支付账号的支付场景。
4)通过一个支付设备可绑定多张银行卡及多个第三方支付账号，解决了用户需随身携带多张银行卡及多个支付设备的问题，提高了用户的便捷性。
5)在移动支付环节加入银行虚拟账号服务提供商服务器，针对支付或圈存未使用该发卡行服务器的银行真实***的情况，建立了第三方支付公司与发卡行服务器之间通信，可传递将该银行虚拟***作为主账号的支付请求或圈存请求，实现了线下支付场景中第三方支付的功能。
附图说明
图1为本发明***的结构框图；
图2为本发明方法的流程图；
图3为本实施例中近程在线支付方式的示意图；
图4为本实施例中近程离线支付方式的示意图；
图5为本实施例中远程圈存电子现金支付方式的示意图；
图6为本实施例中远程在线支付方式的示意图。
图中：1、支付设备，2、发卡行服务器，3、第三方支付服务器，4、POS，5、收单行服务器，6、卡组织服务器，7、商户服务器，8、BVA SP服务器，9、近程支付模块，10、嵌入式安全元件，11、通信模块，12、中转数据库，13、密钥数据库，14、支付数据库，15、CPU。
具体实施方式
下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。
实施例一
如图1所示，一种基于银行虚拟***的移动支付***包括支付设备1、发卡行服务器2、第三方支付服务器3、POS4、收单行服务器5、卡组织服务器6、商户服务器7和BVA SP服务器8，支付设备1分别连接POS4、发卡行服务器2、商户服务器7和BVA SP服务器8，POS4连接收单行服务器5，收单行服务器5连接卡组织服务器6，卡组织服务器6连接发卡行服务器2，发卡行服务器2连接BVA SP服务器8，BVA SP服务器8分别连接第三方支付服务器3和商户服务器7。其中，支付设备1包括但不限于多用途卡、手机、平板电脑、智能手表及智能手环等可随身携带、支持移动支付的电子终端设备；发卡行服务器2包括工商银行、建设银行及交通银行等商业银行的服务器；第三方支付服务器3包括非发卡行的商业银行及支付宝、杉德卡等具有相关支付牌照的第三方支付公司的服务器；收单行服务器5包括工商银行、建设银行等商业银行及易宝、汇付天下等具有收单资质的第三方支付公司的服务器；卡组织服务器6包括***、VISA及MASTER等清算组织的服务器；商户服务器7包括淘宝、携程及美团等有移动支付需求的商户的服务器。
支付设备1在支付现场直接接受POS4通过近程通信方式(包括但不限于NFC通信方式、磁条通信方式、接触式IC通信方式及蓝牙通信方式)发起的支付请求，或者经BVA SP服务器8接受商户服务器7远程发起的支付请求，或者直接远程向BVA SP服务器8发起圈存请求，支付设备1生成用于作为支付请求或圈存请求的主账号的银行虚拟***，支付请求通过POS4、收单行服务器5、卡组织服务器6的中转传输或者圈存请求通过BVA SP服务器8的中转传输发送给发卡行服务器2，发卡行服务器2处理后反馈至支付设备1，完成支付或圈存；
当支付设备1使用第三方支付账号(包括非发卡行的其他银行真实***及非银行体系第三方支付公司的支付账号)进行支付或圈存时，则发卡行服务器2通过BVA SP服务器8的中转传输与第三方支付服务器3通信，在验证支付请求或圈存请求后反馈至支付设备1，完成支付或圈存。
支付设备1可以为手机、平板、智能手表及智能手环等支持移动支付的终端设备，作为移动支付***中的用户环节，主要包括以下模块：
用于控制各个模块和计算密钥的CPU15；
用于与POS4交换支付数据的近程支付模块9，近程支付模块9包括但不限于NFC模块、磁条模块、接触式IC模块及蓝牙模块；
用于存储密钥数据的嵌入式安全元件(Embedded Secure Equipment，eSE)10；
用于与发卡行服务器2、BVA SP服务器8、商户服务器7通信的通信模块11。
发卡行服务器2作为移动支付***中的加解密及支付(圈存)请求验证环节，包括：
用于控制各个模块和计算密钥的CPU15；
用于存储密钥数据的密钥数据库13；
用于存储支付数据的支付数据库14；
用于与支付设备1、卡组织服务器6、BVA SP服务器8通信的通信模块11；
第三方支付服务器3作为支付(圈存)请求验证环节，包括：
用于控制各个模块的CPU15；
用于存储支付数据的支付数据库14；
用于通过网络专线与BVA SP服务器8通信的通信模块11。
商户服务器7包括以下功能模块：
用于控制各个模块的CPU15；
用于存储支付数据的支付数据库14；
用于与支付设备1、BVA SP服务器8通信的通信模块11。
BVA SP服务器8、POS4、收单行服务器5和卡组织服务器6作为移动支付***中的中转环节，均包括：
用于控制各个模块的CPU15；
用于存储中转数据的中转数据库12；
用于建立网络专线通信的通信模块11。
POS4还包括用于与支付设备1通信的近程支付模块9。
以NFC手机(即支付设备1)、招商银行服务器(即发卡行服务器2)、支付宝服务器(即第三方支付服务器3)、POS4、工商银行服务器(即收单行服务器5)、银联服务器(即卡组织服务器6)、淘宝服务器(即商户服务器7)和BVA SP服务器8构成的移动支付***为例，如图2所示，在本实施例***中实现基于银行虚拟***的移动支付方法包括以下步骤：
步骤S1：NFC手机绑定招商银行真实***，并通过该银行柜面人工存储或在线下载存储的方式获得基于该银行真实***的密钥，同时根据支付宝服务器的认证绑定流程绑定支付宝账号，在绑定完成时，按顺序生成绑定***或账号的序号，用以标识该绑定***或账号；
步骤S2：NFC手机直接接受POS4通过近程通信方式(近程通信方式包括但不限于NFC通信方式、磁条通信方式、接触式IC通信方式及蓝牙通信方式，此处NFC手机采用NFC通信方式)发起的支付请求，或者经BVA SP服务器8接受淘宝服务器远程发起的支付请求，或者直接远程向BVA SP服务器8发起圈存请求，NFC手机对银行真实***进行加密，随机生成本次支付或圈存的银行虚拟***，并通过近程支付方式或远程支付方式向招商银行服务器发送将该银行虚拟***作为主账号的支付请求或圈存请求，其中，近程支付方式包括近程在线支付方式和近程离线支付方式，远程支付方式包括远程圈存电子现金支付方式和远程在线支付方式；
步骤S3：招商银行服务器接受支付请求或圈存请求，对银行虚拟***进行解密后获得银行真实***，判断本次支付或圈存是否使用该招商银行服务器的银行真实***，若否，执行步骤S4，若是，招商银行服务器生成支付或圈存请求验证结果，执行步骤S5；
步骤S4：招商银行服务器通过BVA SP服务器8将支付或圈存请求转发给相应的支付宝服务器，支付宝服务器生成支付或圈存请求验证结果，并经BVA SP服务器8转发给招商银行服务器；
步骤S5：招商银行服务器将支付或圈存请求验证结果反馈至NFC手机，完成本次支付或圈存。
其中，银行虚拟***是在绑定的银行真实***的基础上加密生成，银行真实***的位数Q1和银行虚拟***的位数Q2符合卡组织规定的位数集Q，即Q1,Q2∈Q，Q∈{16,17,18,19}。
银行真实***的内容包括BIN、识别码、固定值、客户流水号及校验码，其中：
BIN字段包括n1位数字，记为B，n1＝6；
识别码字段包括n2位数字，记为S，若BIN字段用于识别是否为银行虚拟***，n2＝0，即***中不显示识别码字段，否则，n2＝1，识别码用于识别是否为银行虚拟***；
固定值字段包括n3位数字，记为G，n3∈{0,1,...,4}，由发卡行设定，可用于识别发卡的分行及支行，也可用于识别银行卡支持的币种及其他自定义识别功能，若n3＝0，即***中不显示固定值字段；
客户流水号字段包括n4位数字，记为L，n4∈{4,5,...,12}，用于识别客户身份，当发卡行设定***中有固定值字段时，与固定值字段对应；
校验码字段为按卡组织标准由该位之前的(n1+n2+n3+n4)位数字通过Luhn算法计算得出的1位数字，记为J，则Q1＝n1+n2+n3+n4+1，银行真实***即为B+S+G+L+J；
银行虚拟***的内容包括BIN、识别码、固定值、加密客户流水号及校验码，其中：
BIN字段包括n1位数字，记为B；
识别码字段包括n2位数字，记为S，若BIN字段用于识别是否为银行虚拟***，n2＝0，否则，n2＝1，识别码用于识别是否为银行虚拟***；
固定值字段包括n3位数字，记为G，n3∈{0,1,...,4}，由发卡行设定，可用于识别发卡的分行及支行，也可用于识别银行卡支持的币种及其他自定义识别功能，在银行虚拟***中按发卡行设定进行舍去或保留，若舍去，则在银行虚拟***中不显示固定值字段，在解密银行虚拟***时根据客户流水号还原固定值；
加密客户流水号字段包括n5位数字，记为L'，n5∈{5,6,...,12}，且n5＞n4；
校验码字段为按卡组织标准由该位之前的(n1+n2+n3+n5)或(n1+n2+n5)位数字通过Luhn算法计算得出的1位数字，记为J'，则Q2＝n1+n2+n3+n5+1或Q2＝n1+n2+n5+1，银行虚拟***即为B+S+G+L'+J'或B+S+L'+J'，银行虚拟***的B、S、G字段与银行真实***的B、S、G字段相同，因为固定值字段在加密为银行虚拟***时可能会按发卡行设定舍去，所以银行虚拟***存在上述两种情况；
支付设备1和发卡行服务器2均设有用于加密、解密的密钥，包括支付密钥T1和鉴权密钥T2，T1为所有用户一致的密钥，用于将银行真实***加密为银行虚拟***，T2为每个用户唯一使用的密钥，作为定期通过在线下载的方式更新T1时的身份鉴权密钥；
实施例一中，招商银行16位真实***为6225 8801 1234 5675，其中：
622588为BIN字段，记为B；
0为识别码字段，记为S；
11为固定值字段，记为G；
234567为客户流水号字段，记为L；
5为校验码字段，记为J。
NFC手机加密的步骤包括：
A：NFC手机获得此次所使用的X(X＝01)，再将L及X顺序排列，并由T1加密生成加密客户流水号43211234，即L'；
B：通过Luhn算法将B+S+G+L'，(即622588+0+11+43211234)计算后获得J'(J'＝8)，再将B+S+G+L'+J'组合，获得用于此次支付的18位招商银行虚拟***6222 6001 1432 112348，完成加密。
招商银行服务器解密的步骤包括：
a：招商银行服务器接收到招商银行虚拟***后，先通过Luhn算法校验J'是否合法，若是，则执行步骤b，若否，则反馈支付请求失败信息；
b：用T1解密L'，从而获得L及X；
c：通过Luhn算法将B+S+G+L计算后获得J，再将B+S+G+L+J组合，获得用于此次支付的16位招商银行真实***6225 8801 1234 5675，完成解密。
下面对四种支付方式进行具体的说明：
当用户使用NFC手机通过近程通信方式在商户POS4处进行支付时，若电子现金余额不足或该商户强制要求联网在线验证支付合法性时，则须使用在线验证的方式(即POS4需联网认证)进行符合银联规范的移动支付。如图3所示，近程在线支付方式包括以下步骤(图3中的虚线表示在账号发行方为第三方支付公司时才需要执行的步骤)：
101：POS4发起支付请求，NFC手机生成本次支付的银行虚拟***，通过近程通信方式以该银行虚拟***作为主账号来响应POS4发起的支付请求，其中需要变更传输给POS4的主账号及第2、3磁道中的主账号信息，支付请求内包括主账号、卡有效期、卡片序列号、第2磁道数据及第3磁道数据等数据信息；
102：POS4通过网络专线将支付请求转发给工商银行服务器；
103：工商银行服务器通过网络专线将支付请求转发给银联服务器；
104：银联服务器根据银行虚拟***中的BIN(卡组织分配给发卡行的6位数字BIN字段，用于识别不同的发卡行)将支付请求转发给相应的招商银行服务器，发卡行根据识别码(发卡行在6位BIN后自行定义的1位数字识别码字段，用于识别该账号使用银行虚拟***支付方式)判断当前***为银行虚拟***后，对其进行解密，获得银行真实***及序号，判断本次支付是否使用招商银行服务器的银行真实***，若否，执行步骤105，若是，则招商银行服务器对支付请求进行有效性验证，并执行步骤109；
105：招商银行服务器将支付请求、与该银行真实***绑定的用户标识(用户标识指NFC手机的移动设备国际识别码，International Mobile Equipment Identity，IMEI)及序号转发给BVA SP服务器8；
106：BVA SP服务器8根据用户标识及序号将支付请求转发给相应的支付宝服务器；
107：支付宝服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器8；
108：BVA SP服务器8将支付请求验证结果反馈至招商银行服务器；
109：招商银行服务器将支付请求验证结果反馈至银联服务器；
110：银联服务器将支付请求验证结果反馈至工商银行服务器；
111：工商银行服务器将支付请求验证结果反馈至POS4；
112：POS4本地完成支付请求验证，并将支付请求验证结果反馈至NFC手机，完成本次支付。
当用户使用NFC手机通过近程通信方式在商户POS4处进行支付时，若电子现金余额足够且该商户不强制要求联网在线验证支付合法性时，则可使用离线验证的方式(即POS4无需联网认证)进行符合卡组织规范的移动支付。如图4所示，近程离线支付方式包括以下步骤(图4中虚线代表在账号发行方为第三方支付公司时才需要执行的步骤，点线代表异步执行的步骤)：
201：POS4发起支付请求，NFC手机生成本次支付的银行虚拟***，并通过近程通信方式以该银行虚拟***作为主账号来响应POS4发起的支付请求，即变更传输给POS4的主账号及第2、3磁道中的主账号信息；
202：POS4本地完成支付请求验证，并将支付请求验证结果反馈至NFC手机，完成本次支付；
203：POS4通过网络专线异步将离线时间段内的所有支付请求批量转发给工商银行服务器；
204：工商银行服务器通过专线异步将批量的支付请求转发给银联服务器；
205：银联服务器根据银行虚拟***中的BIN将支付请求转发给相应的招商银行服务器，招商银行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***，判断本次支付是否使用招商银行服务器的银行真实***，若否，执行步骤206，若是，则招商银行服务器对支付请求进行有效性验证，并执行步骤210；
206：招商银行服务器将支付请求、与该银行真实***绑定的用户标识及序号转发给BVA SP服务器8；
207：BVA SP服务器8根据用户标识及序号将支付请求转发给相应支付宝服务器；
208：支付宝服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器8；
209：BVA SP服务器8将支付请求验证结果反馈至招商银行服务器；
210：招商银行服务器将支付请求验证结果反馈至银联服务器；
211：银联服务器将支付请求验证结果反馈至工商银行服务器；
212：工商银行服务器将支付请求验证结果反馈至POS4。
当用户使用远程支付方式在NFC手机中对某个已绑定的账号进行电子现金圈存时，则须通过BVA SP直联发卡行来完成电子现金圈存，若圈存账号为第三方支付公司，则还须联接第三方支付公司。如图5所示，远程圈存电子现金支付方式包括以下步骤(图5中虚线含义同图3)：
301：NFC手机生成本次支付的银行虚拟***，并通过无线通信方式以该银行虚拟***作为主账号来向BVA SP服务器8发起圈存请求；
302：BVA SP服务器8根据银行虚拟***中的BIN将圈存请求转发给相应的发卡行，招商银行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***，判断本次支付是否使用招商银行服务器的银行真实***，若否，执行步骤303，若是，则招商银行服务器对圈存请求进行有效性验证，并执行步骤307；
303：招商银行服务器将与该银行真实***绑定的用户标识及序号转发给BVA SP服务器8；
304：BVA SP服务器8根据用户标识及序号将圈存请求转发给相应的支付宝服务器；
305：支付宝服务器对圈存请求进行有效性验证，并将圈存请求验证结果反馈至BVA SP服务器8；
306：BVA SP服务器8将圈存请求验证结果反馈至招商银行服务器；
307：招商银行服务器将圈存请求验证结果反馈给NFC手机，完成本次圈存。
当用户使用远程支付方式在NFC手机中进行在线支付时，则须通过BVA SP直联发卡行来完成在线支付，若所使用的账号为第三方支付公司，则还须联接第三方支付公司。如图6所示，远程在线支付方式包括以下步骤(图6中虚线含义同图3)：
401：用户在淘宝服务器的支付平台向BVA SP服务器8发起支付请求；
402：BVP SP服务器8通过无线通信方式发送至NFC手机；
403：NFC手机生成本次支付的银行虚拟***，并通过无线通信方式以该银行虚拟***作为主账号来向BVA SP服务器8响应由淘宝服务器发起的支付请求；
404：BVA SP服务器8根据银行虚拟***中的BIN将支付请求转发给相应招商银行服务器，招商银行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***，判断本次支付是否使用招商银行服务器的银行真实***，若否，执行步骤405，若是，则招商银行服务器对支付请求进行有效性验证，并执行步骤409；
405：招商银行服务器将与该银行真实***绑定的用户标识及序号转发给BVA SP服务器8；
406：BVA SP服务器8根据用户标识及序号将支付请求转发给相应的支付宝服务器；
407：支付宝服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器8；
408：BVA SP服务器8将支付请求验证结果反馈至招商银行服务器；
409：招商银行服务器将支付请求验证结果反馈给淘宝服务器；
410：淘宝服务器将支付请求验证结果反馈给NFC手机，完成本次支付。
综上，本发明的核心要素是通过在移动支付环节中引入BVA SP的角色，作用包括：
1)用户所持有的支付设备1或用户远程操作的商户服务器7的支付平台分别与BVASP服务器8通过通讯模块无线联网的模式进行通讯，来完成绑定、查询及支付等请求的提交及中转工作。
2)BVA SP服务器8与发卡行服务器2通过通讯模块专线联网的模式进行通讯，来完成绑定、查询及支付等请求的中转及反馈工作。
3)BVA SP服务器8与第三方支付服务器3通过通讯模块专线联网的模式进行通讯，来完成绑定、查询及支付等请求的中转及反馈工作。
当用户进行移动支付时，在其已绑定于支付设备1上的银行真实***的基础上，使用T1对客户流水号及此次支付交易所使用的银行账号或第三方账号的序号进行随机加密，生成符合卡组织要求的银行虚拟***，在支付流程的传输过程中采用银行虚拟***进行传输，克服了直接使用银行真实***进行传输存在的不安全隐患，即使银行虚拟***在传输过程中被获取，但是没有支付密钥T1，仍然无法获取含有用户真实信息的银行真实***，大幅提高了移动支付的安全性与兼容性。
实施例二
本实施例与实施例一的区别在于，交通银行服务器作为发卡行服务器2，其中，银行真实***与银行虚拟***的加解密过程为：
交通银行19位真实***为6222 6001 1234 5678 909，其中：
622260为BIN字段，记为B；
0为识别码字段，记为S；
11为固定值字段，记为G；
234567890为客户流水号字段，记为L；
9为校验码字段，记为J。
支付设备1加密步骤包括：
A：支付设备1获得此次所使用的X(02)，再将L及X顺序排列，并由T1加密生成加密客户流水号0987654321，即L'；
B：按交通银行设定加密时舍去G(G字段仍然存在，只是不在银行虚拟***中显示)，通过Luhn算法将B+S+L'(即622260+0+09876543210)计算后获得J'(J'＝1)，再将B+S+L'+J'组合，获得用于此次支付的19位交通银行虚拟***6222 6000 9876 5432 101，完成加密。
交通银行服务器解密的步骤包括：
a：交通银行服务器接收到交通银行虚拟***后，先通过Luhn算法校验J'是否合法，若是，则执行步骤b，若否，则反馈支付请求失败信息；
b：用T1解密L'，从而获得L及X；
c：根据L获得相对应的G，并通过Luhn算法将B+S+G+L计算后获得J，再将B+S+G+L+J组合，获得用于此次支付的19位的交通银行真实***6222 6001 1234 5678 909，完成解密。
交通银行服务器作为发卡行服务器2的四种支付方式与实施例一相同。
实施例三
本实施例与实施例一的区别在于，广发银行服务器作为发卡行服务器2，其中，银行真实***与银行虚拟***的加解密过程为：
广发银行19位真实***为6225 6812 2212 3456 785，其中：
622568为BIN字段，记为B，广发银行设定此BIN为支持银行虚拟***，因此不需要识别码S；
1222为固定值字段，记为G；
12345678为客户流水号字段，记为L；
5为校验码字段，记为J。
支付设备1加密步骤包括：
A：支付设备1获得此次所使用的X(X＝03)，再将L及X顺序排列，并由T1加密生成加密客户流水号0987654321，即L'；
B：按广发银行设定加密时舍去G，通过Luhn算法将B+L'，(即622568+0987654321)计算后获得J'(J'＝1)，再将B+L'+J'组合，获得用于此次支付的17位广发银行虚拟***6222 6009 8765 43211，完成加密。
广发银行服务器解密的步骤包括：
a：广发银行服务器接收到银行虚拟***后，先通过Luhn算法校验J'是否合法，若是，则执行步骤b，若否，则反馈支付请求失败信息；
b：用T1解密L'，从而获得L及X；
c：根据L获得相对应的G，并通过Luhn算法将B+S+G+L计算后获得J，再将B+S+G+L+J组合，获得用于此次支付的19位广发银行真实***6225 6812 2212 3456 785，完成解密。
广发银行服务器作为发卡行服务器2的四种支付方式的步骤中采用BIN来识别当前***是否为银行虚拟***，其他步骤与实施例一相同。

Claims (10)

1.一种基于银行虚拟***的移动支付***，其特征在于，包括支付设备、发卡行服务器、第三方支付服务器、POS、收单行服务器、卡组织服务器、商户服务器和银行虚拟账号服务提供商服务器，所述支付设备分别连接POS、发卡行服务器、商户服务器和银行虚拟账号服务提供商服务器，所述POS连接收单行服务器，所述收单行服务器连接卡组织服务器，所述卡组织服务器连接发卡行服务器，所述发卡行服务器连接银行虚拟账号服务提供商服务器，所述银行虚拟账号服务提供商服务器分别连接第三方支付服务器和商户服务器；
支付设备直接接受POS近程发起的支付请求，或者经银行虚拟账号服务提供商服务器接受商户服务器远程发起的支付请求，或者直接远程向银行虚拟账号服务提供商服务器发起的圈存请求，支付设备生成用于作为支付请求或圈存请求的主账号的银行虚拟***，支付请求通过POS、收单行服务器、卡组织服务器的中转传输或者圈存请求通过银行虚拟账号服务提供商服务器的中转传输发送给发卡行服务器，发卡行服务器处理后反馈至支付设备，完成支付或圈存；
当支付设备使用第三方支付账号进行支付或圈存时，发卡行服务器通过银行虚拟账号服务提供商服务器的中转传输与第三方支付服务器通信，在验证支付请求或圈存请求后反馈至支付设备，完成支付或圈存。
2.根据权利要求1所述的一种基于银行虚拟***的移动支付***，其特征在于，所述支付设备为支持移动支付的电子终端设备，包括以下功能模块：
用于控制各个模块和计算密钥的CPU；
用于与POS交换支付数据的近程支付模块，所述近程支付模块包括但不限于NFC模块、磁条模块、接触式IC模块及蓝牙模块；
用于存储密钥数据的嵌入式安全元件；
用于与发卡行服务器、银行虚拟账号服务提供商服务器、商户服务器通信的通信模块。
3.根据权利要求1所述的一种基于银行虚拟***的移动支付***，其特征在于，所述发卡行服务器包括以下功能模块：
用于控制各个模块和计算密钥的CPU；
用于存储密钥数据的密钥数据库；
用于存储支付数据的支付数据库；
用于与支付设备、卡组织服务器、银行虚拟账号服务提供商服务器通信的通信模块；
所述第三方支付服务器包括以下功能模块：
用于控制各个模块的CPU；
用于存储支付数据的支付数据库；
用于与银行虚拟账号服务提供商服务器通信的通信模块；
所述商户服务器包括以下功能模块：
用于控制各个模块的CPU；
用于存储支付数据的支付数据库；
用于与支付设备、银行虚拟账号服务提供商服务器通信的通信模块；
所述银行虚拟账号服务提供商服务器、POS、收单行服务器和卡组织服务器均包括以下功能模块：
用于控制各个模块的CPU；
用于存储中转数据的中转数据库；
用于建立通信网络的通信模块；
所述POS还包括用于与支付设备通信的近程支付模块。
4.一种根据权利要求1所述的***实现基于银行虚拟***的移动支付方法，其特征在于，包括以下步骤：
步骤S1：支付设备绑定至少一张银行真实***，并通过该银行柜面人工存储或在线下载存储的方式获得基于该银行真实***的密钥，同时根据第三方支付服务器的认证绑定流程继续绑定其他第三方支付账号，在绑定完成时，按顺序生成绑定***或账号的序号，序号标识该绑定***或账号；
步骤S2：支付设备直接接受POS近程发起的支付请求，或者经银行虚拟账号服务提供商服务器接受商户服务器远程发起的支付请求，或者直接远程向银行虚拟账号服务提供商服务器发起的圈存请求，支付设备对银行真实***进行加密，随机生成本次支付或圈存的银行虚拟***，并通过近程支付方式或远程支付方式向发卡行服务器发送将该银行虚拟***作为主账号的支付请求或圈存请求，其中，近程支付方式包括近程在线支付方式和近程离线支付方式，远程支付方式包括远程在线支付方式和远程圈存电子现金支付方式；
步骤S3：发卡行服务器接受支付请求或圈存请求，对银行虚拟***进行解密后获得银行真实***，判断本次支付或圈存是否使用该发卡行服务器的银行真实***，若否，执行步骤S4，若是，发卡行服务器生成支付或圈存请求验证结果，执行步骤S5；
步骤S4：发卡行服务器通过银行虚拟账号服务提供商服务器将支付请求转发给相应的第三方支付服务器，第三方支付服务器生成支付或圈存请求验证结果，并经银行虚拟账号服务提供商服务器转发给发卡行服务器；
步骤S5：发卡行服务器将支付或圈存请求验证结果反馈至支付设备，完成本次支付或圈存。
5.根据权利要求4所述的一种基于银行虚拟***的移动支付方法，其特征在于，所述近程在线支付方式包括以下步骤：
101：POS发起支付请求，支付设备生成本次支付的银行虚拟***，通过近程通信方式以该银行虚拟***作为主账号来响应POS发起的支付请求；
102：POS通过网络专线将支付请求转发给收单行服务器；
103：收单行服务器通过网络专线将支付请求转发给卡组织服务器；
104：卡组织服务器根据银行虚拟***中的BIN将支付请求转发给相应的发卡行服务器，发卡行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***及序号，判断本次支付是否使用该发卡行服务器的银行真实***，若否，执行步骤105，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤109；
105：发卡行服务器将支付请求、与该银行真实***绑定的用户标识及序号转发给银行虚拟账号服务提供商服务器；
106：银行虚拟账号服务提供商服务器根据用户标识及序号将支付请求转发给相应的第三方支付服务器；
107：第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至银行虚拟账号服务提供商服务器；
108：银行虚拟账号服务提供商服务器将支付请求验证结果反馈至发卡行服务器；
109：发卡行服务器将支付请求验证结果反馈至卡组织服务器；
110：卡组织服务器将支付请求验证结果反馈至收单行服务器；
111：收单行服务器将支付请求验证结果反馈至POS；
112：POS本地完成支付请求验证，并将支付请求验证结果反馈至支付设备，完成本次支付。
6.根据权利要求4所述的一种基于银行虚拟***的移动支付方法，其特征在于，所述近程离线支付方式包括以下步骤：
201：POS发起支付请求，支付设备生成本次支付的银行虚拟***，并通过近程通信方式以该银行虚拟***作为主账号来响应POS发起的支付请求；
202：POS本地完成支付请求验证，并将支付请求验证结果反馈至支付设备，完成本次支付；
203：POS通过网络专线异步将离线时间段内的所有支付请求批量转发给收单行服务器；
204：收单行服务器通过专线异步将批量的支付请求转发给卡组织服务器；
205：卡组织服务器根据银行虚拟***中的BIN将支付请求转发给相应的发卡行服务器，发卡行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***及序号，判断本次支付是否使用该发卡行服务器的银行真实***，若否，执行步骤206，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤210；
206：发卡行服务器将支付请求、与该银行真实***绑定的用户标识及序号转发给银行虚拟账号服务提供商服务器；
207：银行虚拟账号服务提供商服务器根据用户标识及序号将支付请求转发给相应第三方支付服务器；
208：第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至银行虚拟账号服务提供商服务器；
209：银行虚拟账号服务提供商服务器将支付请求验证结果反馈至发卡行服务器；
210：发卡行服务器将支付请求验证结果反馈至卡组织服务器；
211：卡组织服务器将支付请求验证结果反馈至收单行服务器；
212：收单行服务器将支付请求验证结果反馈至POS。
7.根据权利要求4所述的一种基于银行虚拟***的移动支付方法，其特征在于，所述远程圈存电子现金支付方式包括以下步骤：
301：支付设备生成本次支付的银行虚拟***，并通过无线通信方式以该银行虚拟***作为主账号来向银行虚拟账号服务提供商服务器发起圈存请求；
302：银行虚拟账号服务提供商服务器根据银行虚拟***中的BIN将圈存请求转发给相应的发卡行，发卡行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***及序号，判断本次支付是否使用该发卡行服务器的银行真实***，若否，执行步骤303，若是，则发卡行服务器对圈存请求进行有效性验证，并执行步骤307；
303：发卡行服务器将与该银行真实***绑定的用户标识及序号转发给银行虚拟账号服务提供商服务器；
304：银行虚拟账号服务提供商服务器根据用户标识及序号将圈存请求转发给相应的第三方支付服务器；
305：第三方支付服务器对圈存请求进行有效性验证，并将圈存请求验证结果反馈至银行虚拟账号服务提供商服务器；
306：银行虚拟账号服务提供商服务器将圈存请求验证结果反馈至发卡行服务器；
307：发卡行服务器将圈存请求验证结果反馈给支付设备，完成本次圈存。
8.根据权利要求4所述的一种基于银行虚拟***的移动支付方法，其特征在于，所述远程在线支付方式包括以下步骤：
401：用户在商户服务器的支付平台向银行虚拟账号服务提供商服务器发起支付请求；
402：银行虚拟账号服务提供商服务器通过无线通信方式发送至支付设备；
403：支付设备生成本次支付的银行虚拟***，并通过无线通信方式以该银行虚拟***作为主账号来向银行虚拟账号服务提供商服务器响应由商户服务器发起的支付请求；
404：银行虚拟账号服务提供商服务器根据银行虚拟***中的BIN将支付请求转发给相应发卡行服务器，发卡行服务器识别当前***为银行虚拟***后进行解密，获得银行真实***及序号，判断本次支付是否使用该发卡行服务器的银行真实***，若否，执行步骤405，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤409；
405：发卡行服务器将与该银行真实***绑定的用户标识及序号转发给银行虚拟账号服务提供商服务器；
406：银行虚拟账号服务提供商服务器根据用户标识及序号将支付请求转发给相应的第三方支付服务器；
407：第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至银行虚拟账号服务提供商服务器；
408：银行虚拟账号服务提供商服务器将支付请求验证结果反馈至发卡行服务器；
409：发卡行服务器将支付请求验证结果反馈给商户服务器；
410：商户服务器将支付请求验证结果反馈给支付设备，完成本次支付。
9.根据权利要求4所述的一种基于银行虚拟***的移动支付方法，其特征在于，所述银行虚拟***是在绑定的银行真实***的基础上加密生成，银行真实***的位数Q1和银行虚拟***的位数Q2符合卡组织规定的位数集Q，即Q1,Q2∈Q，Q∈{16,17,18,19}。
10.根据权利要求9所述的一种基于银行虚拟***的移动支付方法，其特征在于，所述银行真实***的内容包括BIN、识别码、固定值、客户流水号及校验码，其中：
所述BIN字段包括n1位数字，记为B，n1＝6；
所述识别码字段包括n2位数字，记为S，若BIN字段用于识别是否为银行虚拟***，n2＝0，否则，n2＝1，识别码用于识别是否为银行虚拟***；
所述固定值字段包括n3位数字，记为G，n3∈{0,1,...,4}，由发卡行设定；
所述客户流水号字段包括n4位数字，记为L，n4∈{4,5,...,12}，用于识别客户身份，当发卡行设定***中有固定值字段时，与固定值字段对应；
所述校验码字段为按卡组织标准由校验码字段所在位之前的(n1+n2+n3+n4)位数字通过Luhn算法计算得出的1位数字，记为J，则Q1＝n1+n2+n3+n4+1，银行真实***即为B+S+G+L+J；
所述银行虚拟***的内容包括BIN、识别码、固定值、加密客户流水号及校验码，其中：
所述BIN字段包括n1位数字，记为B；
所述识别码字段包括n2位数字，记为S，若BIN字段用于识别是否为银行虚拟***，n2＝0，否则，n2＝1，识别码用于识别是否为银行虚拟***；
所述固定值字段包括n3位数字，记为G，n3∈{0,1,...,4}，由发卡行设定，在银行虚拟***中按发卡行设定进行舍去或保留，若舍去，在解密银行虚拟***时根据客户流水号还原固定值；
所述加密客户流水号字段包括n5位数字，记为L'，n5∈{5,6,...,12}，且n5＞n4；
所述校验码字段为按卡组织标准由校验码字段所在位之前的(n1+n2+n3+n5)或(n1+n2+n5)位数字通过Luhn算法计算得出的1位数字，记为J'，则Q2＝n1+n2+n3+n5+1或Q2＝n1+n2+n5+1，银行虚拟***即为B+S+G+L'+J'或B+S+L'+J'；
所述支付设备和发卡行服务器均设有用于加密、解密的密钥，包括支付密钥T1和鉴权密钥T2，T1用于将银行真实***加密为银行虚拟***，T2作为定期通过在线下载的方式更新T1时的身份鉴权密钥；
所述支付设备加密银行真实***的步骤包括：
A：每次支付或圈存，支付设备获得此次所使用的X的值，X的值为用于标明此次所用的银行真实***或第三方支付账号在支付设备中绑定的1-2位序号，0<X<99，再将L及X顺序排列，并由T1加密生成L'
B：根据发卡行设定进行舍去或保留G，再通过Luhn算法计算后获得J'，将B+S+G+L'+J'或B+S+L'+J'进行组合，获得用于此次支付的银行虚拟***，完成加密；
所述发卡行服务器解密银行虚拟***的步骤包括：
a：发卡行服务器接收到银行虚拟***后，先通过Luhn算法校验J'是否合法，若是，则执行步骤b，若否，则反馈支付请求失败信息；
b：用T1解密L'，从而获得L及X；
c：通过Luhn算法将B+S+G+L计算后获得J，若G在加密时按发卡行设定被舍去，则根据L获得相对应的G，再将B+S+G+L+J组合，获得用于此次支付的银行真实***，完成解密。
CN201510130816.0A 2015-01-16 2015-03-24 一种基于银行虚拟***的移动支付***和方法 Active CN104700267B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201510130816.0A CN104700267B (zh) 2015-01-16 2015-03-24 一种基于银行虚拟***的移动支付***和方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201510022992.2A CN104504565A (zh) 2015-01-16 2015-01-16 一种基于银行虚拟***的移动支付***和方法
CN2015100229922 2015-01-16
CN201510130816.0A CN104700267B (zh) 2015-01-16 2015-03-24 一种基于银行虚拟***的移动支付***和方法

Publications (2)

Publication Number Publication Date
CN104700267A CN104700267A (zh) 2015-06-10
CN104700267B true CN104700267B (zh) 2018-02-16

Family

ID=52945959

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201510022992.2A Pending CN104504565A (zh) 2015-01-16 2015-01-16 一种基于银行虚拟***的移动支付***和方法
CN201510130816.0A Active CN104700267B (zh) 2015-01-16 2015-03-24 一种基于银行虚拟***的移动支付***和方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN201510022992.2A Pending CN104504565A (zh) 2015-01-16 2015-01-16 一种基于银行虚拟***的移动支付***和方法

Country Status (1)

Country Link
CN (2) CN104504565A (zh)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106157013B (zh) * 2015-04-13 2019-08-30 中国电信股份有限公司 支付终端、机具、服务器、***及支付处理方法
CN104951937B (zh) * 2015-04-27 2018-05-01 上海摩镶数据科技有限公司 一种移动设备之间的鉴权方法和鉴权***
US11301841B2 (en) * 2015-05-13 2022-04-12 Sony Corporation Method and system for authenticating a virtual currency instrument
CN104933563A (zh) * 2015-06-23 2015-09-23 上海卓易科技股份有限公司 一种支付银行卡的方法及装置
CN104992331A (zh) * 2015-07-17 2015-10-21 上海众人网络安全技术有限公司 一种移动终端虚拟线下支付***及支付方法
CN105931035A (zh) * 2015-08-18 2016-09-07 ***股份有限公司 一种支付标记生成方法及装置
CN105590202A (zh) * 2015-08-28 2016-05-18 ***股份有限公司 使用移动终端进行支付的方法和装置
CN107204957B (zh) 2016-03-16 2020-04-28 阿里巴巴集团控股有限公司 一种账号绑定和业务处理的方法及装置
CN107038560B (zh) * 2017-01-06 2020-09-08 阿里巴巴集团控股有限公司 一种支付业务执行的***、方法及装置
US20190236586A1 (en) * 2017-02-16 2019-08-01 Huawei Technologies Co., Ltd. Payment Processing Method and Apparatus
CN107016537A (zh) * 2017-04-12 2017-08-04 杭州纳戒科技有限公司 储值卡管理方法以及装置
CN107274168A (zh) * 2017-06-15 2017-10-20 中国银行股份有限公司 一种支付方法、***、新型pos机及支付核心***
CN108171504B (zh) * 2017-11-16 2021-12-31 深圳市微付充科技有限公司 一种聚合支付方法、移动设备及存储装置
CN109842605B (zh) * 2017-11-29 2020-07-07 华为技术有限公司 绑卡方法及终端
CN108416581A (zh) * 2018-03-20 2018-08-17 深圳市讯联智付网络有限公司 一种在线支付的方法、装置和***
CN108960818A (zh) * 2018-05-04 2018-12-07 ***股份有限公司 一种虚拟卡生成方法、用户终端以及令牌服务器
CN109034818B (zh) * 2018-06-19 2022-05-13 创新先进技术有限公司 生成支付标记、利用支付标记进行验证的方法及装置
CN110647363B (zh) * 2018-06-27 2020-12-25 北京三快在线科技有限公司 异常提示方法、装置、存储介质及电子设备
KR102005554B1 (ko) * 2018-08-09 2019-07-30 주식회사 센스톤 공카드를 이용한 금융거래제공방법 및 시스템
CN109598492B (zh) * 2018-10-15 2023-09-29 创新先进技术有限公司 一种支付方法、***、装置、终端及业务服务器
CN109544146B (zh) * 2018-11-30 2023-06-16 北京红枣科技有限公司 无卡交互***及模拟卡设备
CN111327567A (zh) * 2018-12-13 2020-06-23 北京果仁宝软件技术有限责任公司 共享用户信息的方法、装置和***
CN111967967B (zh) * 2020-08-18 2023-08-18 中国银行股份有限公司 基于区块链的跨行支付业务处理方法及装置
CN112232825B (zh) * 2020-09-02 2022-09-20 厦门鲜品链科技有限公司 强身份认证付款pos***
CN113313491A (zh) * 2021-06-22 2021-08-27 中国农业银行股份有限公司 虚拟***的生成方法及相关装置
CN113657887A (zh) * 2021-08-03 2021-11-16 ***股份有限公司 非卡账户支付方法、设备、***及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101414370A (zh) * 2008-12-15 2009-04-22 阿里巴巴集团控股有限公司 利用虚拟卡提高支付安全的支付方法、***及支付平台
CN103870957A (zh) * 2012-12-13 2014-06-18 陈文原 将虚拟账户余额运用于实体购物的交易***及其方法
CN103886458A (zh) * 2014-03-26 2014-06-25 陆文清 基于网络的银行卡或非银行类储值卡手机支付解决方法
CN104268745A (zh) * 2014-09-29 2015-01-07 余震辉 一种线上线下的安全支付方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101414370A (zh) * 2008-12-15 2009-04-22 阿里巴巴集团控股有限公司 利用虚拟卡提高支付安全的支付方法、***及支付平台
CN103870957A (zh) * 2012-12-13 2014-06-18 陈文原 将虚拟账户余额运用于实体购物的交易***及其方法
CN103886458A (zh) * 2014-03-26 2014-06-25 陆文清 基于网络的银行卡或非银行类储值卡手机支付解决方法
CN104268745A (zh) * 2014-09-29 2015-01-07 余震辉 一种线上线下的安全支付方法

Also Published As

Publication number Publication date
CN104504565A (zh) 2015-04-08
CN104700267A (zh) 2015-06-10

Similar Documents

Publication Publication Date Title
CN104700267B (zh) 一种基于银行虚拟***的移动支付***和方法
CN104050565B (zh) 基于pboc支付网络的智能支付***及其移动终端
CN104794613B (zh) 一种基于销售终端的移动设备鉴权方法
Husni et al. Efficient tag-to-tag near field communication (NFC) protocol for secure mobile payment
CN105096118A (zh) 一种电子货币转付***及方法
CN102521744A (zh) 网络支付方法及装置
CN104463576A (zh) 一种基于线上支付的nfc移动支付的通信方法
CN103577983A (zh) 一种脱机消费电子货币的圈存方法
CN104463575A (zh) 一种基于支付口令的nfc支付的通信方法
CN105931037A (zh) 一种电子现金圈存方法、装置及***
CN106462850A (zh) 支付凭证的安全传输
CN107636664A (zh) 用于向移动设备供应访问数据的方法和***
Dayang et al. Using USSD-based Mobile Payment in Context of Low Internet Connection
CN201307300Y (zh) 一种基于移动通信的付款***
Husni et al. Mobile Payment Protocol for Tag-to-Tag Near Field Communication (NFC).
KR20190083286A (ko) 음파장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
CN205334535U (zh) 一种集金融卡支付和结算于一体的装置
KR20190080647A (ko) 무선장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190080652A (ko) 무선장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190080650A (ko) 무선장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190080651A (ko) 무선장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190080656A (ko) 무선장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190080649A (ko) 무선장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190080653A (ko) 무선장치와 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법
KR20190082417A (ko) 음파신호를 송출하는 가맹점 무선단말과 암호화폐를 이용한 앱 연동 기반 비동기식 역방향 결제 방법

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
CB03 Change of inventor or designer information

Inventor after: Hu Wei

Inventor before: Xu Yining

Inventor before: Ou Rufeng

Inventor before: Hu Wei

CB03 Change of inventor or designer information
TA01 Transfer of patent application right

Effective date of registration: 20180110

Address after: 200001 new road, Zhabei District, Zhabei District, Shanghai, room 701-43

Applicant after: The Shanghai Mdt InfoTech Ltd

Address before: No. 1102-8, No. 912, Gonghe Road, Zhabei District, Shanghai

Applicant before: Shanghai Hao Kai Information technology company limited

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant