善付通支付接入实战：从报文规范到联调对账全解析

简介《建设银行善付通支付结算接入文档》是建行善融商务平台中善付通服务的官方对接指南面向企业后端开发、系统集成与运维人员旨在解决供应链上下游企业在订单协同、在线收付款和自动化对账中遇到的流程分散、人工核对量大等痛点。文档共1个docx文件压缩包大小约1.09MB正文按对接流程、数据传输规范、报文格式、数据加解密、接口定义五大模块编排层次分明。接口定义部分详细说明了二十余个SFT接口涉及订单支付与结果通知、订单查询、日终对账、预付款支付与查询、退款、会员绑定、联机订单、确认付款、订单取消及物流预付款协同等覆盖交易全生命周期。凭借完整接口字段、报文示例和加解密规则技术人员可直接依据文档完成系统设计、联调测试和上线部署缩短接入周期、降低沟通成本。目前已有2471人学习下载是计划接入建行善付通或了解其支付结算规范的企业团队的重要参考资料。1. 善付通支付结算接入从订单到对账一份能照抄的接口对接手册做供应链系统的开发者几乎都躲不开支付这块硬骨头。去年我负责某采购平台对接善付通最初以为只是发起一个支付请求、收一个回调真进入到联调才发现一单交易从下单、支付、退款到日终对账要面对三十多个接口外加数据加解密和回调时序这些绕不开的坑。善付通本质是银行侧的供应链支付结算通道把核心企业和上下游之间的订单协同、在线支付、结算对账串成一条完整的链路。这份接入文档把门槛写得很具体报文结构怎么拼、DES和MD5怎么做、每个接口的字段和适用场景。正在评估在线支付或移动支付方案的团队尤其是被供应链对账折磨过的人建议先读一遍再动手。2. 对接流程与报文规范四个固定参数名拆解所有交互对接之前先摸清地基。文档开头其实已经回答了三个问题先走什么流程、数据怎么传、报文长什么样。很多团队直接翻到接口定义去对字段结果反复被流水号规则和数据格式打回浪费的往往是整个联调窗口。这一章把流程和规范揉开讲透。2.1 业务对接流程从申请到正式上线的五个阶段接入善付通不是拿到文档就能直接打生产按我实际经历拆成五步。第一步提交接入申请。要跟银行侧确认业务场景是普通订单支付、预付款结算还是包含供应链协同的完整模式。场景不同开通的接口权限不同比如只用担保支付的话订单协同类接口不一定给你开。第二步获取对接三件套ThirdSysID、测试DES密钥、测试MD5密钥。ThirdSysID相当于你在善付通体系里的身份标识所有的流水号、签名、后续查询都跟它绑定。密钥在测试环境是统一的文档里写得很直白生产环境则要参考单独的“数据反馈表”文档去申请正式密钥。第三步拿到测试环境接口地址和 Hosts 配置。银行侧给的是一个域名本地联调时需要通过修改 hosts 把域名指向测试 IP否则访问的可能不是测试环境轻则超时重则把测试单打到不存在的地址。文档第六部分专门列了这项建议联调第一天就把 hosts 配置固化进开发机。第四步系统开发与联调。正确顺序是先跑订单支付主链路SFT10001 下单浏览器跳转支付页完成测试支付接收 SFT20001 通知再用 SFT10003 查订单状态确认状态一致后再扩展退款、对账、预付款这些分支。不要把三十几个接口一次性都接完再联调出了问题极难定位。第五步部署申请与生产切换。联调通过后提交部署申请拿到生产密钥和生产接口地址同时把回调地址加入白名单。从这步开始所有参数都要按数据反馈表来测试密钥一个都不能带上去。2.2 数据传输规范编码、通讯方式与流水号规则文档里定义了四条硬性规范任何一条不遵守接口直接报错。第一字符集统一 UTF-8。这不光是 HTTP 请求的编码还包括表单页面的编码和中文字段的传输。虽然联调环境里偶尔用 GBK 也能通但一旦遇到中文备注或收货人姓名就会出现签名对不上或者落库乱码。我一开始就在所有代码里强制指定 UTF-8省得排这种哑巴 bug。第二通讯方式统一 HTTP POST。请求接口时固定四个参数名ThirdSysID、TxCode、Data、Auth。TxCode 就是交易码比如 SFT10001 是订单支付、SFT10003 是订单查询Data 是加密后的密文Auth 是 MD5 签名。无论哪个接口POST 的 body 里都是这四个字段变化的只有 TxCode 和 Data 里的具体内容。第三流水号规则。这是整个文档里最容易被忽略的硬指标流水号统一使用 ThirdSysIDyyyyMMddHHmmss5 位顺序号由发送方生成长度不超过 30 位一个流水号只能使用一次含发送/返回两次跳转重复请求无效。“重复请求无效”这句话杀伤力很大。有一次联调我图省事直接用订单号加随机数当流水号结果长度超了被拒后来改成固定规则又因为同一秒内并发产生重复顺序号出现流水号冲突。流水号本质上是业务幂等键必须在发出去之前保证全局唯一多节点部署的还要在顺序号里加节点标识。第四返回地址。第三方要提供一个唯一的接收善付通数据的接口地址善付通向这个地址 POST 数据第三方根据报文里的 TxCode 分发给不同的处理逻辑。这个地址要在联调前准备好并且保证公网可达否则银行侧服务器回调不到你的系统。2.3 报文结构五个字段的职责与接口类型所有接口传输的数据总体分为五部分字段名含义是否加密说明ThirdSysID对接系统 ID否银行侧分配标识调用方身份TxCode交易码否例如 SFT10001决定业务类型Data业务数据是DES 加密具体接口所需的参数集合AuthMD5 签名否由 ThirdSysIDTxCodeDataMD5Key 拼接计算errorCode/errorMsg错误码和错误信息否发送请求时不带响应报错时返回Data 是业务核心里面是接口所需的参数集合发送前先用 DES 加密成密文再参与 Auth 签名。Auth 的计算方式是把 ThirdSysID、TxCode、Data 密文、MD5Key 四个字符串直接拼接算一次 MD5。注意这里用的是密文而不是明文 JSON顺序也不能调换后面第三章会专门演示。接口类型分为两种这个区分理解错了对接流程会整个跑偏。一种是联机接口。没有页面跳转第三方直接用 HTTP 客户端发起 POST 请求善付通处理完原路返回结果响应是 JSON 格式。典型代表是 SFT10003 订单信息查询、SFT10005 绑定用户关系。这类接口适合后端程序调用不涉及用户操作。另一种是网关接口。必须通过 POST 报文 FORM 表单以页面跳转的形式发起请求处理结果以异步通知返回。典型代表是 SFT10001 订单支付接口浏览器要从第三方系统跳到善付通的支付页面去完成支付支付完成再由善付通回调第三方的通知地址。网关接口的异步通知又分两种方式一种是页面通知带支付通知报文跳转第三方指定的前台地址另一种是服务器通知POST 到第三方指定的后台服务器地址。第三方接收程序要做成同一个入口根据 TxCode 区分业务类型才能保证页面通知和服务器通知都不丢。响应报文里凡是出错的场景基本都会返回 errorCode 和 errorMsg。联调时经常遇到一个现象接口返回 HTTP 200但报文里的 Status 是 2Remark 带一串原因——这说明请求到了善付通但业务校验没通过。排查错误别急着怀疑代码先把发送内容和文档字段定义逐字对照一遍多半是参数名大小写或者字段为空的问题。3. 数据加解密DES 密文与 MD5 签名拼接顺序错一个字符就全盘报错平台之间交互采用 DES 对称加密/解密算法。这句话翻译过来就是你在报文中看到的 Data 字段永远不会是 JSON 明文而是用约定的 DES 密钥加密出来的十六进制密文。加密、签名、验签这三步是接入善付通的第一道门槛也是最容易翻车的部分。3.1 DES 对称加密Data 字段里没有明文只有密文测试环境的 DES 密钥统一使用“TestDesKey”MD5 密钥统一使用“TestMD5Key”生产环境使用正式密钥具体值在数据反馈表文档里。加密的 Java 示例文档里给的 DESTool 工具类可以直接用// 密钥测试环境固定用 TestDesKey String desKey TestDesKey; // 待加密的字符串这里是接口所需的业务参数 JSON String data {\TxCode\:\SFT10001\,\TransID\:\10042025010100001\}; // 加密enStr 为密文 String enStr DESTool.encrypt(desKey, data); // 输出形如 07B0FE28667D98092D5DC0730A56E784EF68EB3BAD2F5E8C解密方向反过来String desKey TestDesKey; String data 07B0FE28667D98092D5DC0730A56E784EF68EB3BAD2F5E8C; // 解密后得到明文字符串 String deStr DESTool.decrypt(desKey, data);逻辑说明DESTool.encrypt 统一处理了填充逻辑业务代码不需要自己拼块。desKey 是约定的对称密钥测试环境为 TestDesKeydata 是待加密的业务参数 JSON。文档示例的密文是十六进制大写字符串如果你的实现返回的是小写或带换行符先处理工具类再继续。有个细节容易踩加密结果的密文是十六进制大写字符串拿这个字符串直接拼 Auth 的时候大小写要保持原样。MD5 对大小写很敏感如果开发机上的加密实现返回小写而银行侧期望大写签名校验必挂。我当时自测的方式是打印一次加密结果跟文档示例的密文格式做比对。3.2 MD5 签名先拼字符串再算摘要顺序就是约定发送方的签名逻辑文档里的示例把每一步都摊开了String thirdSysID 1004; // 第三方系统 ID String txCode SFT10001; // 交易码 String data 07B0FE28667D98092D5DC0730A56E784EF68EB3BAD2F5E8C; // DES 加密后的密文 String MD5Key TestMD5Key; // MD5 密钥 // 重点拼接顺序是 ThirdSysID TxCode Data MD5Key String auth MD5.getMD5(thirdSysID txCode data MD5Key, UTF-8); // 此时 auth 形如 4764da69b2cd9497801d42394562dd3f接收方验签逻辑反过来做一遍String thirdSysID request.getParameter(ThirdSysID); String txCode request.getParameter(TxCode); String data request.getParameter(Data); String auth request.getParameter(Auth); String MD5Key TestMD5Key; // 用同样的拼接方式重新计算签名 String tempAuth MD5.getMD5(thirdSysID txCode data MD5Key, UTF-8); if (tempAuth.equals(auth)) { // 签名一致数据未被篡改 } else { // 签名不一致按报文被篡改处理 }逻辑说明Auth 是 MD5 摘要拼接顺序必须严格保持 ThirdSysID、TxCode、Data、MD5Key 这个顺序。这里的坑在于很多人会把 MD5Key 拼到最前面或者拿明文 JSON 去签名——必须用 DES 加密后的密文。接收方验签时同样是对密文做拼接如果第三方拿到请求后先解密再用明文验签那永远对不上。MD5 计算结果是小写十六进制。文档示例里的 auth 是小写字符串。如果自己用 MessageDigest 转十六进制时习惯性转成大写也要统一。验签失败时先把发送和接收两边的 auth 打印出来逐字符对比绝大部分问题都出在拼接内容而不是算法上。3.3 加解密的两个隐蔽坑密钥位数与 URL 编码第一个坑是密钥位数。测试用的 TestDesKey 是 10 位DES 标准密钥是 8 字节工具类一般会自动截取或补位。生产切换时如果正式密钥更长要和银行侧确认到底是自动截断到前 8 字节还是要求应用程序自己做处理。第二个坑是密文中的特殊字符。DES 密文是十六进制串时还好但有些加密实现会吐出带 、/、 的 Base64 形式一旦放进 FORM 表单跳转这些字符在 URL 里会被重新编码解码后跟原密文不一致Auth 验签也会跟着失败。文档示例用十六进制密文天然只有 0-9 和 A-F适合直接拼接签名这是设计上的优势。如果你的工程里把它转成了 Base64请务必在 POST 之前做 URLEncode并和银行侧确认解析标准一致。注意Data 在参与 MD5 签名时必须是 DES 加密后的密文不能用明文 JSON 替代。这是联调期最常见的验签失败原因。如果你的团队不是 Java 栈比如是 Go 或 PythonDES 加密也能实现但要注意语言库默认的填充方式可能不一样。Java 的 DES 默认是 NoPadding 或 PKCS5PaddingPython 的 pyDes 默认也是 PKCS5一般能对上真正需要确认的是模式ECB/CBC和 IV初始向量。文档示例没有出现 IV说明用的是 ECB 模式。如果生产密钥要求 CBC银行侧必须给出 IV 值否则解密结果就是乱码。我建议在联调环境把这一点先问清楚省得生产切换那天突然发现密钥换新后全链路解密失败。4. 核心接口拆解从下单到对账一条链路走通支付全流程整套接口看着多实际围绕一条主链路展开创建订单、发起支付、接收通知、查询状态、退款、日终对账。先把这个闭环走通其他接口都是在这个骨架上的扩展。4.1 SFT10001 订单支付网关跳转与必填字段SFT10001 是善付通体系里最核心的入口。第三方系统将订单信息提交到善付通如果买家没有在善付通注册会跳转登录/注册页面引导用户输入用户名密码后再跳转支付页面完成支付。接口类型是网关接口请求通过页面跳转发起结果异步通知。关键参数里最需要拿准的几个字段说明必填备注TxCodeSFT10001是固定值TransID流水号是ThirdSysID时间5 位顺序号一次有效GoPayType保存订单后是否立即支付是1-PC 支付 2-移动版支付 3-小程序支付PayType支付方式否01 直接支付 00 担保支付默认 01OrderIniter订单创建方是0 买方发起 1 卖方发起Pay_Interface支付接入方式否00 融易付收银台、01 个人网银、02 企业网银、03 银联在线、04 聚合支付码GoPayType 决定支付页面形态传 1 保存订单后自动跳转 PC 版支付页面适合 PC 端浏览器场景传 2 跳移动版支付页面适配手机 H5传 3 说明是通过小程序跳支付前端需要对接小程序端的跳转逻辑。Pay_Interface 默认是 00 融易付收银台。如果你的场景里买家可能在电脑旁却没有网银可以用 04 聚合支付码此时接口会多返回一个 Direct_Pay_Url用于接收聚合支付 URL 串前端拿到这个 URL 再渲染出收款码。这个字段仅当 Pay_Interface04 时返回。订单详情部分报文是一个 dataset 结构的 OrderInfos里面包含 Order_No第三方系统订单号、Order_Money订单支付金额、Order_Time创建时间格式 yyyyMMddHHmmss、Order_Title订单标题、ReceiverTrueName_ThirdSys收货方姓名等。订单标题会直接展现在支付页面上别把内部备注当标题传上去买家付款时看到一串乱码属于业务字段使用错误。文档里还提到分账相关字段Rlacc_Num分账账户个数、Topy_Tamt分账总金额、Cmsn_Inracc_No分账账户列表。注意一个原则分账账户必须是银行侧实名绑定账户数量必须与 Rlacc_Num 一致以竖线分割上送同笔订单所有明细固定金额之和加上所有手续费之和必须小于或等于支付金额。这些约束银行侧会校验但在自己后端提前判断能省去来回调试的时间。提示分账字段中账户必须以 | 线分割上送且账户必须是银行侧实名绑定账户数量必须与 Rlacc_Num 一致否则接口直接拒绝。4.2 支付结果通知 SFT20001状态机与幂等处理每一笔订单支付完成后无论支付成功与否善付通都会调用 SFT20001 通知第三方。通知有两种页面通知和服务器 POST 通知。第三方系统必须同时支持两种用一个统一的接收入口按 TxCode 分发。通知报文里重点看几个字段。PayStatus 支付状态有四个取值1 付款成功、2 付款失败、4 已支付未确认付款。这里的 4 容易让人困惑对应担保交易场景买家已付款但还没确认收货钱在中间账户压着业务上既不能当成成功发货也不能算失败退款。对接担保支付时收到 4 要做的是触发发货流程或等待确认而不是完结订单。Order_Money 本次支付金额和 Total_Money 累计支付金额的区别同一订单可能存在多次支付的情况业务上要按累计金额判断是否收齐用 PayStatus1 且 Total_Money 达到订单金额来判定最终成功单看某一次通知里的金额会漏判。PayNameByCard 是支付人的姓名或公司名优先使用实际付款人信息为空时退而求其次用融易付实名认证信息Pay_Card 是付款人卡号。这两个字段对财务核对很有用尤其是处理代付场景时。幂等处理是接这个接口的重中之重。善付通的服务器通知可能会重复投递页面通知和服务器通知也可能先后到达。最稳的做法是以 TransID 或订单号做唯一键落一张通知记录表收到通知先查重重复报文直接返回成功应答不重复处理业务逻辑。我在联调时就因为没做幂等测试支付时连续收到两条 PayStatus1 的通知把发货逻辑执行了两次仓库那边直接打出两单。4.3 查询、退款与对账SFT10003、SFT10009、SFT10008SFT10003 订单信息查询是联调阶段最好的调试工具。它按第三方系统的订单号查支付结果一次最多查询 10 个订单号超过会被拒绝。请求里带上 Clr_Flag001 可以额外查清算状态返回 Clr_Status00 订单未清算、01 清算成功、05 清算成功后有退款以及 Clr_Time 清算时间。联调时我的习惯是收到 SFT20001 通知后再用 SFT10003 主动查一次两边对比既能验证通知报文也能排除网络丢包。退款链路分成几个接口SFT10009 订单退款接口走原支付路径退回SFT10013 联机退款接口适合实时处理退款结果由 SFT20003 通知。查询接口里有个 thirds PaybackIds 字段记录已成功退款的第三方退款 ID 列表用逗号分隔。对接退款时一定要先查再退特别是部分退款场景得先看累计已退金额避免超退。SFT10008 日终对账接口按日期查询返回对账单文本文件。这个接口每天调用次数有限制对账节奏建议是当天中午拉前一日的对账单先校验笔数和金额再和本地订单流水表逐笔核对不一致的单独标记。对账文件是文本文件解析时注意换行符在不同平台上的差异Windows 上做出来的文件拿到 Linux 服务器解析会把 \r\n 拆出空行。4.4 扩展接口速览预付款、协同、实名与配置信息剩下的接口按用途快速过一遍方便规划对接排期。预付款链路SFT10020 预付款支付、SFT20002 预付款支付结果通知、SFT10021 预付款信息查询、SFT10022 预付款单状态查询、SFT10024 预付款协同。这类接口适合核心企业预收货款或预付货款场景资金流和订单流可以分开走。协同链路SFT10015 联机订单保存只保存订单不发起支付、SFT10016 订单协同、SFT10017 上下游绑定/解绑确认、SFT10018 退款协同、SFT10019 物流协同、SFT10023 确认付款。这些接口的目标是把订单、退款、物流状态在上下游系统之间同步对接时区分发起方和接收方不要看到“订单”字样就往支付上报。用户与账户链路SFT10005 绑定用户关系、SFT10011 买家会员绑定、SFT20005 绑定结果通知、SFT10025 实名认证、SFT10026 回单查询、SFT10027 实名查询、SFT10028 用户信息变更、SFT10029 用户解绑。实名认证相关接口在上线前最好测试通过否则买家无法绑卡支付。特殊支付链路SFT10012 是订单支付接口的手机号验证码版本适合移动场景多了短信验证码校验步骤SFT10004 电票支付接口处理电票支付。配置信息里还有几项要联调前确认接口地址测试和生产两套、Hosts 配置、需第三方提供的地址、部署申请流程。最后补充一个使用文档的小技巧善付通的接口编号有规律。SFT1 开头基本是第三方系统发起请求的接口比如 10001、10003、10009SFT2 开头是善付通主动通知第三方的接口比如 20001 支付结果通知、20003 退款结果通知。收到 SFT2 开头的 TxCode 时接收程序进入的是通知处理分支而不是主动请求分支这个区分能帮你快速定位报文在哪个环节产生的。5. 避坑清单联调两个月里踩过的五个支付接入坑这一章不按接口顺序讲按坑的类型讲。每条都按现象、原因、解决三个维度展开方便你排查时对照。5.1 报文与编码类流水号、密文和签名对不上的典型场景坑一流水号超长或重复请求被拒绝。现象是调用 SFT10001 返回错误提示流水号无效或重复请求。原因是当时用订单号加随机数拼流水号长度达到 32 位超过 30 位上限后来改成固定规则又因为同一秒内并发产生重复顺序号。解决方法是严格按 ThirdSysIDyyyyMMddHHmmss5 位顺序号拼接顺序号用进程内自增加锁保证同一秒内不重复。第三方系统有多个节点部署时顺序号还要加节点标识否则两个节点会在同一秒生成同一个顺序号。坑二密文里的特殊字符被 URL 重编码验签失败。现象是网关接口跳转时明明加密和签名逻辑都正确善付通却返回签名校验失败。原因是某个版本的 DES 工具类输出的是 Base64 格式密文比如 7BAb/...这种字符串放在 FORM 表单或 URL 里、/、 会被转义到达银行侧时已经不是原串签名自然对不上。解决方式是构造跳转表单时对 Data 字段不做额外处理让浏览器自动按表单格式编码如果是自己拼 URL则用 URLEncoder 先行编码同时确认接收方用相同方式解码。更稳妥的做法是用文档示例的十六进制密文输出它天然没有特殊字符。坑三中文字段乱码订单标题、收货人信息失真。现象是测试环境一切正常生产环境部分字符变成问号或乱码。原因是生产环境的容器或 HTTP 客户端默认字符集不是 UTF-8虽然规范里写了统一 UTF-8但容器的 URIEncoding、HTTP 客户端的字符集设置这些地方很容易被漏掉。解决方法是全链路固定接收端在容器层面强制 UTF-8发送端在每个 POST 请求头显式带上 charsetUTF-8数据库连接字符串也加上 characterEncodingutf-8。排查乱码时不要只盯代码先看请求实际用什么编码发出去的。5.2 流程与状态类通知幂等、订单状态和文件对账的边界问题坑四支付成功通知重复投递业务被重复处理。现象是同一笔订单收到多条 SFT20001 通知发货单重复创建。原因是善付通的服务器通知为了保证送达会重试页面通知和服务器通知也可能同时到达而我们当时没有做通知去重。解决方式是以 TransID 加 Order_No 做唯一索引通知处理前先查重记录落库要在业务处理成功之后再写如果先写记录再处理业务处理失败时记录已存在后续重试会被直接跳过反而漏单。坑五日终对账单和本地订单金额对不上。现象是对账文件里某笔订单金额多了一分钱或者多了一笔本地没有的订单。原因有两个一是本地以支付结果通知为准入账但通知里 PayStatus4 的担保支付订单还没确认付款金额挂在中间态二是 SFT10008 是按日期查的但订单的支付日期和业务创建日期可能不是同一天拉错了日期范围。解决方式是统一以支付完成时间对账担保支付订单单独区分确认付款后再计入对账文件解析后先核对文件里的记录数和总金额再逐笔核对明细任何异常先停掉自动入账流程人工介入。还有一个低级但常见的坑生产环境忘记换 MD5 密钥全用测试密钥签名上线首日所有请求验签失败。这个错太蠢又太常见建议把密钥核对写进上线检查单逐项打勾。6. 联调验证与安全验签把回调入口做成可审计的黑匣子6.1 回调验签服务先验签再入库联调阶段第一个要写好的代码是善付通回调的接收端。它接收 POST、验签、还原明文、打印参数。用 Python 可以写得很短from flask import Flask, request import hashlib app Flask(__name__) MD5_KEY TestMD5Key # 联调阶段使用测试密钥 app.route(/sft/notify, methods[POST]) def sft_notify(): # 从表单参数中取出四个固定字段 third_sys_id request.form.get(ThirdSysID, ) tx_code request.form.get(TxCode, ) data_cipher request.form.get(Data, ) auth request.form.get(Auth, ) # 按文档约定拼接并计算 MD5 raw third_sys_id tx_code data_cipher MD5_KEY expect_auth hashlib.md5(raw.encode(utf-8)).hexdigest() # 验签失败直接返回失败不放行 if expect_auth ! auth: print(验签失败: tx%s, auth%s, expect%s % (tx_code, auth, expect_auth)) return verif fail # 验签通过后把 Data 密文记录到日志留作审计 print(收到回调: TxCode%s, Data%s % (tx_code, data_cipher)) return success这段代码的核心就两件事验签、打日志。注意验签用的 raw 是密文 data_cipher 直接拼接不是解密的 JSON。把密文原样打进日志方便后期复现问题。联调阶段接收端只做验签和落库不做业务处理等所有报文格式确认无误再往上加业务逻辑能减少干扰变量。6.2 本地演练的四个固定动作在用这个回调服务联调时我每次都会按固定顺序执行四个动作现在已经变成习惯。第一个动作预备测试交易数据一个唯一的 Order_No、一个唯一流水号、一个小额订单金额。不建议金额填 0.01 这类极端值部分环境对极小金额有特殊处理填 1.00 最稳。第二个动作发起一笔 SFT10001 请求。先本地构造 Data 明文DES 加密拿密文拼 Auth用 curl POST 到测试环境地址观察返回。看到跳转页面后人工完成测试支付用银行侧提供的测试账号不要用真实卡号。第三个动作等回调。观察回调服务日志记录 TxCode、Data 密文和验签结果用 SFT10003 主动查询同一笔订单对比 PayStatus 和 Total_Money。如果一致订单链路走通。第四个动作做一次退款。用 SFT10013 发起退款等 SFT20003 退款通知再调 SFT10008 拉日终对账单看那笔订单是否变成已退款状态。这四个动作跑完后支付闭环才算真正打通。有个小细节值得多说一句联调时不要只测成功路径要故意构造一次签名错误、一次金额超限、一次重复流水号看错误码是不是符合预期。这些异常路径是生产上最容易出问题的地方联调阶段多测一次生产少熬一个夜。没有写在文档里的是这些坑。从那以后每次对接外部支付网关我都强制自己走一遍这套流程先读数据规范再写验签服务再按主链路逐个接口联调最后把密钥和 hosts 当成发布检查项逐项核对。善付通这份文档虽然接口多但数据传输规范是统一的只要把报文规范、加解密、网关与联机的区分理解透剩下的接口都是填字段的活。希望帮到你。本文还有配套的精品资源点击获取