工商银行银企互联系统企业开发手册

工商银行银企互联系统

企业开发手册

Company number：【00WT-88YT-W8CCB-BUUT-202108】

企业开发手册

1. 文档属性 文档属性 文档名称 文档版本号 文档状态 文档编写完成日期 作者 2. 文档变更历史清单 文档版本号 A0 A1 变更日期 2011-11-21 2012-4-10 修改人 高小伟 高小伟 备注 给文档加了首页，版本号，作者等信息。 ”企业接收交易响应数据过程””企业接收交易响应数据过程” 对于推广版交易来说，企业收到的同步返回包，Base解码后就是明文，不需要验签。 增加了第8章交易规则 修正签名验签接口用例中的内容 补充了“第9章大批量指令提交” 内容 中国工商银行银企互联系统企业开发手册 A3 正式稿 2012-11-1 高小伟（北京开发三部），丁孚旌（北京开发三部） A2 A3 A4 2012-9-5 2012-11-1 2013--7-31 高小伟 丁孚旌 高小伟 3. 本次修改变更说明 序号 1. 2. 3. 4. 5. 目录

变更内容简述 第9章：增加了大批量提交接口“人事发工资指令提交”

概述

银企互联面向大的集团客户，提供与企业ERP系统直连的平台，为工行的现金管理服务提供多渠道和客户化支持。

企业ERP系统通过HTTPS协议与工行系统进行连接并向银企互联前置发送数据，数据的接口格式使用标准的xml数据格式，但双方通讯的过程中则需要遵守下文描述的规定。银企互联前置接到企业数据后进行一系列的检查后完成交易，并将处理结果以企业便于处理的形式返回给企业。

在安全保证方面，通讯层的安全保证是HTTPS协议。

企业如需使用银企互联系统，要办理有关注册手续，并审领证书。 企业进行结算类交易时，如果涉及到授权过程，企业需要在企业网银系统中完成相关授权动作。银企互联系统将企业提交的支付指令或者授权成功后的指令当作最终转账指令，根据提交指令的证书ID检查收付方帐号等合法性，以保证所提交指令在权限允许范围内进行操作。

总体方案介绍

总体网络结构图

上图企业ERP系统1采用的是非NC方式接入的客户；企业ERP系统2采用的是NC方式接入的客户； 企业端安全服务器简介 此服务器只对使用NC方式接入的客户有效。企业端安全服务器被称为 NetSafeClient。它有两个可以配置的端口分别用于加密和签名／验签服务，如交易请求包 交易请求包 加密 交易请求包 下图所示（假设１为加密端口，２为签名／验签端口）。 加密 NetsafeClient 交易返回包 6、http交易返回包 交易返回包 NetsafeClient 交易返回包 1.签名请求包 签名 具体使用时，企业应用向工行提交交易请求时，可以依照http协议向2.签名结果 结算类查询类NetSafeClient的端口１发送请求。接到请求后，NetSafeClient使用企业证书将http请求包转换成https请求包发往工行端服务器(如上图“查询类”)；如果需要对某些交易数据进行签名，则企业应用需要与签名端口建立Socket连接并将待签名数据发往端口２，然后接收端口２的签名结果，之后再将包含签名信息的交易请求发往端口１而完成整个交易请求过程(如上图“结算类”)。

对签名还是验签名请求的区分则是通过http包头来进行。Content-Type:INFOSEC_SIGN/和Content-Type:INFOSEC_VERIFY_SIGN/分别用于标识签名请求和验签名请求，而Content-Type:INFOSEC_SIGN_RESULT/和Content-Type:INFOSEC_VERIFY_SIGN_RESULT/分别用于标识签名和验签名的返回结果。

为方便起见，可以将NetSafeClient的两个服务端口逻辑地称为两台服务器，NetSafeClient的加密服务器和签名服务器。

安全控制介绍

对于NC方式接入的客户

✓

企业向工行提交的交易数据，必须通过企业方的NetSafeClient进行与工行服务器的连接，接口确定需要签名的数据也必须由NetSafeClient的签名服务器签名后组成规定的数据包格式后，通过NetSafeClient提交工行，这样可以保证企业数据以及相关信息不被恶意篡改。 ✓

