一般为测试环境不稳定的问题，请商户再次发起支付即可。

支付请求时提交报错。通常后面会明确提示来自400主机的报错。请根据提示信息进行相应处理。

参数检查不会检查端口，但因防火墙限制，目前测试环境只允许80、8081、443；生产只支持80端口。

常见的情况：

1、 商户支付接口名填写错误，一网通支付接口名为：PrePayEUserP

2、 客户网络不稳定：网络环境有变化，导致支付过程中客户端IP有变化

会话失效。可能原因：

1、 单次交易操作时间太长（超过30分钟）；

2、 测试环境：系统更新中

3、 客户网络不稳定：网络环境有变化，导致支付过程中客户端IP有变化

MerchantCode内容不正确。

可能原因：

1、 生成校验码的商户密钥与设置的不一样：测试环境填写“”，生产环境由商户自行登陆“商户结账处理系统”进行设置，设置方法见文档《设置商户密钥方法》”

2、 生成校验码时填写的参数与支付接口中填写的相应参数值不一样。

可能原因：

1、 商户支付接口4位分行号+6位商户号字段是否填写错误

2、 该商户不在支付系统的“一网通支付商户白名单中”

支付系统在查询客户协议信息时，后端中间业务平台系统无应答。

联调中多数情况是因为商户在填写协议信息输入参数有误。例如企业银行编号填写不正确。

1、 商户支付接口4位分行号+6位商户号字段是否填写错误

2、 主机没有对该商户进行配置。

3、 察看支付请求地址，确认请求环境是否正确

支付回调不支持域名，只支持ip

支付通知以Get方式发送，请以相应方式获取参数。

可以。通知地址允许http或https开头

系统维护中，请5-10分钟之后再试。

Sdk安全控件密文解密失败。请确认配置的sdk加密公钥是否与环境匹配。

支付通知系统在发送支付通知时，若支付系统未及时收到响应，将重复发送支付结果通知命令，因此商户系统必须相应的能够处理重复通知的情况。

MerchantUrlRetUrl参数填写问题。无法实现自动跳转。可能原因：

1、 MerchantUrlRetUrl参数格式错误

2、 客户端浏览器禁止了跳转

不重复即可，没有其他要求。

不能超过30分钟。因为该参数是在单笔会话中有效的，而一笔支付交易会话的有效时间为30分钟，所以即使是填写了超过30分钟，交易也会随着会话失效而无法继续进行。

测试环境中，商户秘钥统一设置成空字符串，即长度为0的字符串

1、 建议商户APP实现页头导航及返回，如下图中页面左上方的 “<”标志及跟随的动作。用于客户支付过程中返回商户页面。

2、 支付接口中提供MerchantRetUrl和MerchentRetParam参数，用于客户支付成功后返回商户页面。详见《一网通支付开发指南-一网通支付》

定单不是唯一的。

日期+定单号，才是唯一的。一天之内定单号不能重复，但是日期不同，可以用相同的定单号。

定单号长度，为10位数字。如果不足10位，可以在前面补“0”。

遇到这种情况，通常有两种方案解决。

方案1：通过算法映射，让商户定单号和10位数字互相转换

方案2：在定单中，额外增加一个10位数字的“招行定单号”。这样，通过招行10位定单号，也能找到定单。可以通过搜索定单库，完成商户定单号和10位招行定单号互相转换。

可以的。

在支付接口中填写字段“ExpireTimeSpan”。详见《一网通支付开发指南-一网通支付》1.2.5支付接口中的ExpireTimeSpan定义。

ExpireTimeSpan参数表示定单过期时间跨度，单位：分钟。

找开户工作人员索取6位的商户号。这个很长的商户号不是用于网上支付业务的。

1、可以参考例子程序。

如果是Java环境，可以参考商户开发包\示例\java\test.java，里面的testVerifySign()，这段代码是能够验证通过的。

如果用控件版，则可以参考：商户开发包\示例\com\CheckSign.asp

2、常见的错误有：

URL转码导致：例如像“|”符号被转码成“%7C”。由于转码，导致和原来的字符串不同了，就不能通过验证。

目前没有这种情况。

1、 加密会额外增加商户开发的难度

2、 如果商户担心传输信息被他人截获，可以采用https的MerchantURL

异步的。

1、MerchantURL不正确

MerchantURL不是公网的地址。常见于开发阶段的商户，用了内网的URL，所以收不到通知

MerchantURL不正确端口号。测试环境只允许80、8081、443；生产环境只支持80端口。

2、商户收到了通知，但是处理失败。

出现这个现象的原因，是商户处理服务器通知时出错，误以为没有收到。所以值得提醒的是，商户不能假设通知访问是来自客户的浏览器的，处理通知时不要取客户端的信息（如会话信息、浏览器类型等）。

1、拼接过程的错误

