微信支付 APIv3 2026 文档更新：合单支付字段语义调整与退款入账展示变化
来源：微信支付商户文档中心《总览_更新日志》（更新 2026.03.04 / 2026.09.01）及合作伙伴文档中心更新日志。
2026-01：合单支付字段描述调整
受影响接口：
- 《App合单下单》
- 《H5合单下单》
- 《JSAPI合单下单》
- 《Native合单下单》
- 《小程序合单下单》
- 《查询合单订单》
- 《关闭合单订单》
- 《合单订单支付成功回调通知》
请求/返回参数变更：
- 原字段
sub_orders（子单信息列表）更名为sub_orders（商品单信息）。 - 原字段
out_trade_no（子单商户订单号）更名为out_trade_no（商品单商户订单号）。
注意：字段名 sub_orders、out_trade_no 本身未变，只改了语义/描述（“子单”改“商品单”）。
服务端影响：
- JSON 解析 key 不变，反序列化代码不需要改字段名。
- 日志、对账报表、内部字段注释如果使用“子单”概念，应同步为“商品单”，避免运营/客服按旧文档理解。
- 回调解析《合单订单支付成功回调通知》时，仍按
sub_orders、out_trade_no取数，不要因为文档中文描述变化而重命名字段或改 JSON 路径。
2026-09：合单支付 description 长度与描述调整
sub_orders.description长度由 128 改为 127。combine_out_trade_no、out_trade_no字段描述去掉 @ 符号。
影响：
- 入参校验、SDK 封装、测试用例中的长度限制要从 128 调整为 127；继续按 128 放行会与文档不一致。
- 数据库若已使用
varchar(128)不必仅因此改表，但服务端校验边界应按 127。 combine_out_trade_no、out_trade_no改的是字段描述，不是字段名或值格式；不要据此调整参数拼接。- 对账/日志中若记录
description，注意截断和报表列宽按 127 处理。
2026-09：退款返回参数 user_received_account 展示调整
受影响接口：
- 《申请退款》
- 《查询单笔退款（通过商户退款单号）》
- 《发起异常退款》
- 《退款结果通知》
变更：返回参数 user_received_account 字段优化退款入账账户银行卡展示形式：
- 原银行卡返回格式：
{银行名称}{卡类型}{卡尾号} - 调整后：
{银行名称}{卡类型}，不再展示卡尾号。
更早变更：user_received_account 陆续新增入账方式（用户分付、微银通退款、小金罐退款）。
对账/日志影响：
- 不能再从
user_received_account解析银行卡尾号；原有按尾号做匹配、核对、报表拆列的规则会失效。 - 对账若依赖卡尾号，需要检查是否有其他可用字段或改走其他核对维度。
- 日志展示会少卡尾号，脱敏压力降低，但日志解析正则、告警规则要同步去掉尾号段。
回调解析注意：
- 《退款结果通知》中的
user_received_account可能是银行卡，也可能是用户分付、微银通退款、小金罐退款等入账方式。 - 不要用固定“银行名称+卡类型+卡尾号”的三段结构或尾号正则去解析；按字符串展示或按已知入账方式枚举处理更合适。
其他 2026-09 与 2025-03 更新
- 2026-09 上线《AI支付》能力、《医保一码付》能力。
- 微信支付分
materiel_no由“物料编码”更名为“物料URL”。字段名不变，涉及该参数的注释、日志文案和校验说明需要同步。 - 2025-03 微信支付分停车《扣费受理》
currency调整为非必填。请求校验如果仍强制必填，需要放宽。 - 商家转账错误码新增
FREQUENCY_LIMIT_EXCEED、RATELIMIT_EXCEEDED等；商家转账接口频率限制 100 次/s。错误处理和重试策略应覆盖限流类错误。 - 微信支付 APIv3 提供 Java、PHP、GO 开发库，封装签名生成/验证、敏感信息加解密、媒体文件上传。