数据全部由NetSafeClient负责转发，使NetSafeClient成为架设在企业现场的工行接入服务器。而企业与工行之间安全的连接，由NetSafeClient和工行安全代理服务器NetSafe保证； ✓

工行接收到企业提交过来的部分关键交易数据后，需要解密并验证企业的数字签名，以防止第三方假冒企业的行为。

对于非NC方式接入的客户

✓

企业向工行提交交易数据时的安全控制

企业ERP与银企互联系统之间使用HTTPS协议通讯。

企业可以选择是否对交易数据进行对称加密，目前系统支持的算法有DES与3DES。进行对称加密可以防止第三方截获交易的信息。而加密中需要用到的密钥由企业与工行共同约定。（加密功能暂不支持） 企业需要对其发送的指令数据进行数字签名，签名中使用的证书可以是企业证书也可以是工行证书，其中签名使用的算法是

SHA1withRSA。进行数字签名可以防止第三方假冒企业的行为。 ✓

工行向企业发送结果信息时的安全控制

企业ERP与银企互联系统之间使用HTTPS协议通讯。 企业可选择是否对返回数据进行对称加密，方法与上文相同。 工行对部分关键交易返回信息进行数字签名。

重点说明

➢ xml格式要支持业界公认的标准格式，例如：等同于

；上送数据格式尽量简单，避免使用CDData等文本格式。 ➢ 所有的交易请求包中“包序列ID”。在一个企业代码下当日包序列ID必须唯一。工行处理完毕之后将该字段原值返回，即所有的交易返回包中“包序列ID”字段（PackageID）。

➢ 转帐交易请求包中“签名时间”字段（SignTime），格式为yyyyMMddHHmm“签名时间字段”并重新签名。

➢ 所有请求包和返回包中备用字段的使用主要是出于对今后扩展的考虑，如果以后需要增加企业上送的项目或者返回给企业的信息，不必再改变交易包格式。目前对企业请求包来说这些备用字段的值可以送空；企业对银行返回包中的备用字段也不必作处理。请求包中的备用字段标签为“ReqReserved*”，返回包中的备用字段标签为“RepReserved*”（其中*为1、2、3或4，详见接口说明文档）。

➢ 查询历史明细返回数据包中交易时间（）数值如为空，则说明该笔指令是银行的计息交易明细。

➢ 支付查询指令接口，方便企业对可疑、有疑问（如网络中断，交易长时间没有返回等）或处理完毕的转帐指令进行查询。企业提交要查询的结算请求的包序列ID，工行返回该笔转帐指令的基本信息和状态。

➢ 本接口说明中所有涉及金额的字段都是以分为单位（不带小数点）。 ➢ 如企业系统需要代理汇兑功能则企业应用需同步开发网点信息下载交易，以便为代理汇兑交易中收方为它行情况时提供工行网点名称。否则，无需开发网点信息下载交易。

➢ 在网点信息下载功能中，由于下载数据过大且数据不会经常更新，所以此交易控制了企业每日下载次数。目前暂定次数为每日2次。 ➢ 个人联名卡签权指令只支持币种是人民币的账号/卡号。 ➢ 企业端传输数据时，指定xml编码方式为GBK。

➢ 银企互联提交包中包含“签名时间（yyyyMMddHHmmssSSS）”此标签的，说明该交易需要进行签名处理。

➢ 企业端的程序需要对银行返回的数据有可扩展性，以便适应今后业务的不断发展。

➢ 银企互联系统支持两种接入方式，客户可以任何选择一种。第一种：使用第三方NC软件方式接入银企互联系统；第二种：使用非NC方式企业直接接入银企互联系统；

➢ 一些接口中，返回包分文件级返回包和指令级返回包两种。文件级返回包是作为客户请求的响应信息同步返回的。而指令级返回包是银行主动发起的异步返回信息，表示指令处理的结果，指令级返回包首先会返回整批指令的处理结果，然后对于其中指令状态非最终状态（成功和失败）的指令，银行会实时更新每一条指令的状态，然后再每条分别以指令级返回包的格式返回给客户。

➢ 建议客户使用HTTP/协议。HTTP/及其以下协议版本可能无法正常发送指令到银行端。

下面将区分两类客户分别对接入方式等相关信息进行说明。

银企互联——NC方式接入客户

企业端系统环境要求 软件环境

对企业的ERP系统无要求；

