常见对接问题汇总

常见对接问题汇总

第一类：常见报文错误

1.文档中的必传项丢失,易丢失的如 2域（消费撤销必传）、4域、23域、35/36域、52域。

2.补0操作引起的问题，易补错的如 2域、35/36域，长度是基数会按规则补0，无论是左补0还是右补0，原数据长度（卡磁长度）不能变。（说明：2左靠右补0；35/36：右靠左补0）。

3.对比tpdu是否正确，可以根据当前41/42长度确定，对比消息类型是否正确。 4.域长度问题，LLVAR与LLLVAR长度，易错：61域长度。（LLVAR用一个字节表示长度；LLLVAR用两个字节表示长度。）

5.传不支持的交易，比如，大pos不支持无密交易(消费/消费撤销)（022），都不支持退货交易。

6.同一终端当天同种交易 流水号不能重复，11域不可重复。 7.域信息编码格式错误。

8.位图信息包含了域信息没有的域。

9.MAC是8个字节的ASCII码；38域是17个字节的ASCII码；mak是双倍长的，是32位的。

10.我们这边一般都不校验26域；

11.消费撤销注意38域，容易漏传或格式不对，传原交易的订单号，作为参考号使用。

第二类：常见错误码及原因 1.返回A0（银联规定）

1)一渠道对应一密钥，即一个渠道下所有商户公用同一密钥，更新密钥必须全部更新，如果密钥不同步，可以重新签到解决；

2)Mac校验未过，mac按照银联规范计算，mackey进行双倍长密钥计算。（用分配的主密钥明文解密pinkey和mackey，如果解出的checkvalue值都正确，说明分配的主密钥明文没有问题。使用的是3des加解密。） 2.交易失败99

1).IC卡交易必传23域；磁条卡交易必传二或三磁信息； 2)比对交易金额是否正确（有时有通道对交易金额有限制）；

3)新下发的商户，在高庆瑞（mpos）的系统里，这个商户对应的银行商户，终端一般在晚上10点才签到，也就是说新发商户没有到生效时间，立马交易肯定会交易失败。

4)有时候一个商户号下所有交易都是失败，如果不是报文问题，平台没有异常，有可能是商户录入的问题。

5)设备与商户未绑定，需要确定下这笔交易的终端号和商户号是否建立关联关系。 6)宕机情况下，可能存在缓存,引起的11域重复(不是交易上送的11域,是我们这边查到的)，可以根据商户号和终端号清除一下缓存。

7)如果简单的签到没有成功，有可能是终端密钥录入有问题，可以计算并比较计算出的checkvalue值是否相同。

8)商户与代理商未绑定，渠道商户管理下的渠道商户信息管理，根据商户编号查询是否在代理商下绑定。

9)多传不必要传的域信息，比如消费撤销不用传25、26、37（以前37域参考号作

为对账依据，现在是商家订单号最后六位11域作为对账依据） 3.交易没有返回

1)可能是tpdu错误(比如从手刷切到大pos没有更改tpdu)； 2)可能传错了渠道id。 3)报文格式错误。 4.返回42

可能是风险控制，可能原因：同卡同金额交易次数过多。 一般只限制一天，第二天可以正常交易。 5.错误码210

值校验未通过，对比传入与返回的41/42域信息，可能存在带空格导致信息不完全一致的。

6.手刷消费返回05

不是错误信息，返回05需要sleep 5秒后进行交易状态查询确定订单状态。做交易状态查询三次，如果交易状态查询的返回码也是05，则是产生了单边账，一般遇到银行单边的情况，银行会在一周内将钱退还到交易人卡中（钱是否到账咨询结算）。 7.返回99

1).集中时间段内大批交易失败，可能是通道重启或是通道问题；

2).PIN解密失败，可能是传二磁三磁信息有问题，看补0操作和长度是否正确。 8.返回203

一般是mac校验未过，可以查看渠道id是否录入正确，可能在录入时录入了不识别的符号。

9.大批量的交易失败，

可以核对当前时段的机房服务器情况和数据库（数据库是否到达最大连接数，是否有死锁）；交易失败但是银行扣款成功，则是单边账，一般确认是单边账情况的，会在一周内将钱返还到持卡人卡中（钱是否到账咨询结算）；

可能是网络问题，导致响应超时，会造成大部分的商户无法交易。由于网络问题引起的不成功的交易会冲正到持卡人卡里。 10.如果有的交易在交易记录里面没有记录

要先问一下是对方系统没有订单还是我们对账文件中没有，然后再去后台查询相关订单信息。（如果是对方系统找不到订单信息的话，那我们这边也是不会有记录的。） 11.有的商户下的交易出现大批量的交易失败，

或者交易出现短信通知的商户名与后台大商户不一致的情况，可能是由于商户违规操作被禁，会随机路由到其他商户上面去，但是这样不会影响到结算。 12.运营后台不能正常生成xmk，

根据系统工具管理下的Redis缓存数据查询，看是否能连接上Redis缓存服务（吴建勇）

