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

>更新时间：2026.06.12

# 微信电子发票错误码



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

| 错误码 | 错误信息 |
| --- | --- |
| 271962114 | 业务成功（非 0 但属正常业务态） |
| 273808905 | 请求正在处理中 |
| 268470903 | 发票申请单不存在 |
| 268435463 | 参数过短 |
| 268577873 | 新增发票请求与历史发票请求相同（重复请求） |
| 268436152 | 请求参数不满足业务要求 |
| 269546538 | 商户号不存在 |
| 268565253 | 请求数电接口获取企业状态接口返回结果处理错误 |
| 268470902 | 用户尚未提交抬头 |
| 268435461 | 参数非法 |
| 268436172 | 要查询的发票不存在 |
| 268435483 | 数据不存在 |
| 268552457 | 商户信息内未找到数电开票人信息 |
| 268578415 | 交易信息当前状态不可重试 |
| 271942234 | 已经插卡成功，无须重复插卡 |
| 268564709 | 服务商获取邀请商户信息参数错误 |
| 268436173 | 商户未同意开票申请，无法进行当前操作 |
| 268513837 | 商户未设置开票平台 |
| 270924345 | content-type 不正确 |
| 268574945 | 交易单剩余可开票金额不足 |

* * *

## 二、错误码详细排查

### 271962114 — 业务成功（非 0 但属正常业务态）

排查步骤：

1. 该错误码不是真正的失败，业务侧应识别为「成功」处理

2. 检查响应体 `data` / `fapiao_information` 中的实际业务状态字段

3. 不要把 271962114 计入错误率指标


* * *

### 273808905 — 请求正在处理中

排查步骤：

1. 微信电子发票所有写操作（开票 / 冲红 / 插卡）都是异步的，该状态为正常中间态

2. 通过监听回调通知或主动调「查询电子发票」接口获取最终结果

3. 轮询策略：1s → 3s → 10s → 30s 指数退避

4. 长时间未完成不要重发开票请求，会触发重复请求错误


* * *

### 268470903 — 发票申请单不存在

排查步骤：

1. 检查 `fapiao_apply_id` 是否传错（被截断 / 编码污染 / 大小写）

2. 服务商场景下注意 `sub_mchid` 与 `fapiao_apply_id` 必须匹配

3. 开票接口刚调用后立即查询可能有秒级延迟，建议 2-3 秒后再查

4. 业务侧应在调开票接口后立即把 `fapiao_apply_id` 落库


* * *

### 268435463 — 参数过短

排查步骤：

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

2. 不要传空串 `""`，可选字段直接不传 key

3. 业务侧入参做长度校验


* * *

### 268577873 — 新增发票请求与历史发票请求相同（重复请求）

排查步骤：

1. 不要把这个错误当作失败处理——首次请求大概率已成功受理

2. 调「查询电子发票」接口确认实际状态：

   - `ISSUE_ACCEPTED`：等待异步处理完成

   - `ISSUED`：开票成功

   - `ISSUE_FAILED`：换一个新的 `fapiao_id` 重试（不要换 `fapiao_apply_id`）
3. 接口幂等性：同 `fapiao_apply_id` 重复调用应返回相同结果

4. 网络超时时先查询再决定是否重发


* * *

### 268436152 — 请求参数不满足业务要求

排查步骤：

1. 首要：查看响应体 `message` 与 `detail.message` 字段——业务规则错误的具体原因都在这里

2. 常见业务规则：

   - 所有发票的 `total_amount` 之和不能超过交易总金额

   - 金额单位为分，数量单位为 `10^-8`（1 = `100000000`），单价单位为 `10^-6 分`（1 元 = `100000000`）

   - `items[].tax_rate` 必须是 `0` / `100` / `150` / `300` / `500` / `600` / `900` / `1000` / `1100` / `1300` / `1600` / `1700`（单位万分之一）

   - 折扣行（ `discount=true`）必须是被折扣行的下一行

   - `buyer_information.taxpayer_id` 在购买方类型为 `ORGANIZATION` 时必填

* * *

### 269546538 — 商户号不存在

排查步骤：

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

2. 区分服务商商户号（签名所用）与 `sub_mchid`（请求 Body 中）

3. 区分测试 / 灰度 / 生产环境的商户号

4. 服务商场景下注意 `sp_mchid` 与 `sub_mchid` 不要混用位置


* * *

### 268565253 — 请求数电接口获取企业状态接口返回结果处理错误

排查步骤：

1. 该错误为微信支付与税局对接的中间环节出错，多为税局侧暂时性问题

2. 业务侧应当作可重试错误处理（30s → 2min → 5min 退避）

3. 长时间持续失败时调「检查子商户开票功能状态」接口确认商户在税局的接入状态，关注 `digital_tax_mode.status` 与 `digital_tax_mode.access_fail_reason`

4. 如果是数电服务商资源过期（ `RESOURCE_EXPIRED`），联系数电服务商续期


* * *

### 268470902 — 用户尚未提交抬头

排查步骤：

1. 该错误只发生在非微信支付场景

2. 正确流程：先调「获取用户抬头填写链接」生成填写链接 → 引导用户填写 → 监听「用户发票抬头填写完成通知」 → 收到后再调开票接口