工行企业端证书服务器软件NetSafeClient需安装在一台PC机上。 网络环境

企业财务系统通过局域网与工商银行提供的NetSafeClient连接；

企业端的NetSafeClient可以通过专线或INTERNET与中国工商银行银企互联系统互联。

企业开发过程描述 企业提交交易请求数据过程

企业提交的交易分为两大类：查询类和结算类（需要进行签名处

理）。

1、查询类：

（1） 企业按照工行提供的xml包格式进行打包，在局域网内通过

http协议以POST方式将交易包发送到NetSafeClient的安全http协议服务器。

http请求格式：action=”客户端NetSafeClient的地址和加密端口号/servlet/ICBCCMPAPIReqServletuserID=证书ID&PackageID=包序列ID&SendTime=请求时间” http请求包头信息：Content-Type应为application/x-www-form-urlencoded

请求数据格式（post方式）：Version=版本号TransCode=交易代码（区分交易类型，每个交易固定)&BankCode=客户的归属单位&GroupCIS=客户的归属编码&ID=客户的证书ID（无证书客户可空)&PackageID=客户的指令包序列号（由客户ERP系统产生，不可重复)&Cert=客户的证书公钥信息（进行BASE编码；NC客户送空)&reqData=客户的xml请求数据(需要URLEN)

其中：包序列ID、证书ID应根据实际情况进行更改，请求时间为企业发出该交易请求包的当前系统时间。post方式最后不允许有回车等其他乱字符，TransCode交易名称应与xml包内标签中的值一致，action中的证书ID、PackageID与请求数据格式中的证书ID、PackageID、xml包中的证书ID、PackageID的值三者相一致。

（2） NetSafeClient将xml包加密后按照https协议，通过互联网/

专线发送到银行端的NetSafeServer。（本步由NetSafeClient完成，企业无需处理）；

（3） NetSafeServer将交易请求送银企互联系统进行处理。 企业

（1NetSafeClient （2NetSafeServer （3工行

2、结算类：

（1） 企业按照工行提供的xml包格式进行打包，在局域网内与

NetSafeClient的签名端口建立Socket连接，通过此连接向签名端口发送http数据包。http包头中需包含“Content-Length”和“Content-Type”两个属性。其中“Content-Length:”后面是需要签名的二进制数据包的长度，“Content-Type:”后面是需要签名的标记，为INFOSEC_SIGN/。（注意大小写） http请求格式：action=””

请求数据格式：结算类请求提交的xml包

NetSafeClient对xml包进行签名后，通过http协议将签名结果返回给企业系统。如签名成功标签与标签之间的部分为签名结果。

NetSafeClient返回的签名包如下：

0

MIIIXAYJKovcNAQcCo………….0BlLdSgw=

（2） 企业按照工行提供的xml包格式进行打包，在局域网内通过

http协议以POST方式将交易包发送到NetSafeClient的安全http协议服务器。

http请求格式：action=”客户端NetSafeClient的地址和加密端口号/servlet/ICBCCMPAPIReqServletuserID=证书ID&PackageID=包序列ID&SendTime=请求时间”

请求数据格式（post方式）：Version=版本号TransCode=交易代码（区分交易类型，每个交易固定)&BankCode=客户的归属单位&GroupCIS=客户的归属编码&ID=客户的证书ID（无证书客户可空)&PackageID=客户的指令包序列号（由客户ERP系统产生，不可重复)&Cert=客户的证书公钥信息（进行BASE编码；NC客户送空)&reqData=签名后的客户请求数据(需要URLEncode，判断方法是查看发送数据中是否有“+”，如果存在说明没有做URLEncode)

其中：包序列ID、证书ID应根据实际情况进行更改，请求时间为企业发出该交易请求包的当前系统时间。post方式最后不允许有回车等其他乱字符，TransCode交易名称应与xml包内标签中的值一致，action中的证书ID、PackageID与请求数据格式中的证书ID、PackageID、xml包中的证书ID、PackageID的值三者相一致。

（3） NetSafeClient将企业送来的签名包加密后按照https协议，通

过互联网/专线发送到工行端的NetSafeServer，再发往工行

网银进行处理。（本步由NetSafeClient完成，企业无需处理）。

（1企业 （2（3NetSafeClient （4NetSafeServer NC提交参考范例：

