直付通进件报错 CTU_FAIL_MERCHANT_IN_BACKLIST 的原因

2026-10-24支付阿杰

结论

CTU_FAIL_MERCHANT_IN_BACKLIST 表示这次直付通进件触发了准入风控。仅凭这个错误码，不能断定二级商户的支付宝账户被拉黑，也不能直接判断问题来自服务商整体风险。

如果多个商户同时失败，但当面付签约正常，应先检查这些商户在直付通链路中是否使用了相同或关联的信息，以及服务商与商户之间的接入关系。不同产品有各自的准入规则、风险维度和审核标准，当面付可以签约，不代表直付通进件一定能够通过。

接口通常不会返回具体命中的规则。要进一步定位，需要准备完整的请求信息，联系支付宝直付通技术支持，或通过对应的风控申诉渠道核查。

常见原因

1. 直付通与当面付的准入标准不同

当面付签约成功，只能说明商户符合当面付当时的准入要求。直付通涉及二级商户管理、资金结算和服务商责任，可能采用独立的风控模型。

同一商户可能遇到以下情况：

当面付已经开通，但直付通进件被拒绝；
支付宝账户本身状态正常，但商户主体不符合直付通准入要求；
已开通的产品可以继续使用，但新增产品或合作关系受到限制。

因此，不能根据当面付的签约结果推断直付通的审核结果。

2. 多个商户存在共同风险特征

十几个商户同时失败，不一定表示十几个账户各自存在异常。如果它们共享某些信息，就可能同时触发同一条风险规则，例如：

使用相同的联系人、手机号或邮箱；
使用相同或高度关联的结算账户；
法定代表人、实际控制人或受益所有人存在关联；
营业地址、经营地址、门店照片或经营场景高度重复；
使用相同的网站、App、小程序或域名；
商户简称、经营内容或证照材料有批量套用的痕迹；
主体、支付宝账户、结算人或历史商户之间存在风险关联；
短时间内集中提交大量相似的进件申请。

风险系统通常不只检查 merchant_user_id，还可能综合判断主体、人员、结算、设备、场景和历史记录等信息。

3. 服务商账户正常，但接入关系受限

“服务商账户没有风险”和“当前直付通进件链路没有限制”并不是同一个结论。

客服或服务商管家确认的账户状态，可能只涉及服务商主体或支付宝账户本身。以下事项仍需由直付通业务侧确认：

服务商是否具备当前直付通模式所需的有效准入资格；
服务商使用的 app_id、PID 或产品签约关系是否正确；
当前行业、商户类型或业务场景是否在允许范围内；
服务商与二级商户的合作关系是否触发渠道级限制；
服务商是否受到直付通维度的阶段性准入限制；
二级商户进件能力是否已经正确开通并生效。

这不代表服务商一定属于“高风险间连机构”，只是普通的账户状态查询无法排除产品、渠道或合作关系方面的问题。

4. 进件资料或业务场景不符合要求

部分资料问题也可能被风险系统统一返回为准入失败，例如：

营业执照状态异常、已经注销或即将过期；
商户名称、统一社会信用代码与证照不一致；
法定代表人身份信息不一致或证件已经失效；
经营类目与营业执照或门店场景不符；
经营范围属于受限行业，或需要提供特殊资质；
网站、App 或门店无法验证真实经营情况；
证照图片重复、模糊、裁剪严重或有修改痕迹；
商户支付宝账户没有完成必要的实名认证，或认证主体与进件主体不一致。

是否属于这些情况，要结合实际调用的接口和直付通最新准入规则判断，不能只看错误码。

5. 请求主体或参数映射错误

如果多个进件请求由同一套程序批量生成，还要检查程序是否错误复用了部分字段。常见问题有：

所有请求误传了同一个二级商户账户；
商户编号与商户支付宝账户对应错误；
服务商 PID、应用 app_id 或授权关系使用错误；
请求流水号被重复使用；
测试环境和生产环境的主体信息混用；
同一商户存在未完成或已经失败的历史申请；
更新申请时误用了新增进件接口，或申请单之间产生了错误关联。

如果所有请求从同一时间开始失败，应重点检查近期是否改动过公共配置、字段映射或批量导入模板。

建议的排查步骤

第一步：做一组差异化对照

先暂停批量重试，选择少量商户做对照：

选择一个主体、法人、联系人和结算账户都完全独立的商户。
选择一个此前已经成功进件的商户，检查同一链路现在是否仍可使用。
对比成功和失败请求中的服务商 PID、app_id、商户账户、主体证件、联系人、结算信息及经营场景。
检查失败商户是否共享联系人、法人、地址、结算账户、域名或设备环境。

