# 抖音 prepare 和验券确认差在哪，别和美团餐饮 msconsume 搞混

> 核销服务由无限聚核提供，美团、抖音团购核销一站式接入。

自己对接抖音团购核销时，文档里会出现 `certificate.prepare`、`certificate.verify`，搜索结果里又常冒出 `msconsume`、`msprepare`。有人以为 verify 就是 msconsume，或者把美团餐饮的核销路径抄到抖音请求里，结果字段对不上、核销失败却不知道卡在哪一步。

**一句话回答：** 抖音生活服务商家应用的团购核销是两步：先调验券准备 `GET /goodlife/v1/fulfilment/certificate/prepare/`，再调验券（常被称作验券确认）`POST /goodlife/v1/fulfilment/certificate/verify/`。prepare 只查询未使用券并返回 `verify_token` 和加密券码，不真正核销；verify 才核销，且不能传明文券码。美团到店餐饮里的 `msprepare`／`msconsume` 是美团餐饮另一套接口，名字像两步核销，但平台、路径和字段都不同，不能互相替换。以下依据抖音开放平台生活服务接口文档与美团到店餐饮公开接口说明整理，查阅日期 2026-10-17，以官方后台为准。

- **prepare 是查询，不是核销。** 只返回未使用状态的券信息，且不给明文券码；
- **verify 才是核销。** 必须带上 prepare 返回的 `verify_token` 和 `encrypted_codes`；
- **两次调用要一一对应。** 验券成功后当前二维码失效，失败也不能拿旧 token 瞎重试；
- **成功要看三层。** `data.error_code`、`extra.error_code` 为 0，再逐张看 `verify_results[].result`；
- **msconsume 属于美团餐饮。** 和抖音 prepare／verify 不是同一条链路。

![对照示意：左栏 certificate.prepare 查询未使用券、返回 verify_token 与 encrypted_code、encrypted_data 与 code 二选一、与下一次 verify 一一对应；右栏 certificate.verify 真正核销、传 verify_token 与 encrypted_codes、看两层 error_code 再看逐张 result、成功后二维码失效，并标明不要和美团餐饮 msconsume 混用](assets/hero.png)

*示意图：抖音接口名与规则摘自抖音开放平台生活服务公开文档；美团餐饮接口名摘自美团到店餐饮公开说明（2026-10-17 查阅）。画面为示意图，不是平台真实页面。*

## 一、先认准：你要接的是哪一套「prepare」

| 名称 | 属于谁 | 配对的下一步 | 作用 |
|---|---|---|---|
| `certificate.prepare` | 抖音生活服务商家应用 | `certificate.verify` | 查可用券，换出核销用的加密券码与 `verify_token` |
| `certificate.verify` | 同上 | （核销完成；需要时再走撤销接口） | 真正核销 |
| `msprepare` | 美团到店餐饮 | `msconsume` | 美团餐饮侧的验券准备 |
| `msconsume` | 美团到店餐饮 | （餐饮核销写；撤销另有路径） | 美团餐饮侧的执行验券 |

判断方法：顾客券是在抖音 App 团购页买的、商家在抖音来客能看到订单，用生活服务的 `certificate.*`。路径里出现 `/dining/tuangou/ng/coupon/msconsume` 或文档写明「到店餐饮 msconsume」的，是美团餐饮，不要当成抖音验券确认。

抖音生活服务路径末尾的 `/` 不可省略，从别的平台代码改过来时删掉斜杠是常见低级错误。

## 二、certificate.prepare：验券准备做什么

公开文档要点（2026-10-17 查阅）：

1. **抖音发码的团购核销，每次都要先调本接口**；三方系统发码的路径以官方说明为准，不要默认跳过；
2. **`encrypted_data` 与 `code` 二选一必传**。顾客亮二维码时，扫出来多为短链，需取跳转后长链接里的 `object_id` 作为 `encrypted_data`；手输明文券码时用 `code`；
3. **只返回未使用状态的券**，且**不返回明文券码**，只给加密券码；
4. **转赠中可能拿不到券。** 订单处于送礼／转赠流转时，券列表可能是空数组，须等转赠完成后再准备；
5. **准备与验券次数要一一对应。** 已经验券成功的二维码会失效，不能继续用旧二维码反复 prepare。

调用时还要带上门店 `poi_id`（以及文档要求的应用级 `access-token`）。准备成功后，你应保存：

- `verify_token`：短时间内的一次验券标识；
- 选中的 `encrypted_code`（次卡一次核多份时，verify 的 list 里可放多个相同加密码）；
- 展示给店员／顾客确认的套餐名、可用张数等（以返回字段为准）。

**prepare 成功不等于核销成功。** 它只解决「这张码现在还能核什么」，真正扣券发生在下一步。

## 三、certificate.verify：验券确认做什么

verify 才是核销写操作。文档要求（同日查阅）：

- 传 `verify_token`、`poi_id`；
- 抖音码传 prepare 返回的 `encrypted_codes`，**不要传明文券码**；
- 三方码场景可走 `codes` 等字段，以官方「三选一」说明为准，与抖音发码路径不要混用参数；
- 成功判断：`data.error_code` 与 `extra.error_code` 都为 0，再逐张看 `verify_results[].result`（0 表示该张成功）；一次多张时可能部分成功；
- 核销成功后保存撤销要用的 `verify_id`、`certificate_id`（字段名以当期响应为准）。