NCExample.java

企业接收交易响应数据过程

企业接收到数据包的格式：reqData=交易返回包或errorCode=错误代码 步骤：

判断返回数据中是否是errorCode：

（1）如果是：根据错误代码做相应处理，结束。错误代码的含义参见接口说明文档中的附录。

（2）如果否：

企业接收到数据包的格式：reqData=交易结果包；企业根据先进行BASE解码，签名返回包按照格式拆分出明文和密文，验签正确后对明文得到明文后，按工行提供的xml包格式进行解包。对于单笔提交类指令（即存在文件级返回包的指令），返回的xml包格式按照指令级返回包格式来处理，多笔则按照文件级返回包格式来处理。 企业接收银行主动返回过程

http请求格式：action=”客户ERP服务器的地址和端口号”

请求数据格式（post方式）：Version=版本号TransCode=交易代码（区分交易类型，每个交易固定)&BankCode=客户的归属单位&GroupCIS=客户的归属编码&ID=客户的证书ID（无证书客户可空)&PackageID=客户的指令包序列号（由客户ERP系统产生，不可重复)&reqData=银行主动返回给客户的xml请求数据 reqData数据格式： 如果需要签名，格式为：

数字字符串：长度10位，代表明文数据长度，不足10位左补0；

明文：xml明文，长度可变，需要上面的数据指明，双字节字符（汉字）算作1位长度； 分隔符：ICBCCMP；

密文：明文经过签名后的数据并做BASE编码； 如果不需要签名，则直接送xml明文；

以上数据经过拼接后，再进行BASE编码（仅reqData项）得到最终的reqData数据。

按照以上格式将请求数据发送到企业；此格式返回的数据是不经过NC的，是银行直接发给企业的ERP系统；如有使用，企业需要在内管注册或者修改集团信息时填入企业用于接收银行反馈的地址，标准格式是

报文版本号说明

当存量接口无法满足客户需求且无备用字段可扩充时，进行接口版本号的升级。升级后的接口保持TransCode不变，Version提升，使用新接口的客户，请求报文应与相应版本的报文格式保持一致。同时，要求使用新版本的客户系统按照自动扩展解析方式调用开发。即：企业客户根据银企互联接口数据返回包定义的“是否可选”标记来判断解析原则，如果标志为“否”的，需要

客户系统校验标签节点，如果为“是”的，客户系统可根据自身需求决定是否拓展。

银企互联——非NC方式接入客户

企业端系统环境要求 软件环境

对企业的ERP系统无要求； 网络环境

企业财务系统可以通过专线与中国工商银行银企互联系统互联。 企业开发过程描述 企业提交交易请求数据过程

（1） 企业按照工行提供的xml包格式进行打包，在局域网内通过

http协议以POST方式将交易包发送到银行前置机。 http请求格式：action=，每个交易固定)&BankCode=客户的归属单位&GroupCIS=客户的归属编码&ID=客户的证书ID（无证书客户可空)&PackageID=客户的指令包序列号（由客户ERP系统产生，不可重复)&Cert=客户的证书公钥信息（进行BASE编码)&reqData=客户的xml请求数据 其中：包序列ID、证书ID应根据实际情况进行更改，请求时间为企业发出该交易请求包的当前系统时间。post方式最后不允许有回车等其他乱字符，TransCode交易名称应与xml包内标签中的值一致，action中的证书ID、PackageID与请求数据格式中的证书ID、PackageID、xml包中的证书ID、PackageID的值三者相一致。

reqData数据格式： 如果需要签名：

数字字符串：长度10位，代表明文数据长度，不足10位左补0；

明文：xml明文，长度可变，需要上面的数据指明，双字节字符（汉字）算作1位长度； 分隔符：ICBCCMP；

密文：明文经过签名后的数据并做BASE编码； 如果不需要签名，则直接送xml明文；

以上数据经过拼接后，再进行BASE编码得到最终的reqData数据。

以上每项请求参数的值（全部参数项）均应做一次URLEncode编码，然后按照以上格式将请求数据发送到工行；

企业接收交易响应数据过程

企业接收到数据包的格式：reqData=交易返回包或errorCode=错误代码 reqData=交易返回包结构：

如果交易返回包进行了签名，则结构为：

