2. 接口概述


2. 接口概述

2.1 选择报文

2.1.1 产品与报文的关系

商户需根据与通联合作的支付产品,选择对应的接入报文接口。以下是收付通四种支付产品:收款、付款、还款通、联贷通,需对接的报文接口建议。若商户有其他特殊要求,请与通联客户经理进一步沟通。

提示: 如有需求在特定时间段发完交易,调用批量接口。

产品-主交易

必须接入接口

可选接入接口

收款-协议支付

协议支付签约短信触发(310001)
协议支付签约(310002)
协议支付解约(310003)
协议支付(310011)
签约结果查询(340009)
交易结果查询(200004)
SFTP对账文件推送,见章节4.1

1. 退款(REFUND)(当商户有退款需求时接入)
2. 解约通知(310005)(当商户需接收持卡人银行端发起的解约通知,来引导持卡人重新签约时接入)
3. 快捷单笔交易结果通知(对于掉单情况,如果商户希望通过查询+通知方式更快获取结果时接入)

收款-批量协议支付

协议支付签约短信触发(310001)
协议支付签约(310002)
协议支付解约(310003)
批量协议支付(310016)
签约结果查询(340009)
交易结果查询(200004)
批量交易完成通知(200003)
SFTP对账文件推送,见章节4.1

1. 退款(REFUND)(当商户有退款需求时接入)
2. 解约通知(310005)(当商户需接收持卡人银行端发起的解约通知,来引导持卡人重新签约时接入)

付款-单笔实时代付

单笔实时代付(100014)
交易结果查询(200004)
SFTP对账文件推送,见章节4.1

1. 商户主动划款入账通知
2. 代收付单笔成功交易结果通知
3. 代收付单笔失败交易结果通知

付款-批量代付

批量代付(100002)
交易结果查询(200004)
批量交易完成通知(200003)
SFTP对账文件推送,见章节4.1

1. 商户主动划款入账通知

还款通-实时还款

协议支付签约短信触发(310001)
协议支付签约(310002)
签约结果查询(340009)
实时还款(100007)
交易结果查询(200004)
SFTP对账文件推送,见章节4.1

1. 解约通知(310005)(当商户需接收持卡人银行端发起的解约通知,来引导持卡人重新签约时接入)

联贷通-联合付款

联合付款(100072)
交易结果查询(200004)
SFTP对账文件推送,见章节4.2

-

2.1.2 报文清单

报文组

交易类型

报文名称

报文方向

对账

3.1协议支付报文组

310001

协议支付签约短信触发

商户→通联

×

310002

协议支付签约

商户→通联

×

310003

协议支付解约

商户→通联

×

310011

协议支付

商户→通联

310016

批量协议支付

商户→通联

340009

签约结果查询

商户→通联

×

310010

协议支付签约合并支付

商户→通联

310008

快捷签约协议展示申请

商户→通联

×

310030

协议号授权同步

商户→通联

×

-

H5链接签约

商户→通联

×

3.2批量代收付报文组

100001

批量代收(特殊场景使用,请咨询通联客户经理)

商户→通联

100002

批量代付

商户→通联

3.3单笔实时代收付报文组

100011

单笔实时代收(特殊场景使用,请咨询通联客户经理)

商户→通联

100014

单笔实时代付

商户→通联

3.4还款通报文组

100007

实时还款

商户→通联

×

200008

还款通结果查询

商户→通联

×

3.5联贷通报文组

100072

联合付款

商户→通联

3.6账务报文组

300000

账户信息查询

商户→通联

×

300001

历史余额查询

商户→通联

×

300002

汇款充值通知

商户→通联

×

300003

账户提现

商户→通联

×

100191

汇入金分账

商户→通联

×

100192

汇入金分账查询

商户→通联

×

300006

账户充值

商户→通联

×

100400

内部转账

商户→通联

×

100401

批量内部转账

商户→通联

×

3.7通用报文组

REFUND

退款

商户→通联

200004

交易结果查询

商户→通联

×

200009

对账文件下载

商户→通联

×

200007

卡BIN查询

商户→通联

×

100055

电子回单异步下载接口

商户→通联

×

3.8异步通知接口

-

退票通知

通联→商户

-

商户主动划款入账通知

通联→商户

×

-

