---
url: "https://pay.weixin.qq.com/doc/v3/partner/4020807427.md"
title: "错误码"
doc_id: 4020807427
---

>更新时间：2026.06.12

# 商户开户意愿确认错误码



## 一、错误码速查表（TOP 20）

| 错误码 | 错误信息 |
| --- | --- |
| 268435463 | 参数过短 |
| 270924289 | 频率过快 |
| 269755393 | 申请单状态不匹配 |
| 269755408 | 商户关系不存在 |
| 269546505 | 商户证书已过期 |
| 269755397 | 查询申请单不存在 |
| 268435461 | 参数非法 |
| 269755396 | 提交申请单失败 |
| 268472951 | API 请求参数检查不合法 |
| 270924291 | 头部信息不完整 |
| 269546538 | 商户号不存在 |
| 269755405 | 该申请单不属于当前服务商 |
| 269755403 | applyment\_id 和 business\_code 都未设置 |
| 269755445 | 待确认商户号列表字段校验失败 |
| 269546507 | 商户证书序列号有误 |
| 269546525 | 错误的签名，导致验签失败 |
| 270924332 | 认证信息解析失败 |
| 270924333 | 时间戳距离当前时间超过 5 分钟 |
| 270924346 | 签名信息非法 |
| 270924358 | 参数中含有非法的额外参数 |

* * *

## 二、错误码详细排查

### 268435463 — 参数过短

排查步骤：

1. 看响应体 `message` 与 `detail.field` 定位具体过短字段

2. 字段值前后先 trim 再校验长度，空格不算字符

3. 加密字段加密前长度满足要求即可

4. 地址类字段需填完整地址，不要用「无」「-」等占位符

5. 业务侧本地 schema 校验每个字段的 `minLength` / `maxLength`


* * *

### 270924289 — 频率过快

排查步骤：

1. 提交申请单上限为 5 QPS（商户号维度）；查询申请单上限为 20 QPS

2. 查询申请单状态建议指数退避（5s → 30s → 1min → 5min），不要等间隔轮询

3. 收到 270924289 后至少等 1 秒再重试，连续多次报错则退避到 30 秒+

4. 批量进件场景：业务侧排队消费，控制每秒 ≤ 5 个提交申请单

5. 多实例部署用集中式限流做全局 QPS 控制


* * *

### 269755393 — 申请单状态不匹配

排查步骤：

1. 调「查询申请单审核结果」获取当前 `applyment_state`

2. 允许撤销的状态： `EDITTING` / `WAITTING_FOR_AUDIT` / `WAITTING_FOR_CONFIRM_CONTACT` / `WAITTING_FOR_CONFIRM_LEGALPERSON`

3. `PASSED` / `FREEZED` 状态不可撤销

4. 驳回后必须用新的 `business_code` 重提（与特约商户进件不同，不能用同一编号覆盖）

5. 业务侧严格按状态机操作，不要假设状态


* * *

### 269755408 — 商户关系不存在

排查步骤：

1. 渠道商调用直接使用自己的服务商商户号签名，不传 `channel_id`

2. 从业机构调用必须传 `channel_id` 且该商户号属于本机构

3. 提交申请单前确认 `confirm_mchid_list` 中所有商户号确实归属当前服务商

4. 报错文案会列出具体哪些商户号有问题，按格式（如标点符号）筛选过滤后重新提交

5. 检查商户号是否已经被解约 / 注销


* * *

### 269546505 — 商户证书已过期

排查步骤：

1. 登录服务商商户平台 → 账户中心 → API 安全 → API 证书，查看到期时间

2. 重新申请并下载新证书，更新到所有服务节点

3. 建议在证书过期前 30 天监控告警

4. 长期方案可迁移到微信支付公钥体系


* * *

### 269755397 — 查询申请单不存在

排查步骤：

1. 打印请求 query 参数，确认 `applyment_id` / `business_code` 与本地存储一致