数字字符串：长度10位，代表明文数据长度，不足10位左补0； 明文：长度可变，需要上面的数据指明，双字节字符（汉字）算作1位长度； 分隔符：ICBCCMP；

密文：明文经过签名后的数据；

如果交易返回包没有签名，则结构为：明文； 不论是否签名，交易返回包均进行了BASE编码；

步骤：

判断返回数据中是否是“errorCode=”打头：

（1）如果是：根据错误代码做相应处理，结束。错误代码的含义参见接口说明文档中的附录。 （2）如果否：

企业接收到数据包的格式：reqData=交易结果包

企业根据先进行BASE解码，签名返回包按照格式拆分出明文和密文，验签正确后对明文，得到明文，然后按工行提供的xml包格式进行解包。对于单笔提交类指令（即存在文件级返回包的指令），返回的xml包格式按照指令级返回包格式来处理，多笔则按照文件级返回包格式来处理。 企业接收银行主动返回过程

http请求格式：action=”，每个交易固定)&BankCode=客户的归属单位&GroupCIS=客户的归属编码&ID=客户的证书ID（无证书客户可空)&PackageID=客户的指令包序列号（由客户ERP系统产生，不可重复)&reqData=银行主动返回给客户的xml请求数据 reqData数据格式： 如果需要签名，格式为：

数字字符串：长度10位，代表明文数据长度，不足10位左补0；

明文：xml明文，长度可变，需要上面的数据指明，双字节字符（汉字）算作1位长度； 分隔符：ICBCCMP；

密文：明文经过签名后的数据并做BASE编码； 如果不需要签名，则直接送xml明文；

以上数据经过拼接后，再进行BASE编码（仅reqData项）得到最终的reqData数据。

按照以上格式将请求数据发送到企业；此格式返回的数据是银行直接发给企业的ERP系统；如有使用，企业需要在内管注册或者修改集团信息时填入企业用于接收银行反馈的地址，标准格式是

企业签名验签过程

在银企互联中，对于指令体的签名与验签工作由纯java版工行签名验签接口完成的。

本文档对在专业版银企互联中使用的接口作出描述。

同时提供了一套纯java版的从企业发送指令到工行系统和从工行系统接收处理结果的例子程序。从企业发送指令到工行系统的例子中包括了两方面的内容：用企业的数据层私钥对数据进行签名，然后用工行的通讯层公钥进行通讯认证；从工行系统接收处理结果的例子中包括了两方面的内容：用企业的通讯层私钥要求通讯认证，然后用工行的数据层公钥进行数据的验签。

使用这种接入方式的客户只能使用磁盘证书；该磁盘证书需要拆分，拆分为一对数据层证书，用于签名验签；一对通讯层证书，用于建立与银行的https连接。拆分方法见第7章 企业签名验签方法总体介绍

接口包含、、、四个文件，使用时需要把这四个文件放置到java的classpath目录中。

该接口建议的JDK版本为以上。 接口使用的详细说明 Sign

（对原始数据进行数字签名的函数）

publicstaticbyte[]sign(byte[]src, intlen,

byte[]privateKey, char[]keyPass)

Description用rsa算法对一段消息签名

Parameters:

privateKey-为口令保护的私钥 src-为待签名消息 len-为待签名消息的长度 keyPass-为私钥保护口令

Returns:

如果成功返回签名结果,如果失败返回null

Throws:

NoSuchProviderException- NoSuchAlgorithmException- InvalidKeyException- SignatureException-

verifySign

（对数字签名进行验签的函数）

publicstaticintverifySign(byte[]src, intlen, byte[]cert, byte[]sign)

Description用rsa算法对一段签名进行验证

Parameters:

cert-为证书 src-为被签名的消息

len-为被签名消息的长度 sign-为签名的结果

Returns:

如果成功返回0,如果其它则失败

Throws:

SignatureException- NoSuchAlgorithmException- InvalidKeyException-

附件说明

1． 是一个演示各个接口使用方式的测试程序。

2． APIforZHEJIANG文件夹指导企业开发的例子程序；《使用说明》例子的使用说明。

3． 附件如下 https服务器建立开发支持

请参考上面附件中APIforZHEJIANG\\APIforZHEJIANG\\icbc\\api\\开发。《使用说明》文档介绍了开发方法。 Base编解码方法参考