3. 业务侧应监听抬头填写完成通知，避免提前调开票接口


* * *

### 268435461 — 参数非法

排查步骤：

1. 看响应体 `detail.field` 定位具体非法字段

2. 检查敏感字段是否加密： `buyer_information.phone` / `buyer_information.email` 必须用微信支付公钥/平台证书加密

3. 检查 `Wechatpay-Serial` 头是否与加密使用的公钥/证书匹配

4. 枚举字段需在文档定义范围内：

   - `buyer_information.type` 必须是 `INDIVIDUAL` / `ORGANIZATION`

   - `fapiao_bill_type` 必须是 `COMM_FAPIAO` / `VAT_FAPIAO`

   - `transaction_information.pay_channel` 只能是 `WECHAT_PAY`
5. 时间字段必须为 RFC3339 格式

6. `fapiao_id` 字符集：字母、数字、 `-`、 `_`、 `|`、 `*`


* * *

### 268436172 — 要查询的发票不存在

排查步骤：

1. 检查 `fapiao_id` 是否传错

2. 该 `fapiao_id` 必须属于查询请求中的 `fapiao_apply_id`

3. 不传 `fapiao_id` 时会返回该申请单下所有发票，业务侧可用作兜底


* * *

### 268435483 — 数据不存在

排查步骤：

1. 看响应体 `message` 与 `detail` 定位是哪类数据不存在

2. 常见场景：

   - 查询邀请商户信息时 `sub_mchid` 不存在邀请记录

   - 引用的 `card_template_id` 卡券模板不存在

   - 上传发票文件后的 `media_id` 已过期（通常 3 天有效期）

* * *

### 268552457 — 商户信息内未找到数电开票人信息

排查步骤：

1. 调「检查子商户开票功能状态」接口确认 `digital_tax_mode.billing_person_info` 是否有开票人记录

2. `digital_tax_mode.status` 应为 `ENABLED`

3. 状态停留在 `BILLING_PERSON_REGISTER_PENDING` 时需法定代表人 / 财务负责人登录电子税局设置开票员

4. 状态停留在 `BILLING_PERSON_CONFIRMED_PENDING` 时需开票员登录电子税局 \- 乐企进行授权

5. 开票时 `billing_person_id` 必须传查询接口返回的开票人 ID


* * *

### 268578415 — 交易信息当前状态不可重试

排查步骤：

1. 每个 `fapiao_apply_id` 最多重试 4 次（即最多创建 5 个 `fapiao_id`）

2. 调「查询电子发票」确认当前申请单下已有的 `fapiao_id` 数量

3. 已达 5 个则该 `fapiao_apply_id` 无法继续使用，需换一个新的 `fapiao_apply_id` 重新发起

4. 重试前先排查导致开票失败的根因（查看 `fapiao_error_message`）


* * *

### 271942234 — 已经插卡成功，无须重复插卡

排查步骤：

1. 该错误不是真正的失败，发票已成功进入用户卡包

2. 业务侧应把该错误码识别为「插卡已完成」处理

3. 调「查询电子发票」确认 `card_information.card_status=INSERTED`

4. 业务侧应监听「发票插入用户卡包成功通知」，收到通知后标记完成，避免重复触发

5. 业务侧加分布式锁（按 `fapiao_id` 维度）防止并发插卡


* * *

### 268564709 — 服务商获取邀请商户信息参数错误

排查步骤：

1. 检查 `invite_token` 参数（邀请链接中的 token）是否传错或被截断

2. token 通常有时效，过期后需要重新生成邀请链接

3. 服务商查询的 token 必须是自己发起的邀请


* * *

### 268436173 — 商户未同意开票申请，无法进行当前操作

排查步骤：

1. 服务商需先调「获取开通服务商电子发票能力邀请链接」生成邀请链接

2. 引导子商户在链接页面接受邀请并完成授权

3. 调「检查子商户开票功能状态」确认 `third_mode.status` 或 `digital_tax_mode.status` 是否为 `ENABLED`

4. 子商户在电子税局的授权流程需要法定代表人 / 财务负责人 / 开票员配合


* * *

### 268513837 — 商户未设置开票平台

排查步骤：

1. 调「检查子商户开票功能状态」接口， `third_mode.status` 与 `digital_tax_mode.status` 至少有一个需为 `ENABLED`

2. 引导商户在商户平台配置数电开票模式或第三方 / 自建开票模式

3. 配置完成后约几分钟到几小时生效


* * *

### 270924345 — Content-Type 不正确

排查步骤：

1. 打印实际发送的请求头，确认 `Content-Type: application/json`

2. Body 必须是 JSON 字符串

3. 开票接口同时需要 `Wechatpay-Serial` 头用于敏感字段加密

4. 建议使用官方 SDK


* * *

### 268574945 — 交易单剩余可开票金额不足

排查步骤：

1. 一笔交易的累计开票金额不能超过交易总金额

2. 计算公式：剩余可开票金额 = 交易总金额 \- 已开具发票总金额 \+ 已冲红发票总金额

3. 业务侧需要维护「交易订单 \- 已开票金额」映射

4. 不够时可让用户接受减额开票，或先冲红已开发票再重新开

5. 注意金额单位是分而非元