支付宝小程序订单与分账接口 2026 年字段变更：新增政府补贴字段、退凭证信息，分账 out_request_no 扩到 64 位

本文整理的两份文档更新日志：

• 小程序交易组件：
• 商家分账：

字段名、枚举值、日期均照抄支付宝开放平台更新日志，未做实测验证。接入前建议以文档当前页面为准。

小程序订单查询与结果通知

alipay.open.mini.order.query（订单查询）在 2026-04-21 的更新中，响应参数新增三个字段：

• apple_iap_api：苹果 IAP 支付 API 类型
• government_total_amount：政府补贴汇总
• government_promo_detail：政府补贴详情

也就是说，走苹果 IAP 渠道的订单，以及涉及政府补贴的订单，在查询结果里会多出这几项。以前这类信息要么拿不到，要么得自己从其他字段拼。现在查询响应里直接给出补贴汇总和明细，对账口径可以少一层推导。apple_iap_api 用来标识 IAP 的 API 类型，判断订单是不是 IAP 支付时可以直接读这个字段。

订单结果通知 alipay.open.mini.order.changed 在 2026-04-17 前后，请求参数新增 apple_iap_api（苹果 IAP 支付 API 类型）。通知链路和查询链路在这一项上对齐了。

另外两个较早的变更：

• 2025-07，alipay.open.mini.order.query 业务响应参数中 ext_info.remark_color_flag（卖家备注旗标颜色）字段被修改，新增枚举类型。
• 综合风险模型相关字段 comprehensive_risk_models、risk_level_type 增加 Tn_Level 枚举。

售后单

alipay.open.mini.order.aftersale.query 业务响应参数新增：

• discount_amount：优惠总金额，标识当前售后单退款金额中含优惠部分的总金额
• funds_details：退款资金明细，标识当前售后单退款金额中的资金构成明细

这两个字段解决的是"这笔退款里有多少是优惠、多少是实付资金"的问题。之前只能拿退款总额，退款的资金构成和优惠分摊需要自己在业务侧算。

alipay.open.mini.order.aftersale.create 业务请求参数新增 certificate_infos（退凭证信息），标识当前需要进行退款的凭证信息。创建售后单时如果要带退款凭证，走这个字段。

商家分账

alipay.trade.order.settle 相关的变更集中在这几处。

2025-08-25：alipay.trade.order.settle 业务变更参数 out_request_no，字段描述中的长度由 32 改到 64。原先按 32 位截断或校验的请求号生成逻辑需要放宽，否则新长度下可能误判为非法值。

2025-07-31：修改 trans_in_type，增加枚举 openId；同时修改 trans_in，描述增加"如果收入方类型为 openId，本参数为收入方的支付宝 openId 信息"。同一天，业务错误码 ACQ.PARTNER_ERROR 的解决方案调整为：APP_ID 不是上线状态，请上线后再调用；或请求中的 pid 信息和交易信息中的 pid 不匹配，请更换交易所属账号下的应用调用。

再往前：

• 2025-01-22，分账接收方授权新增退分账，新增分账接收方授权。
• 2024-12-17，alipay.trade.order.settle.query 业务响应参数 royalty_detail_list（分账明细）从必选改为可选；alipay.trade.royalty.relation.batchquery 的 out_request_no 与 receiver_list 从必选改为可选。
• 2024-11-15，alipay.trade.order.settle 更新 royalty_parameters（分账条款）字段，增加可选类型；业务错误码新增 ALREADY_FINISH_ALLOC（分账资金解冻失败，已无冻结资金可解冻）。
• 2023-07-31，商家分账超时自动解冻：若商家不主动发起分账解冻请求，系统默认 30 天后将剩余资金解冻。商户可通过监听 alipay.trade.order.settle.notify（交易分账结果通知）接收通知，其中 msg_type = AUTO_SETTLE_FINISH 代表超期自动分账解冻。

30 天这条容易漏。分账如果一直不主动解冻，到期系统会自己解冻，资金状态在商户侧如果没有对应的监听处理，账面和实际就会不一致。AUTO_SETTLE_FINISH 这个 msg_type 要单独分支处理，不能只按常规分账成功逻辑走。

对接建议

这次变更里，字段新增和枚举新增占了大头。反序列化时建议对未知枚举和未知字段做宽容解析，不要写死 switch 到默认就抛异常，也不要因为响应里多出一个没见过的 key 就解析失败。比如 trans_in_type 增加 openId 之后，老代码里只认原有枚举值的分支会直接落到异常路径；risk_level_type 新增 Tn_Level 同理。这类字段更适合"能识别就处理，识别不了就原样透传并记录"，把异常留到业务真正需要该字段时再判断。

out_request_no 从 32 到 64 属于兼容性变更，长度校验、数据库字段长度、唯一索引长度都要跟着检查一遍，尤其是用这个字段做索引或存储的场景。