需要验签的字符串应该从“Succeed=Y&…”开始，一直到最后包括“Signature=…”在内的整个参数字符串，必须严格的和原始字符串相等，包括参数顺序等，才能通过验证。

最好能够直接获取到原始的字符串内容（QueryString）

2、编码导致。

URL中的“|”字符，在浏览器中会被转码成“%7C”。商户的网站如没有自动处理这个问题，直接把%7C送到API中检验数字签名，会导致验证失败。

3、 其他原因：

Public.Key的路径名不对，或者文件的内容不对。

4、 可以用“签名验证工具”，来检验自己拼接的字符串是否正确。同时也可以对比自己的“签名验证”代码是否正确。

5、可以参考例子程序。

如果是Java环境，可以参考商户开发包\示例\java\test.java，里面的testVerifySign()，这段代码是能够验证通过的。

如果用控件版，则可以参考：商户开发包\示例\com\CheckSign.asp

可能是：

1、商户号，或者分行号错误

2、商户号字段名称错误，比如Name=" Cono "，这种，名称多加了空格

3、少了分行号字段

商户没建好，可能类型不对。请联系开户行处理。

1、事前预防，在定单中增加“商户校验码”。这样确保商户自己的定单不被篡改。具体说明和步骤的可以参考文档《一网通支付开发指南-一网通支付》中的“商户校验码”章节

2、事后检查。即商户在收到成功交易通知后，通过检查定单的各项要素，确保定单没有被篡改。

生成“商户校验码”时，传入参数strGoodsType（商品类型），指定为54010306 （信用卡还款），就可以禁止信用卡支付。

该商户所在分行收单平台交易处理作业没有启动，让收单开发人员启动作业即可。

招行没有开通一网通支付权限，请联系分行业务人员处理。

签名是商户在向银行发送请求报文时，使用商户的私钥对请求报文做签名，银行通过验证商户的签名来确定数据的可靠性，因此商户需要提供商户的公钥给银行；同时银行也会对同步返回的响应报文及主动推送的回调通知进行签名，商户可以使用获取到的银行公钥对响应报文和通知进行验签，以确保数据是来自银行的。

企业证书公钥必须是通用的1024位X.509证书(*.crt或*.cer文件)。可以用java的keytool工具生成，或者用dotnet的MAKECERT工具生成。Keytool生成证书示例如下：

生成私钥：
keytool -genkeypair -alias CMB_FB_KEY -keyalg RSA -keysize 1024 -sigalg SHA256withRSA -validity 3650 -keystore CMB_FB_PRIVATE.jks
参数说明：
-genkeypair：生成一对非对称密钥;
-alias：指定密钥对的别名;
-keyalg：指定加密算法，必须采用RAS加密算法;
-keysize 指定密钥位数，本系统必须是1024位；
-sigalg 签名算法；
-validity 密钥有效期，单位为“天”；
-keystore:密钥库的路径及名称
生成公钥：
keytool -export -alias CMB_FB_KEY -keystore CMB_FB_PRIVATE.jks -rfc -file CMB_FB_PUBLIC.crt
     参数说明：
     -rfc：将证书导出为文本，不输这个参数则生成二进制证书；
     -file 导出证书文件；

通讯报文对字段顺序没有要求，但是对于注明必须填入的字段不能为空。

签名原文中字段的顺序必须严格按照文档说明来，而且字段的内容也必须按照文档说明来，不能添加或减少字段。另外请注意区分对请求报文的签名原文与返回报文的签名原文。

请求报文里的SIGDAT字段应该是使用私钥对签名原文做签名后再做BASE64编码得到的数据，而不是直接对签名原文做BASE64编码，另外签名原文里的各个字段的值应该与请求报文里对应字段的值完全一致。如果以上步骤都正确，则请检查签名用的私钥与提供给银行的公钥是否是一对，还有上传的公钥证书的格式是否严格符合银行要求（上传的证书必须是通用的1024位X.509证书）。

SIGTIM字段的格式不对，该字段格式应为：yyyyMMddHHmmssffff。

当前服务器时间与客户签名时间的时间间隔不能超过一个小时。请检查SIGTIM字段的内容与当前北京时间是否相差过大。

当商户在一定时间内多次发送错误报文时会被短暂列入黑名单，这个限制会在一定时间后被解除。

会重发。第一次发送失败后，10秒后发送第二次，如果第二次发送失败，则30秒后发送第三次，以此类推，每次重发的间隔时间会比上次长，最多发送10次。

不相同。

请求报文的大小控制在2000000Byte以内，大概不到2M。响应报文的长度暂不做控制。

请求报文的数据应放在RequestData参数中传递。例如如果使用HttpClient实现POST，则创建参数队列的代码为：

List<NameValuePair> formparams = new ArrayList<NameValuePair>();

