附录C.常见问题汇总

常见问题汇总

一、常见报错问题

1.1. 找不到客户产品配置的业务信息

检查是否有开通对应的产品或商户是否用错交易代码，比如开通了批量代付产品而商户调用了单笔代付，如未开通产品联系运营配置。(配置完不要马上发起交易，有缓存）

1.2. 未开通的业务类型/业务类型与商户信息中设置的业务类型不一致

检查上送的业务类型（BUSINESS_CODE）是否与配置的一致。

在产品配置-》业务参数进行查看。(配置完不要马上发起交易，有缓存）

1.3 未配置分账商户号，请检查

分账交易的分账收款方需在交易发起的商户号下做关联配置，其他参数-》分账配置

(配置完不要马上发起交易，有缓存）

1.4. 权限不足

• 检查上送的用户名是否与商户签名的私钥证书名称一致，一般用户名是商户号+04。

• 找总部运营确认下是否开通了04用户的系统对接角色权限，比如交易类要开通系统对接（交易/查询/账务）权限，验证和签约类要开通系统对接（验证）权限；如对应的角色缺少权限则联系总部运营添加。

• 检查上送的接口地址是否正确，比如是否用生产的参数发到了测试的地址。

1.5. 签名不符

• （1）排查商户生成的私钥和在通联系统上传的公钥是否是一对，如不是可在对应角色更新公钥。

• （2）排查是否在生产环境中使用了测试环境的私钥证书，这种情况，只需要替换成生产的私钥证书即可；

• （3）测试环境联调的时候，证书正确，用户名正确，但是还是前面失败，则考虑是签名的方法有问题，签名算法：SHA1withRSA，编码格式GBK，签名的内容是整个报文串除了 <SIGNED_MSG> </SIGNED_MSG>；请商户技术自行检查，或参考该文档的数字签名域；

• （4）检查接口地址与参数是否一致，比如是否用生产的商户的私钥证书加签发到了测试环境；

• （5）证书上传到后，要5分钟之后才生效

1.6. 目前未开通此受理渠道

• 生产的相应产品下的受理渠道没有配置，联系运营配置：接口对接方式需配置XML系统对接受理渠道；手工报盘方式需配置浏览器受理渠道。

1.7.卡号所属银行与发卡行不一致

上送的银行代码有误，或银行代码未做映射导致系统无法匹配，联系运营排查，以下举例：

a. 银行-》行号管理-》银行卡BIN维护页面通过卡号或卡bin查询 该卡BIN对应的 银联机构代码:14097310

b.检查该银联机构代码是否有映射对应的银行代码，以下该图是已经做了映射的，如无映射则联系运营在该处映射对应的银行代码，否则当商户上传04027310的银行代码会报错卡号所属银行与发卡行不一致

1.8.返回码：3012，响应信息：不允许进行对公交易

该报错原因是风控拦截，说明在交易发起时对公的风控没配置或有修改过风控未生效则马上发起交易。

该情况请联系运营人员检查风控配置和产品配置里的对公对私配置，如确认都无问题再重新发起交易。

咨询运营是否支持该银行的对公

1.9.商户收款对公户信息不存在

批量代付/实时代付报错“商户收款对公户信息不存在”，检查银行结算账户的账户用途是否为“收付款”，如果仅为收款会报该错。

1.10 账号属性超长

检查手工提交的模版，账户类型的值是否填错，比如0私人是否填成了00.

1.11.测试环境不发短信验证码，默认123456

测试环境修改密码的短信验证和上传公钥不发短信验证码，默认是123456，需先点击获取验证码。

该情况请联系运营人员检查商户级风控：客户-》风控参数管理-》交易控制管理是否配置允许对公，以及检查产品配置里的对公对私配置是否支持全部，如确认都无问题再重新发起交易。

1.12 交易报错付款方商户未注册，触发限额

商户未报备成功，在收付通页面查看对应的报备情况，渠道管理-》渠道商户号管理-》渠道报备查询

银联报备当天报备成功的，第二天才生效。

1.13 当日通兑业务累计金额超过规定金额

如检查未超过通联设置的风控参数，则可能是该卡当日的扣款金额已超限。

1.14 不允许进行对公交易

该报错原因是风控拦截，说明在交易发起时对公的风控没配置或有修改过风控未生效则马上发起交易。

该情况请联系运营人员检查商户级风控：客户-》风控参数管理-》交易控制管理是否配置允许对公，以及检查产品配置里的对公对私配置是否支持全部，如确认都无问题再重新发起交易。

1.15 3066 不支持对公

1.16 找不到商户**to**授权信息

联系运营，配置商户号之间的内部转账授权配置

1.17 退款接口报 1000 未开通此交易

退款的原交易属于哪个产品，去对应的产品的退款参数配置配置允许退款

1.18 退款报3999 退款账务处理失败

有以下原因：

1 收款户余额不足，不够资金退款

2 如余额充足，则可能是收款户被冻结，可联系运营确认

1.19 付款类交易报3008 余额不足

有以下原因：

1 检查余额是否充足（减去手续费的情况）

2 检查入账（充值交易）时间是否在发起代付交易之前

3 检查账户余额是否被冻结了

1.20 结算交易报错“客户代码未注册[38202000236]”

259 号文，银联结算交易管控，需要重新触发银联代付报备，重新报备后，一般d1生效。

二、交易问题排查

2.1. 渠道不支持，渠道原因：卡号未签约

问题：卡号做过了签约，但是却返回渠道不支持，卡号未签约

排查思路：1、是否有配置符合的路由渠道，比如该卡签约的协议类型是网联，是否有配置网联渠道；2、是否有签约以及签约完成时间是否先于扣款提交时间；3、扣款户名和签约户名是否一致，路由匹配时会检验

先通过系统-》其他参数-》交易诊断，判断是否有符合条件的路由渠道以及匹配不上的原因。

第一个例子：签约和扣款的户名不一致的情况

1）以文件序号：7204500281238793，记录序号0020为例， 签约时间：2021-01-11 10:10，快捷扣款时间2021-01-11 10:15，该交易返回渠道不支持，渠道原因是卡号未签约。

2）从交易诊断可以看出有配置网联渠道XX-NUCC，且有成功签约，协议类型是网联，签约时间也在扣款时间前，排除1和2。签约的户名是：涂*鑫，而扣款的户名是凃*鑫，两者不一致因此导致路由匹配失败。

第二个例子：没有符合的路由渠道，签约走网联，而路由只配置了银联渠道

1）以文件序号：7194457841659968，记录序号00005为例，快捷扣款时间：2020-12-16 10:44，该交易返回渠道不支持，渠道原因是卡号未签约

2）从交易诊断可以看出没有配置网联渠道，配置了银联渠道881029，但该签约协议类型是网联，银联渠道要求银联类型的协议，因此路由匹配不了，需要配置符合条件的渠道。

2.2. 协议号未找到或失效

返回3043 协议号未找到或失效分两种情况：

1、一种是该卡的银行协议在发起交易前在我司系统已失效，该情况不会入库，页面查询不到记录；

先在用户协议管理-》快捷协议查询页面查询该卡号是否有对应的通联协议号，且银行协议状态是否正常。

2、一种该卡的银行协议在发起交易前在我司系统仍是正常状态，但发到渠道后返回失效，该情况有入库，页面可以查询到交易记录，该原因可能是本身持卡人自己解约了，银行协议已失效，但银行可能没有通知到通联，因此通联端的协议状态仍是正常，在发起交易后根据3043返回码自动触发置银行协议失效，持卡人需要重新发到渠道签约才能扣款。

2、检查交易上送的姓名是否跟签约的姓名一致

2.3.汇入金产品打款后，交易明细查询中没生成汇入金交易

A、检查网银打款的收款人信息是否正确

帐号：1200+15位商户号（12表示通联通，00表示汇入金业务，前四位确定平台和业务类型，商户号不足15位前面补0）+8位自定义（可空）

户名：商户名称

开户行：通联支付-备付金账户

B、检查商户是否开通了汇入金产品，并且业务类型已默认选择了 代收其它 19900。

C、找业管查询ACS网银明细是否收到汇入交易

D、如果上面ABC三步检查都没问题，则再联系技术进一步排查。

E、如果第C步网银明细查询到有记录，但因为第B步的产品或业务类型没配置正确，导致没生成交易，请与业管协商退款。

2.4.同持卡人在某个商户的快捷支付某个时间前返回协议无效失败，某个时间后又成功了。

A、通联处理逻辑说明

快捷协议为三方协议：持卡人+支付机构+银行；

同一持卡人在通联会存在两种协议，银行端协议号与通联端协议号，通联协议号规则为，商户号 + 卡号，确定唯一，只要卡号不变，重签返回的协议号也一样，我们返回给商户的是通联端协议号，如果同一持卡人在通联存在多个商户，则给每个商户返回的协议号都是不同的，但都对应相同的银行端协议；

持卡人首次在通联签约时，会创建银行端协议与通联端协议，并且签约短信由银行触发，通过其他商户进行非首次签约，则只会建立商户端协议，并且短信由通联触发；

当持卡人通过银行端进行了解约，通联收到银行端的解约通知后，会将银行端协议置为无效，但商户端协议仍保持为有效状态。如果此时发起了交易，通联会根据渠道返回的协议无效错误码，同时将该商户的协议置为无效（如果银行没有返回协议无效的返回码，而只是返回协议无效的提示内容，则通联不会自动更新商户的协议状态为无效）。

B、问题表现：商户下的某个卡号，某天扣款返回协议号失败，之后某天扣款又返回扣款成功，并且该持卡人在该商户没有做过解约与重签。

C、问题原因：持卡人在银行端解约后，通联收到银行的解约通知，此时通联的银行协议状态已置为无效，但商户的通联协议状态仍为有效。商户A的持卡人在该银行端协议解约之后发起交易，则返回协议无效。后来商户B对该持卡人发起了签约，那么商户A的持卡人之后重新发起了扣款，则可以成功。

D、举例排查：以如下某一商户某一持卡人6月份协议支付扣款返回协议无效，7月份扣款成功，并且该持卡人没做过解约与重签，为例子：将卡号发给运营，通过签约-用户协议管理-银行快捷协议查询，查询该卡的银行协议更新时间，以及对应商户端协议的生效时间。

三、其他问题说明

3.1. 调试过程中的返回信息为 *** cannot be cast to **

• 看接口文档，检查请求报文的格式标签对不对。

3.2. 简单对账文件下载得到空文件

• 检查请求参数的格式是否正确，签名字段值是否正确；

3.3. 如何生成perm文件？通过p12文件或者cer文件转换成perm文件

• 生成私钥

openssl genrsa -out rsa_private_key.pem 1024

• 生成公钥

openssl rsa -in rsa_private_key.pem -pubout -out rsa_public_key.pem

• 生成例子：

• 转换私钥

openssl pkcs12 -nocerts -nodes -in 20060400000044502.p12 -out 20060400000044502.pem

• 转换的时候，密码是：111111

• 转换公钥(或证书)

openssl x509 -inform DER -in allinpay-pds.cer -out allinpay-pds.pem

3.4. 接口并发为tps20，如果超过，我们会拒绝请求。

3.5. 交易请求报http通讯异常的，要发起交易查询，查询该笔交易是否正常处理。

3.6 关于4000 已发送银行返回码的说明

• 代付交易返回 4000 已发送银行返回码的缘由：批量付款，走跨行付款的时候，由于无法直接查询交易的结果，故该笔交易状态为“已发送银行”，这种情况在网银转账的时候，也比较常见，比如：持卡人登录招行的网银，做一笔跨行的转账，转账到某某城市商业银行，操作完毕后，此时，网银也是告诉持卡人，转账成功,但是事实上钱是还没有付到转入方账号上的。

• 而由于网银系统无法马上得知付款最终结果，需要等待网银入账时，才可以判断原交易是否付款成功，故一般做法，都是把“已发送银行”认为是交易成功，并直接提示给客户是交易成功假如最终付款失败，那么在网银明细里面会显示哪笔付款失败。

• 商户系统应该如何考虑该问题？

• ——可以直接把4000当做成功,与0000同样看待。如果最终发生了退票（2-5天，时间不定看具体银行），则运营人员根据网银明细对账后会手工发起退票，商户再根据退票交易更新交易状态。

• 发生退票后，原交易订单的返回码仍是4000已发送银行不会变，为了方便在后台查看明细是否有退票，目前会把发送退票的交易状态页面改成了银行退票，但实际通过接口查询该交易和对账文件显示的的返回码不会再调整。

• 商户也可以配置退票通知：人工触发退票之后，通联系统会往原先配置好的商户通知地址，发起退票通知，通知信息包含了原付款交易的流水号，商户可根据此流水号得知哪笔付款交易产生了退票，也就是付款失败。

3.7 对外的出口ip

测试环境 101.95.191.142 、116.228.64.49、140.207.168.194

生产环境 140.206.57.166 、117.184.121.6 、222.72.143.68 、222.72.143.69、140.206.57.164 、101.95.129.116 117.184.121.4  、210.22.100.126 、220.248.8.94

3.8 https 403报错

错误除了我们那个下载的接口可能是ng拦截的，其他都是触发了安全室那边的协议。要到商户的出口地址以及请求接口和请求时间，联系数据中心。

3.9 签约通知310006 返回全卡号和手机号的配置

3.10 关于请求报文version版本号上传值不同，返回报文格式不同的说明

version 上传06版本，接口100011 310011 100014 REFUND 200004返回报文字段新增 VOUCHERNO。

version 上传08版本的，接口100011 310011 100014 返回新增字段VOUCHERNO ，SETTLE_DAY的值为交易的完成时间。