2. `applyment_id` 是 integer，不要序列化成字符串； `business_code` ≤ 128 字符

3. 提交申请单成功后返回的 `applyment_id` 立即落库，后续查询用这个 ID 更稳定

4. 用同一个服务商商户证书查询，不要跨服务商


* * *

### 268435461 — 参数非法

排查步骤：

1. 看响应体 `message` 与 `detail.field` 定位具体错误字段

2. 必填字段不能漏： `business_code`、 `contact_info`、 `subject_info`、 `identification_info`

3. 主体类型枚举： `SUBJECT_TYPE_ENTERPRISE` / `SUBJECT_TYPE_INSTITUTIONS_CLONED` / `SUBJECT_TYPE_INDIVIDUAL` / `SUBJECT_TYPE_OTHERS` / `SUBJECT_TYPE_MICRO` / `SUBJECT_TYPE_GOVERNMENT`

4. 联系人类型： `LEGAL` / `SUPER`；小微只能用 `LEGAL`

5. 检查敏感字段是否加密（姓名 / 身份证号 / 手机号 / 地址等必须用微信支付公钥加密）

6. 加密算法： `RSA/ECB/OAEPWithSHA-1AndMGF1Padding`

7. `Wechatpay-Serial` 头必须与加密所用公钥匹配

8. 不同主体类型必填字段不同，参照官方文档对照


* * *

### 269755396 — 提交申请单失败

排查步骤：

1. 看响应体 `message` 是否带有更具体的子错误描述

2. 使用相同 `business_code` 重试（接口支持幂等）：5s → 30s → 1min 指数退避

3. 重试前先调「查询申请单审核结果」确认实际状态——可能上次其实成功了

4. 若多次重试都失败可切换备域名重试（ `api2.mch.weixin.qq.com`）


* * *

### 268472951 — API 请求参数检查不合法

排查步骤：

1. 用 JSON 校验工具校验请求体格式

2. 对照官方接口规范确认字段层级结构

3. 数组字段必须是数组（如 `special_operation_list` / `ubo_info_list`）

4. `Content-Type` 必须与 body 实际格式匹配

5. 使用官方 SDK 构造请求体可避免结构错误


* * *

### 270924291 — 头部信息不完整

排查步骤：

1. 打印实际发送的所有请求头检查

2. 必填请求头： `Authorization` / `Accept` / `User-Agent`，POST 还需 `Content-Type`

3. 含敏感字段的「提交申请单」接口必填 `Wechatpay-Serial` 头

4. 查询接口不需要 `Wechatpay-Serial` 与 `Content-Type`


* * *

### 269546538 — 商户号不存在

排查步骤：

1. 仔细核对商户号（10 位纯数字），前后不能有空格

2. 区分签名所用 `mchid` 与 `channel_id`（从业机构场景）

   - 渠道商：签名 `mchid` 即可，不传 `channel_id`

   - 从业机构：签名用机构 `mchid`，body 中 `channel_id` 是旗下渠道商户号
3. 检查请求头 `Authorization` 中签名使用的 `mchid` 与代码中传递的 `mchid` 是否一致


* * *

### 269755405 — 该申请单不属于当前服务商

排查步骤：

1. 检查请求头 `Authorization` 中签名使用的 `mchid` 是否是真正提交了该申请单的 SP 商户号

2. 翻提交申请单时的请求日志，找到当时使用的 `mchid` 与当前调用方对照

3. 多 SP 商户号场景，业务侧做好「申请单 → 提交 SP 商户号」映射

4. 不允许跨服务商访问


* * *

### 269755403 — applyment\_id 和 business\_code 都未设置

排查步骤：

1. 打印实际请求的完整 URL，检查 query 段

2. 标准 URL： `GET /v3/apply4subject/applyment?applyment_id=xxx` 或 `?business_code=xxx`，两者至少传一个

3. 参数必须在 URL query 中，不要放到 body 里

