直付通二级商户进件未传binding_alipay_logon_id报错

结论

即使请求参数相同，服务端采用的进件规则也可能不同。ant.merchant.expand.indirect.zft.create 会根据调用方支付宝账号、应用、直付通产品签约状态、二级商户确认模式和历史兼容配置进行校验。

账号1出现”身份指定支付宝账号为空”，通常表示当前进件模式要求指定二级商户绑定的支付宝登录账号，因此不能省略 binding_alipay_logon_id。账号2可以不传该字段，可能是因为沿用了历史存量配置、白名单或不同的商户确认模式，但这不能证明该字段对账号1同样可选。

仅凭报错无法确定是哪项后台配置导致了差异。需要支付宝技术支持结合账号、应用和请求流水，查询实际命中的产品规则。

可能存在的差异

1. 签约的产品能力不同

签约《互联网直付通解决方案》，不一定表示账号已经具备全部二级商户进件能力。解决方案签约、应用绑定、接口权限、二级商户创建能力和支付产品开通，可能分别对应不同的状态。

账号1仍在对接阶段，可能存在以下情况：

• 直付通签约尚未完全生效；
• 二级商户进件产品没有正式开通；
• 签约产品尚未绑定到调用接口的当前应用；
• 应用的 app_id 不在已开通能力的授权范围内；
• 已签约解决方案，但尚未配置相应的二级商户确认模式。

账号2已经运行多年，产品能力和应用配置可能早已完整生效。

2. 二级商户的身份确认模式不同

直付通进件可能涉及二级商户身份确认、支付宝账号绑定或协议确认。确认模式不同，binding_alipay_logon_id 的要求也可能不同。

账号1命中的规则可能是：

1. 请求中必须提供 binding_alipay_logon_id；
2. 系统向该支付宝账号发起身份确认或协议确认；
3. 二级商户确认后，再进入后续流程。

如果没有传入绑定账号，服务端无法确定由哪个支付宝账号完成确认，因此返回”身份指定支付宝账号为空”。

账号2无须商户操作协议确认，可能使用了另一种确认方式，也可能仍在使用历史存量流程。这类差异通常来自服务端配置，不会直接体现在请求报文中。

3. 账号2可能有历史兼容配置

ant.merchant.expand.indirect.zft.create 是旧版创建接口。已经上线多年的账号可能保留了旧流程，包括：

• 存量商户接入模式；
• 历史白名单；
• 免确认或平台代确认配置；
• 对 binding_alipay_logon_id 的兼容性校验；
• 旧产品签约迁移后的特殊配置。

新签约账号一般按当前规则开通，不一定继承旧账号的兼容策略。即使两个账号属于同一主体，产品权限、白名单和风控配置也不会自动复制。

4. 调用应用或应用绑定关系不同

除了支付宝主账号，还需要比较实际发起请求的应用：

• app_id 是否相同；
• 应用是否分别绑定到对应的直付通签约账号；
• 应用类型和上线状态是否相同；
• 接口权限是否相同；
• 是否使用了不同的公钥证书、授权令牌或网关环境。

服务端通常会根据 app_id 和签约主体识别调用方。如果账号1使用新应用，账号2使用存量应用，那么即使业务参数完全一致，也可能进入不同的产品配置和校验链路。

5. 商户类别或进件资料触发了不同规则

还应确认两次请求除 binding_alipay_logon_id 外是否真的完全一致，尤其要核对：

• 主体类型；
• 证件类型；
• 商户经营类别；
• 联系人及法人信息；
• 结算账户类型；
• 二级商户是否已有支付宝账号；
• 外部商户编号是否曾经进件；
• 商户主体是否命中重复进件或身份合并规则。

某些字段组合可能触发”指定支付宝账号绑定”流程。只比较接口名称和主要业务字段，并不足以排除两次请求进入了不同的规则分支。

建议的处理步骤

第一步：为账号1补充绑定账号进行验证

如果二级商户已有支付宝账号，可以先确认账号归属和授权方式符合产品要求，再传入 binding_alipay_logon_id。

以下是示意请求。具体字段仍应以账号1当前开放平台接口文档和产品配置为准：