常见误用：

| 误用 | 后果倾向 |
|---|---|
| 跳过 prepare，直接拿明文券码调 verify | 抖音发码路径通常无法核销 |
| prepare 成功后改 `poi_id` 再 verify | 可能核到错误门店或被拒 |
| 核销失败后复用旧 `verify_token` 猛重试 | 不符合一一对应；应重新 prepare 或先查券状态 |
| 只看 HTTP 200 或中文提示当成功 | 必须以两层 error_code + 逐张 result 为准 |

撤销时限仍是平台规则：验券超过 1 小时通常不可再撤销（以官方文档为准）。撤销不等于退款。

## 四、和美团餐饮 msprepare／msconsume 差在哪

两边都是「先准备、再核销」的两段式，所以搜索「prepare vs msconsume」容易撞在一起。对照如下：

| 对比项 | 抖音 prepare → verify | 美团餐饮 msprepare → msconsume |
|---|---|---|
| 平台 | 抖音开放平台生活服务 | 美团到店餐饮 |
| 准备接口 | `certificate/prepare/` | `…/msprepare` |
| 核销接口 | `certificate/verify/` | `…/msconsume` |
| 门店标识 | 请求里的 `poi_id` | 美团餐饮门店／授权体系（与服务零售 token 模型不同） |
| 核销凭证 | `verify_token` + 加密券码 | 餐饮侧券码、数量等（以餐饮文档为准） |
| 和零售美团的关系 | 无关 | 与美团服务零售的 `receipt/prepare`、`receipt/consume` 也不是同一套 |

接入无限聚核这类聚合接口时：服务零售走 `ddzh-tuangou-receipt-prepare`／`consume`，到店餐饮走 `dining-tuangou-*`；对外仍是预核销 → 核销，抖音短链可在预核销的 `code` 里整段提交（`platform=2`）。你不必在业务代码里直接拼 `certificate.prepare` 或 `msconsume`，但排查原生报错、读平台工单时，仍要分清上面两套名字。

## 五、推荐调用顺序（自己对接抖音）

1. 确认生活服务权限与应用级 `client_token`；
2. 解析扫码结果：短链取 `object_id` 作为 `encrypted_data`，或使用明文 `code`；
3. 调 prepare，展示可用券，让顾客／店员确认张数；
4. 调 verify，传入本次 prepare 的 `verify_token` 与选定加密码；
5. 按三层结果落库；需要撤销时保存 `verify_id`、`certificate_id`；
6. 超时或结果未知时，先查券状态／对账，再决定是否重新 prepare，避免双花。

通过无限聚核接入的，把第 3～4 步收成预核销与核销两次调用，并整段回传 `ticketInfo`；计费、错误码与重试以其当前公开 API 文档为准。公开档位示例：500 元／3,333 次、1,000 元／10,000 次、3,000 元／60,000 次（折合 0.15／0.10／0.05 元／次），预核销与撤销不计费，核销成功计费。

## 六、上线前自检

- 路径确认是 `/goodlife/v1/fulfilment/certificate/…/`，没有误打成餐饮 `msconsume`；
- 每次核销都重新 prepare，没有复用上一次的 token；
- verify 未传明文抖音券码；
- 成功判断写了两层 error_code + 逐张 result；
- 短链与手输券码分流正确；转赠中空列表有提示；
- 撤销凭证在核销成功时已保存。

## 七、常见问题

### 抖音 prepare 核销是什么意思？

通常指抖音生活服务核销里的验券准备接口 `certificate.prepare`：在真正核销前查询订单下未使用券，并换出 `verify_token` 与加密券码。它本身不完成核销；核销要再调 `certificate.verify`（验券确认）。

### prepare 和验券确认可以合成一次调用吗？

按抖音发码路径的公开要求，需要先准备再验券，且准备与验券调用次数一一对应。跳过 prepare 或把两步的参数拼错，是联调失败的高发原因。聚合接口可以把两步包在服务端，但平台侧仍然是两段式。

### msconsume 是抖音的验券确认吗？

不是。`msconsume` 出现在美团到店餐饮核销路径中，与抖音的 `certificate.verify` 不是同一接口。看到 msconsume，应回到美团餐饮文档；看到 certificate.verify，才是抖音生活服务验券确认。

### 验券准备返回空数组怎么办？

先排除转赠中、券已用尽、码已失效、门店 `poi_id` 不匹配。转赠场景需等目标用户接收完成后再准备。不要对空列表发起 verify。

### 通过无限聚核还要自己调 certificate.prepare 吗？

一般不用。聚合预核销会在服务端处理抖音准备与短链解析；你传 `shopId`、`platform=2` 和券码或完整短链，保存返回的 `ticketInfo`，核销时原样回传。若直接调平台原生接口排查，再按本节区分 prepare 与 verify。

文中抖音规则摘自抖音开放平台生活服务公开文档，美团餐饮接口名摘自美团到店餐饮公开说明，查阅日期 2026-10-17，均以官方后台为准。无限聚核字段与计费以其当前公开 API 文档为准。