13.获取的银行通道编码为空

没有正确配置银行通道编码；在 银行路由管路下的渠道路由配置 里面配置。 14.关于45应答码：

（消费撤销和冲正交易返回45，按照无此交易；消费返回45，则按照风控限制降级交易；）

消费判断是否是降级交易：二磁信息里面D后面的第五位是2或者6就是IC卡，IC卡交易没有55域就属于降级交易（风险控制判断2或6） 15.设备信息不存在

Tpdu与41/42域是否对应，看是否配置正确（终端管理----系统终端管理查询） 16.返回50 金额超限

先查询同卡交易次数和交易金额，如果没有超限，则可能是运营给商户设置了限额，也可能是这张卡的限额。 17.返回66 （全渠道返回）

银联应答，具体原因得持卡人查询发卡行。

第三类：常见业务类问题

1.限额问题

一个商户单笔限额5W，日限额300W；个别银行会有限制。 2.支持交易问题

手刷支持：消费、余额查询、交易状态查询、消费撤销，不支持退货。 手刷没有冲正，交易状态查询接口代替冲正，可以通过查询接口确定订单是否成功。 大pos支持：消费、余额查询、消费撤销、冲正，不支持退货和无密交易，没有交易状态查询。 3.对账文件问题

1).对账文件凌晨4点生成，每日9点开始出款，切日时间是每日0点。 2).商家订单号组成：交易商户编号+系统终端号+交易时间+流水号，

因此，在对账文件中，可以根据商家订单号的最后6位对账，所以在交易时，传的11域是必须保证当日唯一的。

对账规则:

根据卡号后四位,商家订单号后六位,交易订单号,金额,商户号,终端号; 交易订单号即消费返回的38域信息; 商家订单号即11域流水号; 3).38域数据为做消费撤销使用。 4).对账文件中交易类型说明：（只显示成功状态的交易）

1.pos消费 2.pos消费撤销 8.卡余额查询 32.pos消费冲正 4.银行返回信息

66 银联应答,跟银联和发卡行有关。

60 经查询交易失败，失败原因为未收到银行回调，具体原因请联系银行核实。 5.消费冲正的11域流水要与原消费交易流水相同，否则会因找不到原交易导致冲正失 败。消费冲正只能冲正当天的交易，隔天的都已经结算出去了。（消费冲正里面，好多 域信息都要与原交易一致）；同样的，消费撤销也是只能撤销当天的交易。

6.消费撤销必传38域

授权标志应答码，当作参考号使用，对账的时候也到用到38域。(原先37) 7.传统pos的冲正交易：

消费交易超时，后台会跑批发起冲正交易，冲正成功或者三次冲正失败才会停止。咱们后台用的是批量自动冲正，交易超时时，会往数据库表中增加一条记录，然后在某一特定时间集中到某一方完成的自动冲正）。

8.测试环境中，传统pos是从手刷里包出来的，所以错误码是按照mpos的错误码对照 的。

9.传统pos消费应答55域，mpos不应答。一般情况下，对特殊的IC卡，会校验55/63 域，验证失败就会冲正，但是也要看具体下游是怎么处理的。

6000050000603100311901

传统pos测试环境使用的tpdu

个人问题：1.不要着急问那边要流水号和卡号信息，先搞清楚他那边有没有查到这笔记录，看交易是否到达银行接入平台，后台是否有相对应信息，记得查询信息时要把系统交易时间放开。

2.对于分润、对账这方面自己帮不上忙的，可以说清同事帮忙，有的是结算应该回复的，就不用自己多看(FTP和对账文件可以请刘、盛、高，通道问题和银行返回信息请教高，分润和下件这个问清结算的)。

3.如果出现较多的交易失败，考虑当时的网络和数据库环境，考虑商户录入问题，而不是着急出现日志信息（时刻注意数据库是否连接的上和生产运营后台的使用情况）。

4.对应接口使用文档，注意消费撤销和消费冲正的注意事项，好多的域信息都是要 与原交易对应的，避免出现找不到原交易的情况。

5.养成良好的习惯，切记要看交易报文的tpdu是否对应，还有消息类型是否正确、对应的商端号的位数是否有误、各个域的格式是否正确、必传项是否上送、位图信息是否与域信息相对应等。

6. 1 0001 2 0010 3 0011 7. 4 0100 5 0101 6 0110 8. 7 0111 8 1000 9 1001 9. a 1010 b 1011 c 1100 10. d 1101 e 1110 f 1111

11.对于要补0的域信息，0只是在长度上补了，在取域信息的时候，补位的0不作为域信息处理。

12.常用：：：渠道商户管理==》渠道商户信息管理（商户号、渠道号是否对应）

目前需要改善的

商户交易超过日限额 给一个明确的错误码； 关于升付线上交易显示余额不足的问题：？？？？ 捷付睿通交易成功不出小票的问题：？？？？ 跳商户问题：商户违规被禁；关停交易

对接商户信息

卡联 传统pos 测试环境 A11088Ca 1100100008 15121520