一种基于银行虚拟卡号的移动支付系统和方法
【专利摘要】本发明涉及一种基于银行虚拟卡号的移动支付系统，包括支付设备、发卡行服务器、第三方支付服务器、POS、收单行服务器、卡组织服务器、商户服务器和BVA SP服务器，支付设备生成用于作为支付请求或圈存请求的主账号的银行虚拟卡号，支付请求通过POS、收单行服务器、卡组织服务器的中转传输或者圈存请求通过BVA SP服务器的中转传输发送给发卡行服务器，发卡行服务器完成圈存或支付，当支付设备使用第三方支付账号进行支付时，则发卡行服务器通过BVA SP服务器的中转传输与第三方支付服务器通信，在验证支付请求或圈存请求后完成支付或圈存。与现有技术相比，本发明具有提高移动支付安全性、兼容性强、方便用户操作等优点。
【专利说明】一种基于银行虚拟卡号的移动支付系统和方法
【技术领域】
[0001]本发明涉及一种移动支付的系统和方法，尤其是涉及一种基于银行虚拟卡号的移动支付系统和方法。
【背景技术】
[0002]现有的移动支付方法从支付场景来说分为远程支付和近程支付，用户当前使用较多的远程支付主要有支付宝、银联及其他第三方支付公司提供的账号余额支付或银行卡号支付等支付方式，近程支付主要有银联的销售终端(Point Of Sale,P0S)接触式刷卡、非接触式闪付(Quick Pass)、支付宝的扫码付及声波付等支付方式。
[0003]相较已经发展较为稳定的远程支付，目前近场移动支付发展非常迅速，尤其是2014年9月苹果发布的Apple Pay功能，仅发布了 2个多月用户数就突破了 300万。而在中国，银联的非接触式闪付占据了近程支付领域的绝对领先地位，经改造支持闪付的POS已经超过了 360万台。Apple Pay和闪付均属于近场通信(Near Field Communicat1n,NFC)技术，又称近距离无线通信，是一种短距离的高频无线通信技术，允许电子设备之间进行非接触式点对点数据传输交换数据。这个技术由免接触式射频识别(Rad1 FrequencyIdentificat1n，RFID)演变而来，由飞利浦半导体(现恩智浦半导体)、诺基亚和索尼共同研制开发，其基础是RFID及互连技术。与我们目前使用较多的蓝牙技术相比，NFC使用更加方便，成本更低，能耗更低，建立连接的速度也更快，只需0.1秒钟，因此在手机、门禁、一卡通、银行卡领域也逐渐被广泛应用。
[0004]但随着黑客及钓鱼网站的盛行，现有的远程支付和近程支付均存在较大的安全隐患，特别是银行卡号及第三方支付账号的泄露，会给用户资金带来极大的安全风险。
[0005]而且无论是Apple Pay还是闪付均只支持自有标准的用户识别标识，如闪付只支持符合银联要求的16-19位银行卡号，无法兼容非银行体系的第三方支付账号，从而造成第三方支付账号可使用范围非常狭小，无法在近程支付领域普及使用。
【发明内容】
[0006]本发明的目的就是为了解决移动支付的安全性和兼容性问题，而提供一种基于银行虚拟卡号的移动支付系统和方法，可兼容非银行体系第三方支付账号进行高安全性的移动支付操作。
[0007]本发明的目的可以通过以下技术方案来实现:
[0008]一种基于银行虚拟卡号的移动支付系统，包括支付设备、发卡行服务器、第三方支付服务器、P0S、收单行服务器、卡组织服务器、商户服务器和BVA SP(Bank Virtual AccountService Provider，银行虚拟账号服务提供商)服务器，所述支付设备分别连接P0S、发卡行服务器、商户服务器和BVA SP服务器，所述POS连接收单行服务器，所述收单行服务器连接卡组织服务器，所述卡组织服务器连接发卡行服务器，所述发卡行服务器连接BVA SP服务器，所述BVA SP服务器分别连接第三方支付服务器和商户服务器；
[0009]支付设备直接接受POS近程发起的支付请求，或者经BVA SP服务器接受商户服务器远程发起的支付请求，或者直接远程向BVA SP服务器发起的圈存请求，支付设备生成用于作为支付请求或圈存请求的主账号(Primary Account Number,PAN)的银行虚拟卡号，支付请求通过P0S、收单行服务器、卡组织服务器的中转传输或者圈存请求通过BVA SP服务器的中转传输发送给发卡行服务器，发卡行服务器处理后反馈至支付设备，完成支付或圈存；
[0010]当支付设备使用第三方支付账号进行支付或圈存时，发卡行服务器通过BVA SP服务器的中转传输与第三方支付服务器通信，在验证支付请求或圈存请求后反馈至支付设备，完成支付或圈存。
[0011]所述支付设备包括:
[0012]用于控制其他模块和计算密钥的CPU;
[0013]用于与POS通信的NFC模块；
[0014]用于存储密钥数据的嵌入式安全元件；
[0015]用于与BVA SP服务器无线通信的无线通信模块。
[0016]所述发卡行服务器包括:
[0017]用于控制其他模块和计算密钥的CPU;
[0018]用于存储密钥数据的密钥数据库；
[0019]用于存储支付数据的支付数据库；
[0020]用于通过网络专线与BVA SP服务器及卡组织服务器通信的通信模块；
[0021 ] 所述第三方支付服务器包括:
[0022]用于控制其他模块的CPU ；
[0023]用于存储支付数据的支付数据库；
[0024]用于通过网络专线与BVA SP服务器通信的通信模块。
[0025]所述BVA SP服务器、P0S、收单行服务器、卡组织服务器和商户服务器均包括:
[0026]用于控制其他模块的CPU ；
[0027]用于存储中转数据的中转数据库；
[0028]用于建立网络专线通信的通信模块；
[0029]所述POS还包括用于与支付设备通信的NFC模块。
[0030]一种根据上述的系统实现基于银行虚拟卡号的移动支付方法，包括以下步骤:
[0031]步骤S1:支付设备绑定至少一张银行真实卡号，并通过该银行柜面人工存储或在线下载存储的方式获得基于该银行真实卡号的密钥，同时根据第三方支付服务器的认证绑定流程继续绑定其他第三方支付账号，在绑定完成时，按顺序生成绑定卡号或账号的序号，序号用于标识该绑定卡号或账号；
[0032]步骤S2:支付设备直接接受POS近程发起的支付请求，或者经BVA SP服务器接受商户服务器远程发起的支付请求，或者直接远程向BVA SP服务器发起的圈存请求，支付设备对银行真实卡号进行加密，随机生成本次支付或圈存的银行虚拟卡号，并通过近程支付方式或远程支付方式向发卡行服务器发送将该银行虚拟卡号作为主账号的支付请求或圈存请求，其中，近程支付方式包括近程在线支付方式和近程离线支付方式，远程支付方式包括远程在线支付方式和远程圈存电子现金支付方式；
[0033]步骤S3:发卡行服务器接受支付请求或圈存请求，对银行虚拟卡号进行解密后获得银行真实卡号，判断本次支付或圈存是否使用该发卡行服务器的银行真实卡号，若否，执行步骤S4，若是，发卡行服务器生成支付或圈存请求验证结果，执行步骤S5 ;
[0034]步骤S4:发卡行服务器通过BVA SP服务器将支付请求转发给相应的第三方支付服务器，第三方支付服务器生成支付或圈存请求验证结果，并经BVA SP服务器转发给发卡行服务器；
[0035]步骤S5:发卡行服务器将支付或圈存请求验证结果反馈至支付设备，完成本次支付或圈存。
[0036]所述近程在线支付方式包括以下步骤:
[0037]101:POS发起支付请求，支付设备生成本次支付的银行虚拟卡号，通过近程通信方式以该银行虚拟卡号作为主账号来响应POS发起的支付请求，近程通信方式包括但不限于 NFC ；
[0038]102:POS通过网络专线将支付请求转发给收单行服务器；
[0039]103:收单行服务器通过网络专线将支付请求转发给卡组织服务器；
[0040]104:卡组织服务器根据银行虚拟卡号中的BIN将支付请求转发给相应的发卡行服务器，发卡行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号及序号，判断本次支付是否使用该发卡行服务器的银行真实卡号，若否，执行步骤105，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤109 ;
[0041]105:发卡行服务器将支付请求、与该银行真实卡号绑定的用户标识及序号转发给BVA SP服务器；
[0042]106:BVA SP服务器根据用户标识及序号将支付请求转发给相应的第三方支付服务器；
[0043]107:第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器；
[0044]108:BVA SP服务器将支付请求验证结果反馈至发卡行服务器；
[0045]109:发卡行服务器将支付请求验证结果反馈至卡组织服务器；
[0046]110:卡组织服务器将支付请求验证结果反馈至收单行服务器；
[0047]111:收单行服务器将支付请求验证结果反馈至POS ;
[0048]112:POS将支付请求验证结果反馈至支付设备，完成本次支付。
[0049]所述近程离线支付方式包括以下步骤:
[0050]201:POS发起支付请求，支付设备生成本次支付的银行虚拟卡号，并通过近程通信方式以该银行虚拟卡号作为主账号来响应POS发起的支付请求，近程通信方式包括但不限于NFC ；
[0051]202:POS将支付请求验证结果反馈至支付设备，完成本次支付；
[0052]203:POS通过网络专线异步将离线时间段内的所有支付请求批量转发给收单行服务器；
[0053]204:收单行服务器通过专线异步将批量的支付请求转发给卡组织服务器；
[0054]205:卡组织服务器根据银行虚拟卡号中的BIN将支付请求转发给相应的发卡行服务器，发卡行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号及序号，判断本次支付是否使用该发卡行服务器的银行真实卡号，若否，执行步骤206，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤210 ;
[0055]206:发卡行服务器将支付请求、与该银行真实卡号绑定的用户标识及序号转发给BVA SP服务器；
[0056]207:BVA SP服务器根据用户标识及序号将支付请求转发给相应第三方支付服务器;
[0057]208:第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器；
[0058]209:BVA SP服务器将支付请求验证结果反馈至发卡行服务器；
[0059]210:发卡行服务器将支付请求验证结果反馈至卡组织服务器；
[0060]211:卡组织服务器将支付请求验证结果反馈至收单行服务器；
[0061]212:收单行服务器将支付请求验证结果反馈至POS。
[0062]所述远程圈存电子现金支付方式包括以下步骤:
[0063]301:支付设备生成本次支付的银行虚拟卡号，并通过无线通信方式以该银行虚拟卡号作为主账号来向BVA SP服务器发起圈存请求；
[0064]302:BVA SP服务器根据银行虚拟卡号中的BIN将圈存请求转发给相应的发卡行，发卡行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号及序号，判断本次支付是否使用该发卡行服务器的银行真实卡号，若否，执行步骤303，若是，则发卡行服务器对圈存请求进行有效性验证，并执行步骤307 ;
[0065]303:发卡行服务器将与该银行真实卡号绑定的用户标识及序号转发给BVA SP服务器；
[0066]304:BVA SP服务器根据用户标识及序号将圈存请求转发给相应的第三方支付服务器；
[0067]305:第三方支付服务器对圈存请求进行有效性验证，并将圈存请求验证结果反馈至BVA SP服务器；
[0068]306:BVA SP服务器将圈存请求验证结果反馈至发卡行服务器；
[0069]307:发卡行服务器将圈存请求验证结果反馈给支付设备，完成本次圈存。
[0070]所述远程在线支付方式包括以下步骤:
[0071]401:用户在商户服务器的支付平台向BVA SP服务器发起支付请求；
[0072]402:BVP SP服务器通过无线通信方式发送至支付设备；
[0073]403:支付设备生成本次支付的银行虚拟卡号，并通过无线通信方式以该银行虚拟卡号作为主账号来向BVA SP服务器响应由商户服务器发起的支付请求；
[0074]404:BVA SP服务器根据银行虚拟卡号中的BIN将支付请求转发给相应发卡行服务器，发卡行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号及序号，判断本次支付是否使用该发卡行服务器的银行真实卡号，若否，执行步骤405，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤409 ;
[0075]405:发卡行服务器将与该银行真实卡号绑定的用户标识及序号转发给BVA SP服务器；
[0076]406:BVA SP服务器根据用户标识及序号将支付请求转发给相应的第三方支付服务器；
[0077]407:第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器；
[0078]408:BVA SP服务器将支付请求验证结果反馈至发卡行服务器；
[0079]409:发卡行服务器将支付请求验证结果反馈给商户服务器；
[0080]410:商户服务器将支付请求验证结果反馈给支付设备，完成本次支付。
[0081]所述银行真实卡号为16 位，记为 A1A2A3A4A5A6A7A8A9AltlA11A12A13A14A15A16，其中:
[0082]A1A2A3A4A5A6为 6 位的 BIN 字段，记为 B ；
[0083]~为I位的识别码字段，记为S ;
[0084]么8为I位的固定值，记为G；
[0085]A9A10A11A12A13A14A15^ 7位的客户流水号字段，记为L ；
[0086]A16为按银联标准由该位之前的15位卡号通过Luhn算法计算得出I位的校验码字段，记为J ;
[0087]所述银行虚拟卡号为19 位，记为 C1C2C3C4C5C6C7C8C9CltlC11C12C13C14C15C16C17C18C19,其中:
[0088]C1C2C3C4C5C6为 6 位的 BIN 字段，记为 B ；
[0089](:7为I位的识别码字段，记为S ;
[0090]C8C9CltlC11C12C13C14C15C16C17C18S 11 位的加密客户流水号字段，记为 H ；
[0091]C19为I位的校验码字段，记为J’ ；
[0092]所述支付设备和发卡行服务器均设有用于加密、解密的密钥，密钥包括私钥1\和公钥T2，T1包含随机生成的不重复的n i个私钥密钥值P i，(Kn^lOOOOJ# II1个私钥密钥值P i进行顺序标号，获得私钥索引序号Z，公钥T2包含I个公钥密钥值P 2和由η 2个2位的公钥验证码Ρ3，0〈η2〈99，对η2个公钥验证码P 3进行顺序标号，获得公钥索引序号W ;
[0093]所述支付设备加密的步骤包括:
[0094]A:每次支付或圈存，支付设备生成本次所使用的R及X的值，R的值为2位数字随机数，0〈R〈99，X的值为用于标明本次所用的银行卡号或第三方支付账号在支付设备中绑定的2位的序号，0〈X〈99 ；
[0095]B:W取R相同数值，从T2中获取对应顺序为第W个的P 3，将P3、X顺序排列，得到4位的私钥索引序号Z ；
[0096]C:根据Z从T1中获取对应顺序为第Z个的P i，先判断该？1是否已标记为已使用，若是，则返回步骤A重新取R值，若否，则使用PJt L进行加密，获得7位的L’，同时将支付设备中本次所使用的P1标记为已使用；
[0097]D:根据己对W+X+L’进行加密，获得11位的加密客户流水号H ；
[0098]E:通过Luhn算法将B+S+H计算后获得J’，获得用于本次的19位的银行虚拟卡号，即B+S+H+J’，完成加密；
[0099]所述发卡行服务器解密的步骤包括:
[0100]a:发卡行服务器接收到银行虚拟卡号后，先通过Luhn算法校验J’是否合法，若是，则执行步骤b，若否，则反馈支付请求失败信息；
[0101]b:用P2解密H，从而获得W、X及L’ ；
[0102]c IT2中获取对应顺序为第W个的P3，将P3、X顺序排列，得到4位的私钥索引序号Z ；
[0103]d:根据Z从T1中获取对应顺序为第Z个的P i，并对P1的合法性进行验证，即判断P1否被标记为已使用，若否，则使用P 4 L’进行解密，获得7位数字L，同时标记该使用，若是，则反馈支付请求失败信息；
[0104]e:G为发卡行服务器自定义固定值，通过Luhn算法将B+S+G+L计算后获得J，获得用于本次的16位的银行真实卡号，即B+S+G+L+J，完成解密。
[0105]与现有技术相比，本发明具有以下优点:
[0106]I)通过使用非对称双重加密方式在每次交易均生成不重复的银行虚拟卡号，从而避免了银行卡号及第三方支付账号泄露的风险，大幅提高了移动支付的安全性。银行虚拟卡号在加密过程中，使用PJt L进行加密后将支付设备中本次支付所使用的P i标记为已使用，同时在解密过程中，对P1的合法性进行验证，若合法，解密后将发卡行服务器相应的P !标记为已使用，从而实现生成不重复的银行虚拟卡号。
[0107]2)通过为第三方支付账号的近程支付请求生成符合银联规范的银行虚拟卡号，从而使得第三方支付账号可以通过POS的闪付功能来进行移动支付。在不改造POS的前提下，极大提高了闪付与非银行体系第三方支付账号的兼容性。
[0108]3)通过对第三方支付账号远程圈存请求的支持，使得用户的第三方支付账号可以在离线状态下进行各类快捷支付，提高了用户的体验并增加了第三方支付账号的支付场景。
[0109]4)通过一个支付设备可绑定多张银行卡及多个第三方支付账号，解决了用户需随身携带多张银行卡及多个支付设备的问题，提高了用户的便捷性。
[0110]5)在移动支付环节加入银行虚拟账号服务提供商服务器，针对支付或圈存未使用该发卡行服务器的银行真实卡号的情况，建立了第三方支付公司与发卡行服务器之间通信，可传递将该银行虚拟卡号作为主账号的支付请求或圈存请求，实现了移动支付中第三方支付的功能。
【专利附图】
【附图说明】
[0111]图1为本发明系统的结构框图；
[0112]图2为本发明方法的流程图；
[0113]图3为本实施例中近程在线支付方式的示意图；
[0114]图4为本实施例中近程离线支付方式的示意图；
[0115]图5为本实施例中远程圈存电子现金支付方式的不意图；
[0116]图6为本实施例中远程在线支付方式的示意图。
[0117]图中:1、支付设备，2、发卡行服务器，3、第三方支付服务器，4、POS，5、收单行服务器，6、卡组织服务器，7、商户服务器，8、BVA SP服务器，9、NFC模块，10、嵌入式安全元件，11、通信模块，12、中转数据库，13、密钥数据库，14、支付数据库，15、CPU?
【具体实施方式】
[0118]下面结合附图和具体实施例对本发明进行详细说明。本实施例以本发明技术方案为前提进行实施，给出了详细的实施方式和具体的操作过程，但本发明的保护范围不限于下述的实施例。
[0119]如图1所示，一种基于银行虚拟卡号的移动支付系统包括支付设备1、发卡行服务器2、第三方支付服务器3、POS4、收单行服务器5、卡组织服务器6、商户服务器7和BVA SP服务器8，支付设备I分别连接P0S4、发卡行服务器2、商户服务器7和BVA SP服务器8，P0S4连接收单行服务器5，收单行服务器5连接卡组织服务器6，卡组织服务器6连接发卡行服务器2，发卡行服务器2连接BVA SP服务器8，BVA SP服务器8分别连接第三方支付服务器3和商户服务器7。其中，支付设备I包括但不限于手机、平板电脑及智能手表等可随身携带的电子设备，发卡行服务器2包括工商银行、建设银行及交通银行等商业银行，第三方支付服务器3包括具有相关支付牌照的第三方支付公司，如支付宝、财务通及易宝等，收单行服务器5包括工商银行、建设银行及交通银行等商业银行，及易宝、汇付天下等具有收单资质的第三方支付公司，卡组织即清算组织，如中国银联、VISA及MASTER等，商户服务器7指如淘宝、携程及美团等有在线支付需求的商户服务器7。
[0120]支付设备I直接接受P0S4通过近程通信方式(包括但不限于NFC)发起的支付请求，或者经BVA SP服务器8接受商户服务器7远程发起的支付请求，或者直接远程向BVASP服务器8发起圈存请求，支付设备I生成用于作为支付请求或圈存请求的主账号的银行虚拟卡号，支付请求通过P0S4、收单行服务器5、卡组织服务器6的中转传输或者圈存请求通过BVA SP服务器8的中转传输发送给发卡行服务器2，发卡行服务器2处理后反馈至支付设备I，完成支付或圈存；
[0121]当支付设备I使用第三方支付账号(包括非发卡行的其他银行真实卡号及非银行体系第三方支付公司的支付账号)进行支付或圈存时，则发卡行服务器2通过BVA SP服务器8的中转传输与第三方支付服务器3通信，在验证支付请求或圈存请求后反馈至支付设备1，完成支付或圈存。
[0122]支付设备I可以为手机、平板、智能手表及智能手环等支持移动支付的终端设备，作为移动支付系统中的用户环节，主要包括以下模块:
[0123]用于控制其他模块和计算密钥的CPUl5；
[0124]用于与P0S4通信的NFC模块9 ；
[0125]用于存储密钥数据的嵌入式安全元件10 (Embedded Secure Equipment, eSE)；
[0126]用于与BVA SP服务器8无线通信的无线通信模块11。
[0127]发卡行服务器2作为移动支付系统中的加解密及支付(圈存)请求验证环节，包括:
[0128]用于控制其他模块和计算密钥的CPUl5；
[0129]用于存储密钥数据的密钥数据库13 ;
[0130]用于存储支付数据的支付数据库14 ;
[0131]用于通过网络专线与BVA SP服务器8及卡组织服务器6通信的通信模块11 ;
[0132]第三方支付服务器3作为支付(圈存)请求验证环节，包括:
[0133]用于控制其他模块的CPU15 ；
[0134]用于存储支付数据的支付数据库14 ;
[0135]用于通过网络专线与BVA SP服务器8通信的通信模块11。
[0136]BVA SP服务器8、P0S4、收单行服务器5和卡组织服务器6作为移动支付系统中的中转环节，其均包括:
[0137]用于控制其他模块的CPU15 ；
[0138]用于存储中转数据的中转数据库12 ;
[0139]用于建立网络专线通信的通信模块11。
[0140]P0S4还包括用于与支付设备I通信的NFC模块9。
[0141]以NFC手机(即支付设备1)、招商银行服务器(即发卡行服务器2)、支付宝服务器(即第三方支付服务器3)、P0S4、工商银行服务器(即收单行服务器5)、银联服务器(即卡组织服务器6)、淘宝服务器(即商户服务器7)和BVA SP服务器8构成的移动支付系统为例，如图2所示，在本实施例系统中实现基于银行虚拟卡号的移动支付方法包括以下步骤:
[0142]步骤SI:NFC手机绑定至少一张银行真实卡号，并通过该银行柜面人工存储或在线下载存储的方式获得基于该银行真实卡号的密钥，同时根据支付宝服务器的认证绑定流程绑定支付宝账号，在绑定完成时，按顺序生成绑定卡号或账号的序号，用以标识该绑定卡号或账号；
[0143]步骤S2:NFC手机直接接受P0S4通过近程通信方式(包括但不限于NFC)发起的支付请求，或者经BVA SP服务器8接受淘宝服务器远程发起的支付请求，或者直接远程向BVA SP服务器8发起圈存请求，NFC手机对银行真实卡号进行加密，随机生成本次支付或圈存的银行虚拟卡号，并通过近程支付方式或远程支付方式向招商银行服务器发送将该银行虚拟卡号作为主账号的支付请求或圈存请求，其中，近程支付方式包括近程在线支付方式和近程离线支付方式，远程支付方式包括远程圈存电子现金支付方式和远程在线支付方式；
[0144]步骤S3:招商银行服务器接受支付请求或圈存请求，对银行虚拟卡号进行解密后获得银行真实卡号，判断本次支付或圈存是否使用该招商银行服务器的银行真实卡号，若否，执行步骤S4，若是，招商银行服务器生成支付或圈存请求验证结果，执行步骤S5 ;
[0145]步骤S4:招商银行服务器通过BVA SP服务器8将支付请求转发给相应的支付宝服务器，支付宝服务器生成支付或圈存请求验证结果，并经BVA SP服务器8转发给招商银行服务器；
[0146]步骤S5:招商银行服务器将支付或圈存请求验证结果反馈至NFC手机，完成本次支付或圈存。
[0147]其中，16位银行真实卡号为6226099112345670，其中:
[0148]622609为6位的BIN字段，记为B ;
[0149]9为I位的识别码字段，记为S ;
[0150]I为I位的固定值，记为G，；
[0151]1234567为7位的客户流水号字段，记为L ；
[0152]O为按银联标准由该位之前的15位卡号通过Luhn算法(Luhn algorithm)计算得出I位的校验码字段，记为J ;
[0153]银行虚拟卡号为19 位，记为 C1C2C3C4C5C6C7C8C9CltlC11C12C13C14C15C16C17C18C19，其中:
[0154]C1C2C3C4C5C6为 6 位的 BIN 字段，记为 B ；
[0155](:7为I位的识别码字段，记为S ;
[0156]C8C9CltlC11C12C13C14C15C16C17C18S 11 位的加密客户流水号字段，记为 H ；
[0157]C19为I位的校验码字段，记为J’ ；
[0158]NFC手机和招商银行服务器均设有用于加密、解密的密钥，密钥包括私钥1\和公钥T2, T1包含随机生成的不重复的n i个私钥密钥值P P (Kn^lOOOO，对Ii1个私钥密钥值P i进行顺序标号，获得私钥索引序号Z，公钥T2包含I个公钥密钥值P 2和由η 2个2位的公钥验证码Ρ3，0〈η2〈99，对η2个公钥验证码P 3进行顺序标号，获得公钥索引序号W ;
[0159]NFC手机加密的步骤包括:
[0160]A:每次支付或圈存，NFC手机生成本次支付或圈存所使用的R及X的值，例，R为16，X 为 02 ；
[0161]B:W取R相同数值为16，从T2中获取对应顺序为第16个的P 3，P# 57，将P 3、X顺序排列，得到4位的私钥索引序号Z，即5702 ;
[0162]C:根据5702从T1中获取对应的P i，先判断该P1是否已标记为已使用，若是，则返回步骤A重新取R值，若否，则使用PJt L进行加密，获得7位的L’，同时将NFC手机中本次支付所使用的P1标记为已使用，例L’为7654321 ；
[0163]D:根据己对W+X+L’进行加密，获得11位的加密客户流水号H，例H为12345654321 ；
[0164]E:通过Luhn算法将B+S+H计算后获得J’，即I，从而完整获得用于本次支付的19位的银行虚拟卡号(B+S+H+J’)，即622609+9+12345654321+1完成加密；
[0165]招商银行服务器解密的步骤包括:
[0166]a:招商银行服务器接收到银行虚拟卡号(6226099123456543211)后，先通过Luhn算法校验J’是否合法，若是，则执行步骤b，若否，则反馈支付请求失败信息；
[0167]b:用P2解密H，从而获得W、X及L’，分别为16、02及7654321 ；
[0168]c IT2中获取对应顺序为第W个的P3，将P3、X顺序排列，得到4位的私钥索引序号 I,即 5702 ；
[0169]d:根据Z从T1中获取对应顺序为第Z个的P i，并对P1的合法性进行验证，即判断P1否被标记为已使用，若否，则使用PJiL’进行解密，从而获得7位数字L，即1234567，同时标记该P1S已使用，若是，则反馈支付请求失败信息；
[0170]e:G为招商银行服务器自定义固定值，通过Luhn算法将B+S+G+L计算后获得J，即0，从而获得用于本次支付的16位的银行真实卡号(B+S+G+L+J)，即6226099112345670，至此完成解密。
[0171]下面对四种支付方式进行具体的说明:
[0172]当用户使用NFC手机通过近程通信方式(包括但不限于NFC)在商户P0S4处进行支付时，若电子现金余额不足或该商户强制要求联网在线验证支付合法性时，则须使用在线验证的方式(即P0S4需联网认证)进行符合银联规范的移动支付。如图3所示，近程在线支付方式包括以下步骤(图3中的虚线表示在账号发行方为第三方支付公司时才需要执行的步骤):
[0173]101:P0S4发起支付请求，NFC手机生成本次支付的银行虚拟卡号，通过近程通信方式(包括但不限于NFC)以该银行虚拟卡号作为主账号来响应P0S4发起的支付请求，其中需要变更传输给P0S4的主账号及第2、3磁道中的主账号信息，支付请求内包括主账号、卡有效期、卡片序列号、第2磁道数据及第3磁道数据等数据信息；
[0174]102:P0S4通过网络专线将支付请求转发给工商银行服务器；
[0175]103:工商银行服务器通过网络专线将支付请求转发给银联服务器；
[0176]104:银联服务器根据银行虚拟卡号中的BIN(卡组织分配给发卡行的6位数字BIN字段，用于识别不同的发卡行)将支付请求转发给相应的招商银行服务器，发卡行根据识别码(发卡行在6位BIN后自行定义的I位数字识别码字段，用于识别该账号使用银行虚拟卡号支付方式)判断为银行虚拟卡号后，对其进行解密，获得银行真实卡号及序号，判断本次支付是否使用招商银行服务器的银行真实卡号，若否，执行步骤105，若是，则招商银行服务器对支付请求进行有效性验证，并执行步骤109 ;
[0177]105:招商银行服务器将支付请求、与该银行真实卡号绑定的用户标识(用户标识指支付设备I的移动设备国际识别码，Internat1nal Mobile Equipment Identity，IMEI)及序号转发给BVA SP服务器8 ；
[0178]106:BVA SP服务器8根据用户标识及序号将支付请求转发给相应的支付宝服务器;
[0179]107:支付宝服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器8 ；
[0180]108:BVA SP服务器8将支付请求验证结果反馈至招商银行服务器；
[0181]109:招商银行服务器将支付请求验证结果反馈至银联服务器；
[0182]110:银联服务器将支付请求验证结果反馈至工商银行服务器；
[0183]111:工商银行服务器将支付请求验证结果反馈至P0S4 ;
[0184]112:P0S4将支付请求验证结果反馈至NFC手机，完成本次支付。
[0185]当用户使用NFC手机通过近程通信方式(包括但不限于NFC)在商户P0S4处进行支付时，若电子现金余额足够且该商户不强制要求联网在线验证支付合法性时，则可使用离线验证的方式(即P0S4无需联网认证)进行符合卡组织规范的移动支付。如图4所示，近程离线支付方式包括以下步骤(图4中虚线代表在账号发行方为第三方支付公司时才需要执行的步骤，点线代表异步执行的步骤):
[0186]201:P0S4发起支付请求，NFC手机生成本次支付的银行虚拟卡号，并通过近程通信方式(包括但不限于NFC)以该银行虚拟卡号作为主账号来响应P0S4发起的支付请求，即变更传输给P0S4的主账号及第2、3磁道中的主账号信息；
[0187]202:P0S4将支付请求验证结果反馈至NFC手机，完成本次支付；
[0188]203:P0S4通过网络专线异步将离线时间段内的所有支付请求批量转发给工商银行服务器；
[0189]204:工商银行服务器通过专线异步将批量的支付请求转发给银联服务器；
[0190]205:银联服务器根据银行虚拟卡号中的BIN将支付请求转发给相应的招商银行服务器，招商银行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号，判断本次支付是否使用招商银行服务器的银行真实卡号，若否，执行步骤206，若是，则招商银行服务器对支付请求进行有效性验证，并执行步骤210 ;
[0191]206:招商银行服务器将支付请求、与该银行真实卡号绑定的用户标识及序号转发给BVA SP服务器8 ；
[0192]207:BVA SP服务器8根据用户标识及序号将支付请求转发给相应支付宝服务器；
[0193]208:支付宝服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器8 ；
[0194]209:BVA SP服务器8将支付请求验证结果反馈至招商银行服务器；
[0195]210:招商银行服务器将支付请求验证结果反馈至银联服务器；
[0196]211:银联服务器将支付请求验证结果反馈至工商银行服务器；
[0197]212:工商银行服务器将支付请求验证结果反馈至P0S4。
[0198]当用户使用远程支付方式在NFC手机中对某个已绑定的账号进行电子现金圈存时，则须通过BVA SP直联发卡行来完成电子现金圈存，若圈存账号为第三方支付公司，则还须联接第三方支付公司。如图5所示，远程圈存电子现金支付方式包括以下步骤(图5中虚线含义同图3):
[0199]301:NFC手机生成本次支付的银行虚拟卡号，并通过无线通信方式以该银行虚拟卡号作为主账号来向BVA SP服务器8发起圈存请求；
[0200]302:BVA SP服务器8根据银行虚拟卡号中的BIN将圈存请求转发给相应的发卡行，招商银行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号，判断本次支付是否使用招商银行服务器的银行真实卡号，若否，执行步骤303，若是，则招商银行服务器对圈存请求进行有效性验证，并执行步骤307 ;
[0201]303:招商银行服务器将与该银行真实卡号绑定的用户标识及序号转发给BVA SP服务器8 ;
[0202]304:BVA SP服务器8根据用户标识及序号将圈存请求转发给相应的支付宝服务器;
[0203]305:支付宝服务器对圈存请求进行有效性验证，并将圈存请求验证结果反馈至BVA SP服务器8 ；
[0204]306:BVA SP服务器8将圈存请求验证结果反馈至招商银行服务器；
[0205]307:招商银行服务器将圈存请求验证结果反馈给NFC手机，完成本次圈存。
[0206]当用户使用远程支付方式在NFC手机中进行在线支付时，则须通过BVA SP直联发卡行来完成在线支付，若所使用的账号为第三方支付公司，则还须联接第三方支付公司。如图6所示，远程在线支付方式包括以下步骤(图6中虚线含义同图3):
[0207]401:用户在淘宝服务器的支付平台向BVA SP服务器8发起支付请求；
[0208]402:BVP SP服务器通过无线通信方式发送至NFC手机；
[0209]403:NFC手机生成本次支付的银行虚拟卡号，并通过无线通信方式以该银行虚拟卡号作为主账号来向BVA SP服务器8响应由淘宝服务器发起的支付请求；
[0210]404:BVA SP服务器8根据银行虚拟卡号中的BIN将支付请求转发给相应招商银行服务器，招商银行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号，判断本次支付是否使用招商银行服务器的银行真实卡号，若否，执行步骤405，若是，则招商银行服务器对支付请求进行有效性验证，并执行步骤409 ;
[0211]405:招商银行服务器将与该银行真实卡号绑定的用户标识及序号转发给BVA SP服务器8 ;
[0212]406:BVA SP服务器8根据用户标识及序号将支付请求转发给相应的支付宝服务器;
[0213]407:支付宝服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器8 ；
[0214]408:BVA SP服务器8将支付请求验证结果反馈至招商银行服务器；
[0215]409:招商银行服务器将支付请求验证结果反馈给淘宝服务器；
[0216]410:淘宝服务器将支付请求验证结果反馈给NFC手机，完成本次支付。
[0217]综上，本发明的核心要素是通过在移动支付环节中引入BVA SP的角色，作用包括:
[0218]I)用户所持有的支付设备I或用户远程操作的商户服务器7的支付平台分别与BVA SP服务器8通过通讯模块无线联网的模式进行通讯，来完成绑定、查询及支付等请求的提交及中转工作。
[0219]2) BVA SP服务器8与发卡行服务器2通过通讯模块专线联网的模式进行通讯，来完成绑定、查询及支付等请求的中转及反馈工作。
[0220]3)BVA SP服务器8与第三方支付服务器3通过通讯模块专线联网的模式进行通讯，来完成绑定、查询及支付等请求的中转及反馈工作。
[0221]当用户进行移动支付时，在其已绑定于支付设备I上的16位银行真实卡号的基础上，将本次支付交易所使用的账号(包括银行真实卡号与第三方支付账号)与16位银行真实卡号通过私钥及公钥先后进行双重加密混淆处理后生成符合卡组织要求的19位银行虚拟卡号，进而完成支付流程，从而大幅提高了移动支付的安全性与兼容性。
【权利要求】
1.一种基于银行虚拟卡号的移动支付系统，其特征在于，包括支付设备、发卡行服务器、第三方支付服务器、POS、收单行服务器、卡组织服务器、商户服务器和BVA SP服务器，所述支付设备分别连接POS、发卡行服务器、商户服务器和BVA SP服务器，所述POS连接收单行服务器，所述收单行服务器连接卡组织服务器，所述卡组织服务器连接发卡行服务器，所述发卡行服务器连接BVA SP服务器，所述BVA SP服务器分别连接第三方支付服务器和商户服务器； 支付设备直接接受POS近程发起的支付请求，或者经BVA SP服务器接受商户服务器远程发起的支付请求，或者直接远程向BVA SP服务器发起的圈存请求，支付设备生成用于作为支付请求或圈存请求的主账号的银行虚拟卡号，支付请求通过P0S、收单行服务器、卡组织服务器的中转传输或者圈存请求通过BVA SP服务器的中转传输发送给发卡行服务器，发卡行服务器处理后反馈至支付设备，完成支付或圈存； 当支付设备使用第三方支付账号进行支付或圈存时，发卡行服务器通过BVASP服务器的中转传输与第三方支付服务器通信，在验证支付请求或圈存请求后反馈至支付设备，完成支付或圈存。
2.根据权利要求1所述的一种基于银行虚拟卡号的移动支付系统，其特征在于，所述支付设备包括: 用于控制其他模块和计算密钥的CPU ; 用于与POS通信的NFC模块； 用于存储密钥数据的嵌入式安全元件； 用于与BVA SP服务器无线通信的无线通信模块。
3.根据权利要求1所述的一种基于银行虚拟卡号的移动支付系统，其特征在于，所述发卡行服务器包括: 用于控制其他模块和计算密钥的CPU; 用于存储密钥数据的密钥数据库； 用于存储支付数据的支付数据库； 用于通过网络专线与BVA SP服务器及卡组织服务器通信的通信模块； 所述第三方支付服务器包括: 用于控制其他模块的CPU ； 用于存储支付数据的支付数据库； 用于通过网络专线与BVA SP服务器通信的通信模块。
4.根据权利要求1所述的一种基于银行虚拟卡号的移动支付系统，其特征在于，所述BVA SP服务器、P0S、收单行服务器、卡组织服务器和商户服务器均包括: 用于控制其他模块的CPU ； 用于存储中转数据的中转数据库； 用于建立网络专线通信的通信模块； 所述POS还包括用于与支付设备通信的NFC模块。
5.一种根据权利要求1所述的系统实现基于银行虚拟卡号的移动支付方法，其特征在于，包括以下步骤: 步骤S1:支付设备绑定至少一张银行真实卡号，并通过该银行柜面人工存储或在线下载存储的方式获得基于该银行真实卡号的密钥，同时根据第三方支付服务器的认证绑定流程继续绑定其他第三方支付账号，在绑定完成时，按顺序生成绑定卡号或账号的序号，序号标识该绑定卡号或账号； 步骤S2:支付设备直接接受POS近程发起的支付请求，或者经BVA SP服务器接受商户服务器远程发起的支付请求，或者直接远程向BVA SP服务器发起的圈存请求，支付设备对银行真实卡号进行加密，随机生成本次支付或圈存的银行虚拟卡号，并通过近程支付方式或远程支付方式向发卡行服务器发送将该银行虚拟卡号作为主账号的支付请求或圈存请求，其中，近程支付方式包括近程在线支付方式和近程离线支付方式，远程支付方式包括远程在线支付方式和远程圈存电子现金支付方式； 步骤S3:发卡行服务器接受支付请求或圈存请求，对银行虚拟卡号进行解密后获得银行真实卡号，判断本次支付或圈存是否使用该发卡行服务器的银行真实卡号，若否，执行步骤S4，若是，发卡行服务器生成支付或圈存请求验证结果，执行步骤S5 ; 步骤S4:发卡行服务器通过BVA SP服务器将支付请求转发给相应的第三方支付服务器，第三方支付服务器生成支付或圈存请求验证结果，并经BVA SP服务器转发给发卡行服务器； 步骤S5:发卡行服务器将支付或圈存请求验证结果反馈至支付设备，完成本次支付或圈存。
6.根据权利要求5所述的一种基于银行虚拟卡号的移动支付系统，其特征在于，所述近程在线支付方式包括以下步骤: 101:P0S发起支付请求，支付设备生成本次支付的银行虚拟卡号，通过近程通信方式以该银行虚拟卡号作为主账号来响应POS发起的支付请求，近程通信方式包括但不限于NFC ； 102:P0S通过网络专线将支付请求转发给收单行服务器； 103:收单行服务器通过网络专线将支付请求转发给卡组织服务器； 104:卡组织服务器根据银行虚拟卡号中的BIN将支付请求转发给相应的发卡行服务器，发卡行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号及序号，判断本次支付是否使用该发卡行服务器的银行真实卡号，若否，执行步骤105，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤109 ; 105:发卡行服务器将支付请求、与该银行真实卡号绑定的用户标识及序号转发给BVASP服务器； 106:BVA SP服务器根据用户标识及序号将支付请求转发给相应的第三方支付服务器; 107:第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器； 108:BVA SP服务器将支付请求验证结果反馈至发卡行服务器； 109:发卡行服务器将支付请求验证结果反馈至卡组织服务器； 110:卡组织服务器将支付请求验证结果反馈至收单行服务器； 111:收单行服务器将支付请求验证结果反馈至POS ; 112:P0S将支付请求验证结果反馈至支付设备，完成本次支付。
7.根据权利要求5所述的一种基于银行虚拟卡号的移动支付系统，其特征在于，所述近程离线支付方式包括以下步骤: 201:POS发起支付请求，支付设备生成本次支付的银行虚拟卡号，并通过近程通信方式以该银行虚拟卡号作为主账号来响应POS发起的支付请求，近程通信方式包括但不限于NFC ； 202:P0S将支付请求验证结果反馈至支付设备，完成本次支付； 203:P0S通过网络专线异步将离线时间段内的所有支付请求批量转发给收单行服务器; 204:收单行服务器通过专线异步将批量的支付请求转发给卡组织服务器； 205:卡组织服务器根据银行虚拟卡号中的BIN将支付请求转发给相应的发卡行服务器，发卡行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号及序号，判断本次支付是否使用该发卡行服务器的银行真实卡号，若否，执行步骤206，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤210 ; 206:发卡行服务器将支付请求、与该银行真实卡号绑定的用户标识及序号转发给BVASP服务器； 207:BVA SP服务器根据用户标识及序号将支付请求转发给相应第三方支付服务器； 208:第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器； 209:BVA SP服务器将支付请求验证结果反馈至发卡行服务器； 210:发卡行服务器将支付请求验证结果反馈至卡组织服务器； 211:卡组织服务器将支付请求验证结果反馈至收单行服务器； 212:收单行服务器将支付请求验证结果反馈至P0S。
8.根据权利要求5所述的一种基于银行虚拟卡号的移动支付系统，其特征在于，所述远程圈存电子现金支付方式包括以下步骤: 301:支付设备生成本次支付的银行虚拟卡号，并通过无线通信方式以该银行虚拟卡号作为主账号来向BVA SP服务器发起圈存请求； 302:BVA SP服务器根据银行虚拟卡号中的BIN将圈存请求转发给相应的发卡行，发卡行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号及序号，判断本次支付是否使用该发卡行服务器的银行真实卡号，若否，执行步骤303，若是，则发卡行服务器对圈存请求进行有效性验证，并执行步骤307 ; 303:发卡行服务器将与该银行真实卡号绑定的用户标识及序号转发给BVASP服务器； 304:BVA SP服务器根据用户标识及序号将圈存请求转发给相应的第三方支付服务器; 305:第三方支付服务器对圈存请求进行有效性验证，并将圈存请求验证结果反馈至BVA SP服务器； 306:BVA SP服务器将圈存请求验证结果反馈至发卡行服务器； 307:发卡行服务器将圈存请求验证结果反馈给支付设备，完成本次圈存。
9.根据权利要求5所述的一种基于银行虚拟卡号的移动支付系统，其特征在于，所述远程在线支付方式包括以下步骤: 401:用户在商户服务器的支付平台向BVA SP服务器发起支付请求； 402:BVP SP服务器通过无线通信方式发送至支付设备； 403:支付设备生成本次支付的银行虚拟卡号，并通过无线通信方式以该银行虚拟卡号作为主账号来向BVA SP服务器响应由商户服务器发起的支付请求； 404:BVA SP服务器根据银行虚拟卡号中的BIN将支付请求转发给相应发卡行服务器，发卡行服务器识别银行虚拟卡号后进行解密，获得银行真实卡号及序号，判断本次支付是否使用该发卡行服务器的银行真实卡号，若否，执行步骤405，若是，则发卡行服务器对支付请求进行有效性验证，并执行步骤409 ; 405:发卡行服务器将与该银行真实卡号绑定的用户标识及序号转发给BVASP服务器； 406:BVA SP服务器根据用户标识及序号将支付请求转发给相应的第三方支付服务器; 407:第三方支付服务器对支付请求进行有效性验证，并将支付请求验证结果反馈至BVA SP服务器； 408:BVA SP服务器将支付请求验证结果反馈至发卡行服务器； 409:发卡行服务器将支付请求验证结果反馈给商户服务器； 410:商户服务器将支付请求验证结果反馈给支付设备，完成本次支付。
10.根据权利要求5所述的一种基于银行虚拟卡号的移动支付系统，其特征在于，所述银行真实卡号为 16 位，记为 A1A2A3A4A5A6A7A8A9AltlA11A12A13A14A15A16，其中: A1A2A3A4A5A6为6位的BIN字段，记为B ； ~为I位的识别码字段，记为S ; 八8为I位的固定值，记为G ； A9A10A11A12A13A14A15为7位的客户流水号字段，记为L ; A16为按银联标准由该位之前的15位卡号通过Luhn算法计算得出I位的校验码字段，记为J ;
所述银行虚拟卡号为 19 位，记为 C1C2C3C4C5C6C7C8C9CltlC11C12C13C14C15C16C17C18C19，其中: C1C2C3C4C5C6为6位的BIN字段，记为B ； (:7为1位的识别码字段，记为S; C8C9CltlC11C12C13C14C15C16C17C18S 11位的加密客户流水号字段，记为H ； C19为I位的校验码字段，记为J’ ； 所述支付设备和发卡行服务器均设有用于加密、解密的密钥，密钥包括私钥T1和公钥T2, T1包含随机生成的不重复的n i个私钥密钥值P P (Kn^lOOOO，对Ii1个私钥密钥值P i进行顺序标号，获得私钥索引序号Z，公钥T2包含I个公钥密钥值P 2和由η 2个2位的公钥验证码Ρ3，0〈η2〈99，对η2个公钥验证码P 3进行顺序标号，获得公钥索引序号W ; 所述支付设备加密的步骤包括: A:每次支付或圈存，支付设备生成本次所使用的R及X的值，R的值为2位数字随机数，0〈R〈99，X的值为用于标明本次所用的银行卡号或第三方支付账号在支付设备中绑定的2位的序号，0〈X〈99 ； B:W取R相同数值，从T2中获取对应顺序为第W个的P 3，将P3、X顺序排列，得到4位的私钥索引序号Z ； C:根据Z从T1中获取对应顺序为第Z个的P P先判断该P1是否已标记为已使用，若是，则返回步骤A重新取R值，若否，则使用PJt L进行加密，获得7位的L’，同时将支付设备中本次所使用的P1标记为已使用； D:根据匕对W+X+L’进行加密，获得11位的加密客户流水号H ； E:通过Luhn算法将B+S+H计算后获得J’，获得用于本次的19位的银行虚拟卡号，即B+S+H+J’，完成加密； 所述发卡行服务器解密的步骤包括: a:发卡行服务器接收到银行虚拟卡号后，先通过Luhn算法校验J’是否合法，若是，则执行步骤b，若否，则反馈支付请求失败信息；b:用P2解密H，从而获得W、X及L’ ； c:从T2中获取对应顺序为第W个的P 3，将P3、X顺序排列，得到4位的私钥索引序号Z ；d:根据Z从T1中获取对应顺序为第Z个的P i，并对P1的合法性进行验证，即判断P被标记为已使用，若否，则使用PJt L’进行解密，获得7位数字L，同时标记该P 已使用，若是，则反馈支付请求失败信息； e:G为发卡行服务器自定义固定值，通过Luhn算法将B+S+G+L计算后获得J，获得用于本次的16位的银行真实卡号，即B+S+G+L+J，完成解密。
【文档编号】G06Q20/38GK104504565SQ201510022992
【公开日】2015年4月8日 申请日期:2015年1月16日 优先权日:2015年1月16日
【发明者】许逸宁, 欧如锋, 胡炜 申请人:上海浩恺信息科技有限公司