快捷单笔交易结果通知

通联→商户

×

200003

批量交易完成通知

通联→商户

×

-

代收付单笔成功交易结果通知

通联→商户

×

-

代收付单笔失败交易结果通知

通联→商户

×

310005

解约通知

通联→商户

×

110000

余额告警通知

通联→商户

×

-

结算交易通知

通联→商户

×

3.10一键绑卡/网关签约报文组

310006

一键绑卡签约申请

商户→通联

×

-

签约回跳接口

通联→商户

×

310006

签约结果通知

通联→商户

×

310009

短信签约

商户→通联

×

3.11一键多绑报文组

310045

一键多绑签约API(二次短信)申请

商户→通联

×

310046

一键多绑签约API(二次短信)确认

商户→通联

×

310047

一键多绑签约API(二次短信)账户授权申请

商户→通联

×

310048

一键多绑签约API(二次短信)账户授权确认

商户→通联

×

310041

一键多绑签约H5

商户→通联

×

310043

一键多绑签约API(一次短信)申请

商户→通联

×

310047

一键多绑签约API(一次短信)账户授权申请

商户→通联

×

310048

一键多绑签约API账户授权确认

商户→通联

×

-

签约结果通知

通联→商户

×

3.12自定义账单报文组

310031

自定义账单请求

商户→通联

×

310032

自定义账单结果查询

商户→通联

×

310033

自定义账单退款

商户→通联

×

-

自定义账单交易结果通知

通联→商户

×

3.13绑卡智选报文组

310050

绑卡智选

商户→通联

×

3.14客诉报文组

350001

投诉工单查询

商户→通联

×

350002

投诉工单回复

商户→通联

×


2.2 通讯方式

2.2.1 公网通讯方式

HTTPS的POST方式,使用TLS1.2。

2.2.2 专线通讯方式

HTTP的POST方式。

对应的测试环境出口IP和端口:192.168.91.18:8000,同时要提网络申请给数据中心。

2.2.3 生产环境接口地址

目标环境

接口地址

说明

接口生产环境URL

https://tlt.allinpay.com/aipg/ProcessServlet?MERCHANT_ID=?&REQ_SN=?

MERCHANT_ID与REQ_SN分别对应报文头中的商户号、请求流水号

2.2.4 对外出口IP

当对于来自通联端的请求,比如SFTP/FTP对账文件推送,或通知类报文,商户需要设置通联端服务器白名单,参考收付通如下生产出口IP:

生产环境出口IP:

序号

IP 地址

1

140.206.57.166

2

117.184.121.6

3

222.72.143.68

4

222.72.143.69

5

140.206.57.164

6

101.95.129.116

7

117.184.121.4

8

101.95.191.142

9

210.22.100.126

10

220.248.8.94

11

117.144.212.130(新增)

12

210.22.139.90(新增)


2.3 报文格式说明

2.3.1 字段类型

本技术规则在报文的"类型"列中使用的字段类型按如下说明:

属性

说明

C(n)

业务要素的值可使用字母、中文等,长度固定为n

C(n,m)

业务要素的值可使用字母、中文等,最小长度为n、最大长度为m

N(n)

业务要素的值只能使用数字,长度固定为n

2.3.2 字段限制

本技术规则在报文的"限制"列中使用M、C的形式描述业务要素的传递条件:

属性

说明

M

必填

C

选填

2.3.3 请求报文格式

节点

说明

AIPG(根节点)

报文根元素

INFO(报文头)

报文头包含了签名标签SIGNED_MSG

XXX(报文体)

每种报文体都不一样,具体标签值需参考具体请求报文定义

请求报文头格式: <INFO>报文头内容</INFO>

接口

字段ID

字段解释

类型

取值

限制

备注

INFO

TRX_CODE

交易代码

C(6,10)

-

M

用于区分交易接口

VERSION

版本号

C(2)

05

M

-

DATA_TYPE

数据格式

C(1)

2

M

-

LEVEL

处理级别

N(1)

5

M

-

MERCHANT_ID

商户号

C(10,20)

-

M

-

USER_NAME

用户名

C(1,20)

-

M

-

REQ_SN

请求流水号

C(0,60)

-

M

全局唯一不能重复

2.3.4 响应报文格式

节点

说明