建议使用sun提供的BASE编解码方法实现。

/**

*base解码

*@params:需要解码的数据 *@return解码后的数据 */

publicstaticStringgetstrFromBASE(Strings){

if(s==null) try{

byte[]b=(s); returnnull;

decoder=new

} /**

}

returnnewString(b); returnnull;

}catch(Exceptione){

*base解码

*@params:需要解码的数据 *@return解码后的数据 */

publicstaticbyte[]getbyteFromBASE(Strings){ } /**

*base编码

*@params:需要编码的数据 *@return编码后的数据 */

publicstaticStringgetrevFromBASE(byte[]s){ }

if(s==null) try{ }

(s); returnnull;

}catch(Exceptione){

returnnull;

encoder=new if(s==null) try{ }

(s); returnnull;

}catch(Exceptione){

returnnull;

decoder=new

报文版本号说明

当存量接口无法满足客户需求且无备用字段可扩充时，进行接口版本号的升级。升级后的接口保持TransCode不变，Version提升，使用新接口的客户，请求报文应与相应版本的报文格式保持一致。同时，要求使用新版本的客户系统按照自动扩展解析方式调用开发。即：企业客户根据银企互联接口数据返回包定义的“是否可选”标记来判断解析原则，如果标志为“否”的，需要

客户系统校验标签节点，如果为“是”的，客户系统可根据自身需求决定是否拓展。

关于通讯证书和银行证书的说明

如果企业客户需要接收银行的主动反馈信息，请注意以下内容： 1、

对于申请IC卡或者USBKey的硬方式数据证书的客户，需要在电子银行内部管理系统的“企业客户管理-客户通讯证书ID管理”下载一个通讯证书。此证书为磁盘证书，用于银行与客户建立https通讯使用；签名证书请客户继续使用硬证书；此磁盘证书需要拆分，拆分方法请见第7章。

2、

所有客户需要从银行端获取两张证书，一张是：银行端将对应的数据层公钥trust文件发给客户，以便银行与客户主动建立https链接认证使用；另一张是：银行端还要将客户验签使用的公钥证书在客户注册时也要发给客户，以便客户对银行返回的部分交易的数据进行验签使用。

磁盘证书拆分

证书拆分方法

见以下附件中的《证书制作流程.doc》，拆分工具也在其中。 证书拆分后流程

企业证书拆分所得.cer、.key和store文件由客户保存，分别是数据层公钥、数据层私钥和通讯层私钥；

交易规则

1. 对于多笔提交交易，判断银行返回文件级返回包的RetCode是否为0；如果

不为0，说明整批校验不通过，银行不会处理指令。此类情况下，客户可通

过对应交易的查询接口发起该笔指令的查询请求，如返回‘所查指令不存在’类报错，则此笔指令确认失败；如果为0，表示银行接收成功。客户可以通过接收银行反馈（需要在工行网点开通银行主动反馈功能）或者主动查询指令详细信息，进一步确认指令处理状态(一般情况下6代表失败，7代表成功，其他为中间状态。具体以接口文档为准)。

2. 对于单笔提交交易，一般银行实时处理，返回指令级返回包。用户可直接

根据交易的指令状态判断指令处理情况。（一般情况下，指令状态成功时，错误代码为0；指令失败时，在错误代码和错误描述字段会给出详细信息）。

大批量指令提交

背景

2013年8月份版本，优化程序。支持客户一次最大提交1000笔报文。 实现方法

1. 对于提交类请求报文，需要客户将(循环区)的指令压缩并base编码

后，放置到节点，成为新的请求报文。并且增加http请求参数zipFlag=1（0-不压缩1-压缩）。 举例：

压缩前的报文格式：

交易代码 集团CIS号

归属银行编号 证书ID

交易日期 交易时间 指令包序列号

联机批量标志 入账方式 总笔数

总金额 签名时间

请求备用字段1 请求备用字段2

指令顺序号

自定义序号 单据张数 定时启动日期 定时启动时间

记账处理方式

本方账号 本方账户名称

本方账户英文名称

对方账号 对方账户名称

对方账户英文名称

系统内外标志 同城异地标志

交易对方工行地区号 收款方所在城市名称

对方行行号

交易对方银行名称

币种 金额 用途代码 用途中文描述

英文备注

附言

业务编号（业务参考号） 相关业务编号 ERP流水号 业务代码

ERP支票号 原始凭证种类 原始凭证名称

原始凭证号

请求备用字段3 请求备用字段4

压缩后的报文格式

交易代码 集团CIS号

归属银行编号 证书ID

交易日期 交易时间 指令包序列号

联机批量标志 入账方式 总笔数

总金额 签名时间

请求备用字段1 请求备用字段2

压缩并base后的报文

2. 对于查询类交易

 如果客户提交时，是以压缩方式提交的，那么整包查询时，银行会以压

缩方式返回，指令信息放置在节点，需要客户先反base编码，再解压缩处理后得到明文。

 如果客户提交时，是以压缩方式提交的，但是是以单笔查询方式查询的

（即客户上送了具体指令的小序号），则不支持zip方式，直接给客户返回明文。有的交易不支持单笔查询，则不用考虑此条说明。

3. 目前支持大笔数提交的交易 交易 支付指令提交 企业财务室指令提交 企业财务室指令提交汇总记账 代理汇兑指令提交 代理支付指令提交 高级新批扣企业指令提交接口 高级批扣企业汇总记账指令提交 批扣个人指令提交 批扣个人指令提交汇总记账

版本 备注 含对应查询。 含对应查询。 含对应查询。 含对应查询。 含对应查询。 含对应查询。 含对应查询。 含对应查询。 含对应查询。

人事发工资指令提交 4. API 以下API供参考。 /*

含对应查询。 *压缩字符串数组为Zip后的Base格式 *

*@paramsrc源BYTE数组 *

*@return输出的BASE字符串

*/

publicstaticStringZipandBase(byte[]src)throwsIOException {

if(src==null) returnnull;

ByteArrayOutputStreamout=newByteArrayOutputStream(); GZIPOutputStreamgzip=newGZIPOutputStream(out); (src); ();

BASEEncoderencoder=newBASEEncoder(); ()); } /*

*反base编码并解压 *

*@paramsrc源字符串 *

*@return输出解码后的数组

*/

