几个月前，支付宝在杭州率先实现公交扫码付。一石激起千层浪，我们终端设备的升级改造迫在眉睫。而实现银联小额免密免签，扫码付与ODA,时间紧迫，责任重大。
7月24号到湖南银联调试小额免密与 银联扫码支付，原因是之前的调试很不顺利。要么是网络不通，要么是商户号没权限，要么是主秘钥没提供对。
不得不去湖南银联一趟现场调试。
不过可喜可贺，来湖南的第一天，就把小额免密免签与银联扫码付都调通了。且找到之前一直不通的原因竟然是 商户号小额免密免签权限！！来这边分配了个，就通了。
但是有一个问题比较让人头疼！！就是银联后台不支持长连接。每次交易完之后，连接不能保持，过一段时间后台会断开与终端的连接。
当面问银联的技术人员，他们解释到有这么多的终端，如果都保持长连接，后台的压力太大。所以后台才不支持长连接。
可是，问题是我这边终端每次交易都去建立连接，交易，断开连接。耗时会很长，影响用户体验！作为一个负责任的技术人员，应该考虑这方面的事情，努力提高用户的体验，提升公司产品的竞争力。
银联技术人员说道，你们用的GPRS走的运营商的网络，他们网络建立连接，断开连接很快的呀，不会影响用户体验吧？我给他们解释道，我们是外购的第三方的GPRS模块。不光是我们，其他厂家的产品用到GPRS无限数传大多都是用的华为，中兴等第三方的模块 。
终端与银联后台通信，相当于又中转了一层，终端- >串口->GPRS模块->银联后台服务。
GPRS网络与银联后台之间连接网络与断开是很快，但是，终端是通过串口AT指令操纵的GPRS模块。串口波特率是115200，那么建立连接与断开连接，肯定就存在一个耗时的过程。
尤其是断开连接，AT指令是发送一连串的特殊字符间隔几秒时间，这样GPRS模块才知道终端是要断开连接，否则是认为终端在发送数据。试想，这断开连接的几秒种就已经严重影响了用户体验。公交上刷卡哪敢等待那么久。
那么，如何解决这头疼的问题呢？
我想到三种方案。
方案一，我终端自己实现长连接，我定时（比如30秒）发送8583回响测试报文，如果发送成功，则证明后台没有断开连接，如果断开了，自动重连。且我不必接收和验证后台应答报文，只需判断是否成功发送了报文就能知道连接是否还保持着。
方案二，我终端只建立连接，从不断开连接，不管他后台是否断开了连接。这样我终端可以保持短暂的长连接，只有第一次交易时，可能会失败，我提示用户请重刷卡，在提示的同时自动去建立连接，这样后续再有用户连着刷卡，速度很快，不受影响。
方案三，我终端同样是只建立连接，从不断开连接，让其保持短暂的长连接。是否断开连接后台说了算。但是我得知道这连接空闲多久后台会断开。这样我定时空闲一定时间，下次交易时让终端必须先建立连接再交易。
总结三种方案，
第一种，虽然可行，但是不知私下保持长连接，量大的话，银联后台是否受得了，他们是否允许这样做。
第二种，用户的体验会受影响，虽然提示了重刷，刷第二次就可以成功了，但是每次第一个用户的消费，都要受这般待遇吗？体验不好
第三种，我个人觉得最优方案。终端的空闲时间长了，下次交易必须先建立连接。这样，虽然有个建立连接的耗时，但是用户第一次刷卡就交易成功了，且后续用户再接着刷卡，则速度很快，体验好。第一个刷卡的用户吃点亏，速度慢些。相比常规的每笔交易都去建立连接，交易，再断开连接好得多。这样，既符合银联保持短连接的要求，我终端又保持了短暂的长连接，交易速度得到了保证。
可否有更好的方案？谁有更好的注意，还请不吝赐教，不胜感激。
说了这么多，都跑题了，
这里记录下之前与河南银联的调试过程。这么热的三伏天，往河南银联了三四趟。其中的一天，同王总一起上午下午各跑一趟，从高新区到郑东新区。
详细的过程记录，秘钥信息及报文验证过程
河南银联商务提供的商户号终端号信息如下：
拿河南银联商务提供的商户号终端号密文的第一个测试，
"898410148161370","84900503","101400","B1CA4EB3DFEB0952CFEEB7169881B8C8","B1CA4EB3DFEB0952CFEEB7169881B8C8"
经过母pos导出来后的密文，河南银联张工验证确认明文的秘钥没问题。
秘钥如下：
终端号：84900503
商户号：898410148161370
密文：B1CA4EB3DFEB0952CFEEB7169881B8C8
明文：C65D3A0BDC846DEC27F28091C3CC9857
//=================================================
以下为8583银联通信报文：
签到：
Send date size:89
00 57 60 00 30 00 00 61 31 00 31 11 08 0800 00 20 00 00 00 C0 00 16 50 02 05 38 34 39 30 30 35 30 33 38 39 38 34 31 3031 34 38 31 36 31 33 37 30 00 11 00 00 05 19 00 30 00 25 53 65 71 75 65 6E 6365 20 4E 6F 31 32 33 30 36 30 38 34 39 30 30 35 30 33 00 03 30 30 31
应答：
<Receive datesize:123
<00 79 60 00 00 00 30 61 31 00 31 11 0808 10 00 38 00 01 0A C0 00 14 50 02 05 21 02 41 07 20 08 48 02 49 10 30 30 3032 31 35 38 35 34 35 33 37 30 30 38 34 39 30 30 35 30 33 38 39 38 34 31 30 3134 38 31 36 31 33 37 30 00 11 00 00 00 01 00 30 00 40 B9 C4 10 6E EB C5 24 6E25 20 AA 49 39 BD 13 73 7F 69 9C 5E EE B4 E7 AD 4A 33 98 86 00 00 00 00 00 0000 00 A7 14 A4 C9
<-Er PIK错误
<-签到失败
应答报文的解析：
MSG TYPE：0810
BITMAP：003800010AC00014
11域：500205
12域：210241
13域：0720
32域：0848024910
37域：303030323135383534353337
39域：3030
41域：3834393030353033
42域：383938343130313438313631333730
60域：0011000000010030
62域：0040B9C4106EEBC5246E2520AA4939BD13737F699C5EEEB4E7AD4A3398860000000000000000A714A4C9
62域说明，0040表示长度，后面格式为 16字节pinKey密文秘钥+4字节校验码+16字节MAC秘钥密文+4字节校验码
接下来看下秘钥的解密过程，规范中的解释：
以下为秘钥的计算过程：
接下来用解密出的明文，计算下校验码，看是否同 7F699C5E 一致：
结果发现，计算出的校验码前四字节是059E11A3，而后台返回的校验码是7F699C5E，
那么，要么是银联主秘钥从母pos解密出来的不对。要么是跟后台的不对应，银联给提供的商户秘钥不对。
要么。。。，难道是 解密算法错了？后续分析 湖南银联的签到报文。
关于签到报文和秘钥解析,销售点终端POS应用规范中介绍：
接下来试试湖南银联的签到报文，同样的程序,只改通信地址。
//=================================================湖南秘钥：
<OK
<-连接成功
>>connect succ!
->签到中...
>Send date size:89
>00 57 60 01 38 00 00 61 31 00 3111 08 08 00 00 20 00 00 00 C0 00 16 50 02 11 39 39 39 39 39 39 30 36 30 30 3134 33 30 31 37 30 31 31 39 39 39 39 00 11 00 00 05 19 00 30 00 25 53 65 71 7565 6E 63 65 20 4E 6F 31 32 33 30 36 30 39 39 39 39 39 39 30 36 00 03 30 30 31
<Receive datesize:123
<00 79 60 00 00 01 38 61 31 00 31 11 0808 10 00 38 00 01 0A C0 00 14 50 02 11 22 13 01 07 20 08 00 08 55 00 32 32 3133 30 31 34 39 31 33 32 39 30 30 39 39 39 39 39 39 30 36 30 30 31 34 33 30 3137 30 31 31 39 39 39 39 00 11 00 00 05 19 00 30 00 40 46 F1 61 A7 43 49 7B 32EA C7 60 DF 5E A5 7D F5 90 0E CC E3 97 77 31 A7 EA 40 2D DF 00 00 00 00 00 0000 00 CF F1 59 2A
<-签到成功!
应答报文解析：
MSG TYPE：0810
BITMAP：003800010AC00014
11域：500211
12域：221301
13域：0720
32域：0800085500
37域：323231333031343931333239
39域：3030
41域：3939393939393036
42域：303031343330313730313139393939
60域：0011000005190030
62域：004046F161A743497B32EAC760DF5EA57DF5900ECCE3977731A7EA402DDF0000000000000000CFF1592A
62域说明，0040表示长度，后面格式为 16字节pinKey密文秘钥+4字节校验码+16字节MAC秘钥密文+4字节校验码
秘钥解密计算过程：（采用 3DES 双倍长秘钥计算算法）
结果中的 D931648F3DE313A4A22C15DCA4F4299E即为采用3DES（双倍长）秘钥解密出的Pin Key明文秘钥。
接下来用Pin Key明文秘钥对8字节的00加密，算出来校验码和900ECCE3比较，看是否相等。若相等，则说明后台和终端秘钥一致，终端秘钥无误。
计算结果，900ECCE3C957C7A4，取前四字节，900ECCE3，和收到报文中的秘钥校验码900ECCE3一致，结果表明后台和终端秘钥一致，终端秘钥无误。
接下来解密MAC秘钥，并校验是否同后台的一致：
注，MAC计算的校验码，采用的单倍长DES算法，这个已同银联确认过，无异议。
经过上述测试，湖南银联的签到报文，秘钥解密准确无误。
结论： 三种可能 ： 1，母pos导出来明文不对。2，银联商务提供的秘钥密文不对。3，解密算法不对。
第一种可能，银联张工主管秘钥母pos KEK分量管理，验证密文明文对应。暂可排除。
第三种可能，其他地方银联正常签到没问题。
总结，最大的可能是银联商务提供的密文不对 。
最后续。。。，银联商务重新给提供了个商户号，终端号，主秘钥。测试签到成功，证明是第二种可能，提供的秘钥密文不对。
附几张湖南的美景，橘子洲