如果信息完全独立的商户仍然全部失败，历史成功商户也无法提交新申请，那么服务商接入关系或产品通道受到限制的可能性会明显增加。

第二步：保存完整请求与响应

每笔失败申请至少要保留以下信息：

调用的 API 名称；
精确到秒的请求时间；
app_id 和服务商 PID；
商户侧请求流水号，如 out_request_no；
二级商户支付宝账户或商户标识；
商户主体名称和统一社会信用代码；
返回的 code、msg、sub_code、sub_msg；
支付宝返回的申请单号、请求 ID 或链路 ID；
脱敏后的完整请求参数；
申请类型，包括首次申请、修改申请或重复提交。

不要只提交错误码截图。如果缺少请求流水号、时间和主体信息，支持人员通常很难定位对应的风控记录。

第三步：检查批量请求代码

下面是示意代码，字段名应以实际调用的接口和当前支付宝 SDK 为准。记录这些信息是为了方便支付宝定位问题，不是为了绕过风控。

AlipayResponse response = alipayClient.execute(request);

log.info(
    "directPayMerchantApply result: appId={}, outRequestNo={}, " +
    "merchantUserId={}, code={}, msg={}, subCode={}, subMsg={}",
    mask(appId),
    outRequestNo,
    mask(merchantUserId),
    response.getCode(),
    response.getMsg(),
    response.getSubCode(),
    response.getSubMsg()
);

// 在安全日志中保存脱敏后的请求参数。
// 身份证号、手机号、银行卡号、证照图片地址等信息不得明文输出。
saveAuditRecord(
    outRequestNo,
    sanitize(request.getBizContent()),
    response.getBody()
);

还要检查公共字段是否被意外写成固定值：

app_id                  是否属于当前服务商及生产环境
merchant_user_id        是否对应本次二级商户
out_request_no          是否每次业务申请唯一
merchant_name           是否与证照主体一致
business_license_no     是否传错或在多笔请求中重复
contact_info            是否被模板统一覆盖
settle_info             是否误用了同一结算主体

不要不断更换账号、联系人或请求流水号来试探风控规则。这类操作可能增加关联风险，也会给后续申诉带来困难。

如何提交核查或申诉

建议通过支付宝开放平台中对应应用的技术支持工单，明确申请核查“直付通二级商户进件准入风控”，不要只查询服务商支付宝账户是否正常。

工单可以这样填写：

服务商账户经服务商管家确认状态正常，但多个相互独立的二级商户在
直付通进件时均返回 CTU_FAIL_MERCHANT_IN_BACKLIST。

这些商户签约其他产品正常，现申请核查以下范围：

1. 服务商在直付通产品、应用和渠道维度是否存在准入限制；
2. 服务商与二级商户的合作关系是否命中风险限制；
3. 错误命中的是二级商户账户、商户主体、关联人员、结算信息，
   还是服务商/渠道维度；
4. 当前情况应按哪个申诉类型提交，以及需要补充哪些证明材料。

附：app_id、服务商 PID、API 名称、请求时间、out_request_no、
二级商户标识、完整错误信息及脱敏请求参数。

如果支持人员仍然只回复“服务商账户正常”，可以要求其将工单转交给直付通产品或准入风控团队，并确认核查范围是否包括：

直付通产品权限；
当前应用和服务商 PID；
服务商与二级商户的关联关系；
二级商户主体及其关联主体；
渠道级或机构级准入状态。

如果官方判定问题出在二级商户准入，应按准入申诉页面的要求，逐户提交真实、完整的经营证明。如果问题出在服务商或接入关系，应由服务商主体发起申诉，不必让十几个二级商户分别重复申诉。

注意事项

CTU_FAIL_MERCHANT_IN_BACKLIST 中的 BACKLIST 是错误码的原始拼写，接入系统中不要自行改成 BLACKLIST。
账户状态正常，不代表所有产品和风险维度都正常。
不同产品的审核结果可能不一致。当面付签约成功，不能作为直付通必然准入的依据。
不要通过修改真实主体信息、借用其他联系人或更换结算账户来规避审核。
工单和日志中的身份证号、银行卡号、手机号等敏感信息必须脱敏。原始材料应通过官方安全入口提交。
在支付宝给出具体核查结论前，仅凭这个错误码无法判断是二级商户、关联主体、服务商还是渠道维度触发了风险。先对照共同字段，再带上可用于定位的请求流水信息申请产品侧核查。