formparams.add(new BasicNameValuePair("RequestData", PKG));//PKG为请求报文体；

如果使用HttpURLConnection实现POST，则需在请求报文前添加"RequestData="。

商户接入平台与业务系统通讯失败，可能是业务系统正在升级维护，请稍后再试。

商户校验码内的客户协议号、协议商户企业网银编号、协议开通请求流水号无法被识别引起。可能的原因有：

客户协议号、协议商户企业网银编号、协议开通请求流水号填写有误；

商户校验码生成有误，导致客户协议号、协议商户企业网银编号、协议开通请求流水号无法被识别

卡片状态不正确

检查商户参数设置问题，是否存在中文字符或特殊字符

不行,PC上安全键盘调用不了

生产的密码键盘公钥上送前才会给商户，由朱楠辉生成，余立东发给商户。

招行的H5页面没有返回商户App的功能。商户一定要实现，有接口文档中所述的两种方式：

1. 接口参数的MerchantRetUrl字段，提供一个URL，这个Url收到请求后触发App返回。

2. 商户App可以通过查询内部收到的“支付通知结果”，和查询我行提供的主动支付单笔订单接口来确定支付状态，从而触发App返回。

商户查询的订单状态应该是商户端的订单状态，我行查询订单状态确定已成功。因商户端对招行返回的支付回调处理有问题

商户第一次送的协议号与第二次送的协议号不一样，所以会调出签约界面，是商户上送客户协议号的规则存在问题。商户必须对协议号进行管理。

目前我行没有对iPad支持

一网通支付只是个网页，商户是APP， APP包括了该网页，顶上就可以加返回了。

校验码里面有包含客户协议号字段，商户不送就打开不了支付页面，相当于是强制了校验码功能

可能是商户方的APP对嵌入页面的js调用有限制

注册32位控件时，注册路径有误，32位需要放到sysWOW64文件里

64位系统的电脑注册的需要32位和64位控件分别注册，商户可能只注册了64位控件，没有注册32位控件

1、测试环境目前只支持端口为80、8081、443的IP地址进行回调

2、测试环境不支持HTTPS

3、签约回调POST方式、支付回调GET方式

请用招行提供的cmbB2B.jar中的base64编码函数对报文重新进行编码。

查询协议的签名原文格式是NTBNBR=?&TRSCOD=?&COMMID=?&RETCOD=?&SIGTIM=?&BUSDAT=?，查询协议的响应报文是有RETCOD的，支付请求报文和回调通知没有，需要区分一下。另外测试环境的企业网银公钥和生产环境是不一样的。

商户需检查签名时的私钥密码是否正确

C#建议使用控件版，dll版不建议使用。

一般是我行防火墙对商户提供的URL进行了拦截，商户可通过http://tool.chinaz.com/tools/urlencode.aspx验证一下是否有多重编码。如果有，请取消多重编码，取消后还不能成功请联系我们处理。

必须按照招行回调给商户支付成功的数据顺序，不可变动。

创建商户时出错，找不到终端。请联系招行一网通支付技术支持小组人员处理。

同一笔定单号发了多笔交易，请商户用新定单号交易，一个定单号只支持一笔交易。

一网通支付，只有用户支付额度和商户授权额度，没有单独针对银行卡的支付额度

目前普通商户，用户单笔支付金额上限和当日累计金额限制为：2000元，后续风控将把限额提升到5000元。

不同类型的商户，支付额度不同。

每次输入相同的参数计算结果是不一样的，无法单独核对效验码是否正确，只能通过你提交支付请求系统验证。

商户有一个账号用过这张卡了，然后换了个账号还是用这张卡，触发风控，交易被拒绝。请换一张银行卡支付。

商户有一个账号用过这张卡了，然后换了个账号还是用这张卡，触发风控，交易被拒绝。请换一张银行卡支付。

我们没有同步通知，只有异步通知。MerchantUrl后面传支付成功的值，MerchantRetUrl用于跳转到商户的页面。

取消协议和查询协议看商户的客户有没有解绑协议和查询协议的场景，如果有，商户要开发这个接口；

银行端主动取消协议接口也不做要求，主要看商户有没有这个场景需求。

主动支付的支付密钥，由商户自行在招行“网上商户结账处理”系统中生成并导入。配置方法：商户以系统管理员用户，登录我行商户结账管理平台，生成并导入支付密钥。

可能是未知原因导致异步回调有延迟，可查明原因后重试。建议用单笔订单辅助查询。

商户APP前端必须集成密码键盘SDK，配置好密码键盘公钥，实现一网通支付功能。

请严格按照我们提供的顺序组织签名原文。原文正确方式是：NTBNBR=?&TRSCOD=?&COMMID=?&RETCOD=?&SIGTIM=?&BUSDAT=?

附录：常见错误码

附录：协议相关常见错误码