AIPG(根节点)

报文根元素

INFO(报文头)

报文头包含了签名标签SIGNED_MSG

XXX(报文体)

每种报文体都不一样,具体标签值需参考响应报文定义

响应报文头格式: <INFO>报文头内容</INFO>

接口

字段ID

字段解释

类型

取值

限制

备注

INFO

TRX_CODE

交易代码

C(6,10)

-

M

与请求报文的交易类型一致

VERSION

版本号

C(2)

05

M

-

DATA_TYPE

数据格式

C(1)

2

M

-

REQ_SN

请求流水号

C(36,60)

-

M

-

RET_CODE

返回码

C(4)

-

M

-

ERR_MSG

返回信息

C(1,128)

-

M

-

重要提示: 由于网络等不可预知原因,可能会出现响应报文的串改,对响应报文的解析处理,必须校验返回的请求流水号与请求报文的请求流水号一致。

2.3.5 编码格式

默认编码格式是GBK,由于GBK编码对部分生僻字无法兼容,如“䶮”。商户可调整为utf-8 发送交易,原接口地址要加上参数 encoding=UTF-8,签名和发送都要改成UTF-8编码。


2.4 数字签名域

商户用私钥对请求报文进行签名,用公钥对响应报文进行验签。

2.4.1 请求报文加签

签名算法支持:

  • SHA1withRSA
    • SM3withSM2(需设置https请求头字段 SIGN-ALG 为 1),比如demo中conn.setRequestProperty("SIGN-ALG","1")

重要提示: SHA1withRSA只考虑对存量商户的支持,新商户请务必使用SM3withSM2JDK版本要求1.8.0.301以上

签名内容产生规则: 用SHA1(或SM3)计算整个未签名报文哈希值,并将该哈希值用RSA(或SM2)用商户的私钥进行签名,将签名信息置于 <SIGNED_MSG> 节点中,最后将该节点附在报文头INFO。

签名前的报文示例:注意</REQ_SN>与</INFO>之间有一空行

<?xml version="1.0" encoding="GBK"?>
<AIPG>
<INFO>
    <TRX_CODE>xxxxxx</TRX_CODE>

    <VERSION>03</VERSION>

    <DATA_TYPE>2</DATA_TYPE>

    <LEVEL>5</LEVEL>

    <USER_NAME>xxxxxxxxxxxxxxxx</USER_NAME>

    <USER_PASS>xxxxxx</USER_PASS>

    <REQ_SN>xxxxxxxxxxxxxxxxxx</REQ_SN>

</INFO>

<VALIDR>
    <MERCHANT_ID>xxxxxxxxxxxxxxx</MERCHANT_ID>

    <SUBMIT_TIME>xxxxxxxxxxxxxx</SUBMIT_TIME>

    <BANK_CODE>xxxx</BANK_CODE>

    <ACCOUNT_NO>xxxxxxxxxxxxxxxx</ACCOUNT_NO>

    <ACCOUNT_NAME>xx</ACCOUNT_NAME>

    <ID_TYPE>x</ID_TYPE>

    <ID>xxxxxxxxxxxxxxxxxx</ID>

    <TEL>xxxxxxxxxxx</TEL>

    <REMARK></REMARK>

</VALIDR>

</AIPG>

签名后的报文示例:

<?xml version="1.0" encoding="GBK"?>
<AIPG>
<INFO>
    <TRX_CODE>xxxxxx</TRX_CODE>

    <VERSION>03</VERSION>

    <DATA_TYPE>2</DATA_TYPE>

    <LEVEL>5</LEVEL>

    <USER_NAME>xxxxxxxxxxxxxxxx</USER_NAME>

    <USER_PASS>xxxxxx</USER_PASS>

    <REQ_SN>xxxxxxxxxxxxxxxxxx</REQ_SN>

    <SIGNED_MSG>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</SIGNED_MSG>

</INFO>

<VALIDR>
    <MERCHANT_ID>xxxxxxxxxxxxxxx</MERCHANT_ID>

    <SUBMIT_TIME>xxxxxxxxxxxxxx</SUBMIT_TIME>

    <BANK_CODE>xxxx</BANK_CODE>

    <ACCOUNT_NO>xxxxxxxxxxxxxxxx</ACCOUNT_NO>

    <ACCOUNT_NAME>xx</ACCOUNT_NAME>

    <ID_TYPE>x</ID_TYPE>

    <ID>xxxxxxxxxxxxxxxxxx</ID>

    <TEL>xxxxxxxxxxx</TEL>

    <REMARK></REMARK>