4. 业务侧封装查询方法时强制非空参数校验


* * *

### 269755445 — 待确认商户号列表字段校验失败

排查步骤：

1. 解析响应中的 `message`，按分号拆分每个商户号 → 错误原因

2. 业务侧筛选过滤逻辑建议根据标点符号格式（分号、冒号）拆分提取商户号，不要根据具体文案匹配（文案可能调整）

3. 剔除报错的商户号后重新提交申请单

4. 提前校验：

   - 商户号格式为纯数字

   - 数量 ≤ 20

   - 是否归属当前服务商
5. `confirm_mchid_list` 可不传，后续让商家扫码后再选择授权商户


* * *

### 269546507 — 商户证书序列号有误

排查步骤：

1. 用 OpenSSL 提取证书序列号确认： `openssl x509 -in apiclient_cert.pem -noout -serial`

2. 把输出中 `serial=` 后面的部分（去掉冒号、不要 `0x` 前缀）填到 `Authorization.serial_no`

3. `serial_no` 是商户 API 证书序列号，不是平台证书序列号

4. 推荐使用官方 SDK 自动管理证书序列号


* * *

### 269546525 — 错误的签名，导致验签失败

排查步骤：

1. 完整打印「签名前的待签名串」与「实际请求 body」

2. 签名串拼接： `HTTP方法\nURL路径(含 query)\n时间戳\n随机串\n请求体\n`（GET 请求 body 为空字符串，末尾仍要 `\n`）

3. 查询接口签名时 URL 必须包含 query： `/v3/apply4subject/applyment?applyment_id=xxx`

4. 核对 `apiclient_key.pem` 是当前 SP 商户号对应的私钥

5. 中间链路（如 Nginx / API 网关）禁止改写 body

6. 建议使用官方 SDK


* * *

### 270924332 — 认证信息解析失败

排查步骤：

1. 打印完整 `Authorization` 头，逐字段检查

2. `timestamp` 必须 10 位整数秒

3. `nonce_str` 建议 \[A-Za-z0-9\] 随机串，32 位以内

4. `signature` 是标准 Base64 编码（不是 URL-Safe，不能有换行）

5. 字段间用英文逗号分隔，字段值用英文双引号包裹

6. 建议使用官方 SDK 自动生成 Authorization


* * *

### 270924333 — 时间戳距离当前时间超过 5 分钟

排查步骤：

1. 服务器执行 `date -u` 确认 UTC 时间正确

2. 配置 NTP 同步（如 `chrony` / `ntpd`），保证误差 < 1 分钟

3. `timestamp` 必须是调用接口时点的 Unix 秒级时间戳（10 位）

4. 每个请求实时生成 Authorization，不要缓存复用

5. 容器化部署确认容器时钟与宿主机一致


* * *

### 270924346 — 签名信息非法

排查步骤：

1. `Authorization` 头必须以 `WECHATPAY2-SHA256-RSA2048 ` 开头（注意空格）

2. 必须包含五个字段： `mchid` / `nonce_str` / `signature` / `timestamp` / `serial_no`

3. 字段间用英文逗号分隔，字段值用英文双引号包裹

4. `signature` 必须是标准 Base64 编码（非 URL-Safe）

5. `serial_no` 是当前商户 API 证书的序列号（不是平台证书）

6. 建议使用官方 SDK 自动生成 Authorization


* * *

### 270924358 — 参数中含有非法的额外参数

排查步骤：

1. 看响应体 `message` 与 `detail.field` 定位多余字段

2. 字段名是下划线风格 `snake_case`，不是驼峰 `camelCase`

3. 已下线字段不要再传（如 `subject_info.ubo_info_list` / `identification_info.owner` / `contact_info.business_authorization_letter`）

4. 业务侧请求 body 序列化时使用「白名单字段」，过滤掉额外字段

5. 升级到最新 SDK 可自动避开已下线字段