publicstaticbyte[]UnZipandUnbase(Stringsrc)throwsIOException {

if(src==null||()==0) returnnull;

BASEDecoderdecoder=newBASEDecoder();

ByteArrayOutputStreamout=newByteArrayOutputStream(); ByteArrayInputStreamin=newByteArrayInputStream(src)); GZIPInputStreamgzip=newGZIPInputStream(in); byte[]buffer=newbyte[256];

intbSize=0;

while((bSize=(buffer))>=0) {

(buffer,0,bSize); } (); (); }

分行特色交易接入

银企互联推广版非NC或NC客户接入时，增加根据交易代码进行总、分行分发的功能。

取客户上送的http参数报文中的TransCode字段，截取包含‘-’之前的字符，如在下面的对应关系表中，则通过HTTP协议转发至相对应的分行端（转到分行前置机）进行处理；如果未在对应关系表中，转发至总行端处理。 分行前置机地址在电子银行内部管理系统“分行网站应用服务器管理”进行维护，例如： 对应关系表： 安徽分行AHFH- 北京分行BJFH- 重庆分行CQFH- 大连分行DLFH- 福建分行FJFH- 广东分行GDFH- 甘肃分行GSFH- 广西分行GXFH- 贵州分行GZFH-

海南分行HANFH- 河北分行HEBFH- 河南分行HENFH- 黑龙江分行HLJFH- 湖北分行HUBFH- 湖南分行HUNFH- 吉林分行JLFH- 江苏分行JSFH- 江西分行JXFH- 辽宁分行LNFH- 宁波分行NBFH- 内蒙古分行NMGFH- 宁夏分行NXFH- 青岛分行QDFH- 青海分行QHFH- 四川分行SCFH- 山东分行SDFH- 上海分行SHFH- 山西分行SHXFH- 苏州分行SUZFH- 陕西分行SXIFH- 深圳分行SZFH-

天津分行TJFH- 分行XJFH 厦门分行XMFH- 云南分行YNFH- 浙江分行ZJFH-

例子：如标红所示，此交易TransCode为分行（XJFH）特色交易，此报文将会转发至分行在内管所设置的前置机地址及端口，总行侧不对此报文进行转发、校验等 TransCode=XJFH-Test