</VALIDR>

</AIPG>

2.4.2 响应报文验签

验签算法: SHA1withRSA / SM3withSM2

验签规则:

  1. 商户端获取响应报文SIGNED_MSG的值
  2. 用RSA/SM算法使用通联通分配的公钥(测试环境公钥找通联客户经理要)进行解密获得验签值
  3. 将响应报文去掉SIGNED_MSG域值换成空行,用SHA1(或SM3)算哈希值
  4. 将该哈希值与上一步获得的验签值进行比较,一致则验证通过

注意: 获取响应报文时,需判断响应里的REQ_SN与请求报文REQ_SN一致才去更新交易结果。


2.5 全报文加密

HTTP POST 商户加密签名请求报文规范

(兼容 RSA+AES / 国密 SM2+SM4 双体系)

一、文档说明

本文档定义 商户 → 通联支付平台 的标准 HTTP POST 请求报文规范,具备以下特性:

• ✅ 标准 JSON 格式请求体

• ✅ 同时支持 通用算法(RSA + AES) 与 国密算法(SM2 + SM4)

• ✅ 支持 静态约定密钥 与 动态随机对称密钥 两种模式

• ✅ 与通联现有密钥管理、幂等校验、日志追溯体系完全兼容

二、完整报文结构(最终形态)

Content-Type:application/json

请求方法:POST

{
  "MERCHANT_ID": "商户分配编号",
  "REQ_SN": "202605201530000001",
  "SUBMIT_TIME": "2026052015300000",
  "SIGN-ALG": 1,
  "KEY-NUMBER": "TL202605001",
  "encryptKey": "通联公钥加密后的对称密钥密文",
  "encData": "SM4/AES加密后的业务报文密文",
  "encoding": "GBK"
}

三、字段说明(核心规范)

字段名     类型     必传    说明
MERCHANT_ID   String 商户唯一编号,由通联统一分配,固定不变
REQ_SN   String 商户号 + 时间戳 + 随机数,用于幂等、防重、日志追踪
SUBMIT_TIME   String 请求提交时间,格式:YYYYMMDDHHMMSS
SIGN-ALG   String 0= RSA + AES(通用)
1= SM2 + SM4(国密)
KEY-NUMBER   String 否 ,KEY-NUMBER/encryptKey,二选一 通联分配的系统密钥编号。
encryptKey   String 否,KEY-NUMBER/encryptKey,二选一 动态对称密钥密文(通联公钥加密后的对称密钥密文)
encData    String RSA / SM2 加密后 Base64 编码
encoding   String  是 GBK(默认)、UTF-8

 

四、加密交互流程(标准安全模型)

非对称加密保护对称密钥,对称加密保护业务数据

┌────────────┐       ┌────────────┐       ┌────────────┐
│ 商户客户端 │ ───▶ │ 通联网关   │ ───▶ │ 业务系统   │
└────────────┘       └────────────┘       └────────────┘


标准化步骤

1. 选择算法体系

  • SIGN-ALG = 0:RSA + AES

  • SIGN-ALG = 1:SM2 + SM4

2. 生成对称密钥

  • AES:256 bit

  • SM4:128 bit

  • 每笔请求独立生成,不可复用

3. 加密对称密钥

  • 使用 通联公钥

  • RSA / SM2 加密

  • Base64 编码 → encryptKey

4. 加密业务数据

  • 使用上一步生成的对称密钥

  • 加密业务明文 JSON

  • Base64 编码 → encData

5. 填写密钥字段

  • 动态密钥:KEY-NUMBER 为空,encryptKey 必填

  • 静态密钥:KEY-NUMBER 必填,encryptKey 为空

6. 组装并发送请求

  • JSON 请求体

  • HTTP POST


------

五、典型报文示例

场景 1:国密 + 动态密钥(推荐)