{
  "external_id": "MERCHANT_202609090001",
  "name": "示例商户",
  "alias_name": "示例门店",
  "service_phone": "4000000000",
  "binding_alipay_logon_id": "merchant@example.com"
}

binding_alipay_logon_id 一般填写二级商户实际使用的支付宝登录账号，不能填写服务商账号、应用 app_id 或商户 PID。登录账号可能是手机号或邮箱，可接受的具体格式以接口当前校验规则为准。

不要为了避开报错而填写无关账号。账号绑定错误可能导致确认通知发给错误对象，也可能使主体一致性校验失败。

第二步：确认字段确实传到了网关

检查时要看序列化后的最终请求，不能只看业务对象是否已经赋值。常见问题包括：

• 字段值是空字符串；
• 字段被 JSON 序列化配置过滤；
• 使用了错误的字段名；
• 字段位于错误的对象层级；
• SDK 版本对应的请求模型不包含该字段。

Java 中可以在发送前检查业务参数：

AlipayClient alipayClient = new DefaultAlipayClient(
    gatewayUrl,
    appId,
    privateKey,
    "json",
    "UTF-8",
    alipayPublicKey,
    "RSA2"
);

AlipayRequest<?> request = createZftRequest();

Map<String, Object> bizContent = new HashMap<>();
bizContent.put("external_id", "MERCHANT_202609090001");
bizContent.put("name", "示例商户");
bizContent.put("binding_alipay_logon_id", "merchant@example.com");

request.setBizContent(JSON.toJSONString(bizContent));

AlipayResponse response = alipayClient.execute(request);
System.out.println(response.getCode());
System.out.println(response.getSubCode());
System.out.println(response.getSubMsg());

这里的 createZftRequest() 只是占位写法，需要替换为当前 SDK 中与 ant.merchant.expand.indirect.zft.create 对应的实际请求类，不能直接作为完整代码运行。

第三步：逐项比较两个账号的后台状态

可以整理一份对照表，交给产品运营或支付宝技术支持核查：

排查重点不只是”接口文档中该字段是否必填”，而是下面这个问题：

账号1对应的 app_id 和直付通签约配置，实际命中了哪一种二级商户身份确认模式？该模式是否强制要求传入 binding_alipay_logon_id？

第四步：向支付宝提交完整的排查信息

如果账号1原本应开通免确认模式，或者补充字段后仍然失败，应提交以下信息：

• 账号1和账号2对应的支付宝商户号或 PID；
• 两个应用的 app_id；
• 接口名称 ant.merchant.expand.indirect.zft.create；
• 失败请求的网关请求时间；
• trace_id、请求流水号或响应中的诊断标识；
• 完整的 code、sub_code、sub_msg；
• 脱敏后的最终请求报文；
• 两个账号的产品签约页面截图；
• 账号2免协议确认的历史接入说明。

技术支持需要通过后台日志确认规则来源。客户端通常无法判断差异来自产品订单、应用绑定、白名单还是存量兼容配置。

注意事项

1. 不建议直接把账号2的运行表现当作账号1的接入标准。账号2上线较早，很可能适用存量规则。

2. APP支付签约状态和直付通二级商户进件规则不是同一项能力。账号2开通了APP支付，不能单独解释它为什么可以省略 binding_alipay_logon_id。

3. 如果账号1采用需要商户确认的模式，传入绑定账号后，二级商户仍可能需要完成协议或身份确认。这是流程要求，不一定表示接口异常。

4. 旧接口可能继续向存量账号开放，但新账号未必适用完全相同的规则。还应确认是否已有推荐的新接口或新进件方案。在取得官方迁移说明前，不要自行替换生产接口。

5. 如果问题描述中的”账号2二级商户进件均为传入 binding_alipay_logon_id”实际是指”均未传入”，应在工单中明确说明。是否传入该字段，是判断账号2是否存在历史兼容配置的重要依据。

建议优先核查账号1的二级商户身份确认模式、产品与 app_id 的绑定关系，以及账号2是否有历史免确认配置。只要这三项没有对齐，即使请求报文完全相同，也可能得到不同的校验结果。

备注：内容仅供参考。