{
  "MERCHANT_ID": "10088669",
  "REQ_SN": "1008866920260520153022123456",
  "SUBMIT_TIME": "2026052015302200",
  "SIGN-ALG": 1,
  "KEY-NUMBER": "",
  "encryptKey": "SM2加密后的SM4密钥Base64",
  "encData": "SM4加密后的业务数据Base64",
  "encoding": "GBK"
}

 

------

场景 2:AES通用算法 + 静态密钥

{
  "MERCHANT_ID": "10088669",
  "REQ_SN": "1008866920260520153110654321",
  "SUBMIT_TIME": "2026052015311000",
  "SIGN-ALG": 0,
  "KEY-NUMBER": "TLKEY20260520",
  "encryptKey": "",
  "encData": "AES-256加密后的业务数据Base64",
  "encoding": "GBK"
}

 

------

场景 3:AES通用算法 + 动态密钥

{
  "MERCHANT_ID": "10088669",
  "REQ_SN": "1008866920260520153220887654",
  "SUBMIT_TIME": "2026052015322000",
  "SIGN-ALG": 0,
  "KEY-NUMBER": "",
  "encryptKey": "RSA加密后的AES密钥Base64",
  "encData": "AES-256加密后的业务数据Base64",
  "encoding": "GBK"
}

 

------

场景 4:国密 + 静态密钥

{
  "MERCHANT_ID": "10088669",
  "REQ_SN": "1008866920260520153315998712",
  "SUBMIT_TIME": "2026052015331500",
  "SIGN-ALG": 1,
  "KEY-NUMBER": "TLKEY20260520",
  "encryptKey": "",
  "encData": "SM4加密后的业务数据Base64",
  "encoding": "GBK"
}

 

------

六、关键规则速览(对接必读)

类别    强制约束
算法选择    SIGN-ALG 必须明确指定
密钥长度    AES 256bit / SM4 128bit
动态密钥    每笔请求一次,禁止复用
静态密钥    必须配置 KEY-NUMBER
时间格式    YYYYMMDDHHMMSS
编码一致     encoding 必须一致
幂等性    REQ_SN 不可重复

 

AES算法:

// 加密
signedXml = AESUtil.encrptWithBase64(signedXml, "密钥");
// 解密
respText = AESUtil.decryptWithBase64(respText, "密钥");
encryptKey的取值方法可参考demo,密钥文件对应通联rsa公钥。
String encryptKey =AipgCipherUtil.encryptByRSA("密钥", new  File(DemoConfig.pathcer));

国密SM4算法:

// 加密
signedXml = SM4Util.encrptWithBase64(signedXml, "密钥", "GBK");
// 解密
signedXml = SM4Util.decryptWithBase64(signedXml, "密钥", "GBK");
encryptKey的取值方法可参考demo,密钥文件对应通联国密公钥
String encryptKey =AipgCipherUtil.encryptBySm2("密钥", new  File(DemoConfig.pathcer));

2.6 主要字段说明

2.6.1 商户号

报文中的商户号(MERCHANT_ID)新商户默认为15位:数字+字母格式,入网时由通联分配。

2.6.2 交易代码

交易代码(TRX_CODE)区分了对应的报文功能。

2.6.3 业务代码

业务代码(BUSINESS_CODE)在商户入网时由通联分配,商户报文只能上送指定的业务代码。

2.6.4 银行代码

报文体中的银行代码(BANK_CODE)一般为可选字段,通联的处理逻辑为:

  • 验证类接口: 若填写了银行代码,通联会根据卡号匹配对应的卡BIN,若匹配出来的银行代码与商户上送的不一致,则返回银行代码不一致的错误
  • 交易类接口: 通联以商户上送银行代码为准
  • 不上传银行代码: 通联会根据卡BIN匹配银行代码
  • 对公和存折: 统一上送银行代码

建议: 为了提高交易的成功率,该字段尽量上传。

2.6.5 交易类接口提交时间

提交时间(SUBMITTIME),校验时间会与收付通系统时间(北京时间)在5分钟之内,假如超过就会被拦截。

2.6.6 账户类型和账户属性

账户类型 ACCOUNT_TYPE账户属性 ACCOUNT_PROP,系统会根据卡号规则识别该卡是借记卡还是信用卡,识别不到,账户类型替换为01存折,账户属性为对公01。


huangwg 2026年6月24日 15:17 8101 0 条评论 收藏文档