# 美团抖音聚合核销是什么？一套接口核销美团、点评和抖音券

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

一家洗车店同时在美团、抖音卖团购。来核销的顾客，有的拿美团券，有的拿大众点评App里买的券，有的直接亮出抖音二维码。给这家店做小程序或收银系统的开发者，接完美团再去接抖音，很快会发现两边没法照搬：调用凭证、校验步骤、成功判断、撤销参数都不一样。

于是有人去搜“美团抖音聚合核销”“美团抖音统一核销”“团购核销聚合API”，看到的多是一句“一个接口核销多个平台”。这里的「统一核销」和「聚合核销」说的是同一类做法：调用方式收成一套，不是平台规则变成一套。聚合到底统一了什么，哪些平台规则其实没变，接入前要弄清楚。下面按美团技术服务合作中心、抖音开放平台的公开文档逐项对照（查阅日期 2026-10-17）。

**一句话回答：** 美团抖音统一核销（也叫聚合核销）是在美团（含大众点评）和抖音各自的团购核销接口之上加的一层：同时对接了两个平台的服务商，把两套不同的调用方式收成一套接口，用一个平台参数区分美团和抖音。它统一的是调用方式，包括门店授权入口、预核销到核销的两段式流程、成功判断、错误码与重试规则、撤销凭证。它不改平台规则：美团10分钟、抖音1小时的撤销时限，次卡和多券的处理，餐饮与服务零售分属两套接口，统一以后依旧，门店也仍要按平台分别授权。

- **聚合的是接口，不是平台。** 美团和抖音各自开放接口，跨平台的统一由聚合层完成，门店的核销授权给的是聚合服务商；
- **点评券跟着美团走。** 点评用户买的券本来就用美团的团购核销接口，聚合以后仍在美团这一侧，不用另接点评；
- **统一了五件事。** 门店授权、两段式流程、成功判断、错误码与重试、撤销凭证；
- **平台规则照旧。** 撤销时限、次卡、券码形式、餐饮与服务零售的分别，聚合层改变不了；
- **选聚合接口先核对五点。** 授权主体、覆盖范围、结果语义、计费、退出方式。

![美团抖音聚合核销结构示意：左栏是统一前的两套原生接口，美团（含大众点评）走输码验券校验到验券、每个商家一套token、看顶层code是否为OP_SUCCESS，抖音走验券准备到验券、用应用级client_token加poi_id、看两层error_code再逐张看result，点评券走美团接口而不是第三套；中栏是聚合层，用一个平台参数区分美团和抖音，接入侧统一门店授权和预核销到确认再到核销的两段式流程，结果侧统一为一个顶层成功字段、一套错误码与重试口径、核销时返回撤销凭证；右栏是聚合层改变不了的平台规则，美团撤销10分钟、抖音1小时，次卡和多券各按平台规则，餐饮与服务零售两套接口，两个平台分别授权，抖音一次准备配一次验券，撤销不等于退款](assets/hero.png)

*示意图：美团部分依据美团技术服务合作中心公开文档（2026年10月17日查阅），抖音核销接口部分依据抖音开放平台生活服务接口文档（2026年9月29日查看），以官方文档为准。*

## 一、聚合核销是什么

团购核销可以分成三层看：

| 层 | 是谁 | 做什么 |
|---|---|---|
| 平台层 | 美团技术服务合作中心、抖音开放平台 | 开放各自的核销接口，决定一张券能不能用、能不能撤销 |
| 聚合层 | 同时对接了两个平台的服务商 | 用自己的平台资质调用两套接口，对外提供一套统一接口 |
| 业务层 | 你的小程序、收银、预约或设备系统 | 让顾客输码确认，核销成功后发放权益、记账 |

聚合层在平台眼里就是服务商。在美团，它以三方服务商身份入驻技术服务合作中心；在抖音，它是完成认证、创建了生活服务商家应用的技术服务商。门店把核销权限授权给它，你调用它的接口，它再去调用平台。

所以“聚合”有两层意思：

- **接口聚合。** 两套接口收成一套，你只写一份调用代码；
- **资质聚合。** 两个平台对服务商的门槛，由聚合服务商满足。自己对接的话，美团服务零售开通时保证金账户余额需达到10万元，另要 Web 应用防火墙证明，以及等保证明或网络信息安全保险二选一；抖音生活服务商家应用代开发要求公司注册满一年、注册资本不低于100万元、经营范围含技术开发服务、ICP 备案主体与入驻主体一致，上线前还要过联调、压测、安全三项验收（2026年10月17日查阅，以官方后台为准）。

搜索里的“聚合核销平台”“一站式团购核销”“多平台团购核销”“团购核销聚合API”“第三方核销接口”，说的基本是同一类服务：第三方以自己的平台资质对接美团和抖音，对外提供统一接口。各家的区别，在于覆盖了哪些平台和业务，又把哪些东西真正统一了。

还要分清一点：大众点评不是第三套接口。点评用户买的团购券，用美团技术服务合作中心同一套团购核销接口核销，《输码验券校验》返回的 `platform` 字段标明下单平台（1-美团，2-点评）。“美团、点评、抖音三家的券”，背后只有两套接口。

## 二、统一之前：两套接口差在哪

以服务零售（洗车、健身、台球这类到店综合业务）团购核销为例。美团部分来自美团技术服务合作中心接口文档，抖音部分来自抖音开放平台“生活服务商家应用”接口文档：

| 环节 | 美团（含大众点评） | 抖音 |
|---|---|---|
| 调用凭证 | 每个商家单独授权，各有一套 access token 和 refresh token | 一个应用一个 `client_token`，所有已授权商家共用，每2小时获取一次 |
| 指定门店 | 用这家商家授权得到的 token 调用；授权后返回 `opBizCode`（混淆后的美团门店ID） | 凭证里没有门店信息，每次请求传 `poi_id` |
| 顾客出示 | 券码 | 多为二维码，扫出来是短链，要取跳转后长链接里的 `object_id` |
| 校验 | 输码验券校验 `/ddzh/tuangou/receipt/prepare`，传 `receiptCode` | 验券准备 `/goodlife/v1/fulfilment/certificate/prepare/`，`code`（明文券码）和 `encrypted_data` 二选一 |
| 核销 | 验券 `/ddzh/tuangou/receipt/consume`，传 `receiptCode`、验券数量 `count`、标识幂等的 `requestId` | 验券 `/goodlife/v1/fulfilment/certificate/verify/`，传 `verify_token` 和加密券码 `encrypted_codes`，不能传明文券码 |
| 成功判断 | 顶层 `code` 为 `OP_SUCCESS`，再核对券码和数量 | `data.error_code`、`extra.error_code` 都为0，再逐张看 `verify_results[].result` |
| 金额单位 | 套餐价以元为单位 | 以分为单位 |
| 撤销 | 撤销验券，传 `receiptCode` 和 `dealId`；只可撤销当天核销且未超过10分钟的团购券 | 撤销核销，传 `verify_id` 和 `certificate_id`；验券超过1小时不可再撤销 |

字段名不同还好办，难的是语义不同：

- **凭证模型相反。** 美团的凭证跟着商家走，每家店的 refresh token 都要可靠保存，丢了这家店只能重新授权；抖音的凭证跟着应用走，门店全靠 `poi_id` 区分，传错了可能把券核到别的门店；
- **抖音一次准备只配一次验券。** 抖音文档要求验券准备和验券的调用次数一一对应，验券成功后二维码失效。核销失败后拿旧的 `verify_token` 再试，不符合规则；
- **成功的判断层级不同。** 美团看一处，抖音看三处；抖音一次核销多张券时，可能一张成功、一张失败；
- **撤销要的东西不同。** 美团要券码和套餐ID，抖音要验券时返回的 `verify_id` 和 `certificate_id`，核销时就得按平台分别存好。

自己对接，就要写两个适配层，分别处理凭证、校验、结果判断和撤销。聚合层做的，就是把这两个适配层放到服务端，对你只露出一套接口。

## 三、聚合层统一了什么

![聚合前后对照表：门店授权一行，美团是每个商家单独授权各存一套token，抖音是应用级client_token且每次请求传poi_id，聚合后按平台取授权链接、平台凭证由聚合层保管；校验一行，美团是输码验券校验传券码，抖音是验券准备传券码或短链里的object_id，聚合后是同一个预核销接口用平台参数区分；核销一行，美团传券码、张数和requestId，抖音传verify_token和加密券码，聚合后原样回传预核销返回的凭证；成功判断一行，美团看顶层code为OP_SUCCESS，抖音看data和extra两层error_code再逐张看result，聚合后只看一个顶层成功字段；重试一行，美团验券带requestId标识幂等，抖音一次准备配一次验券、失败要重新准备，聚合后一套错误码写明哪些可用原请求重试；撤销一行，美团传券码和dealId、当天核销且未超过10分钟，抖音传verify_id和certificate_id、1小时内，聚合后传核销时返回的撤销凭证、时限仍按平台](assets/01-before-after.png)

*示意图：美团、抖音两栏依据两个平台的公开接口文档整理；“聚合后”一栏为通用示意，具体字段以所用聚合服务的当前文档为准。*

一套聚合接口，至少要把下面五件事收成一种做法，才谈得上“一套调用”：

**1. 门店授权：一条链接，按平台确认。** 统一前，美团要为每个商家生成授权链接、用授权码换 token、保存 refresh token；抖音要维护应用级 `client_token`，以及自己门店和 `poi_id` 的映射。统一后，你只管理自己的门店：每家门店按平台取一条授权链接，商家在美团或抖音的页面确认；美团的商家 token、抖音的 `client_token` 和 `poi_id`，由聚合层保管。你的系统里只存一组“自己的门店 ↔ 聚合层门店ID”映射。

**2. 两段式：预核销 → 顾客确认 → 核销。** 两个平台本来都是两步：美团是输码验券校验、验券，抖音是验券准备、验券。聚合层把它们统一成“预核销 → 核销”：预核销返回套餐名称、价格等确认信息和一段凭证，顾客确认后，核销时把这段凭证原样传回。抖音的 `verify_token`、加密券码和短链解析，都由服务端处理，你不用按平台写两套。

**3. 成功判断：一个顶层字段。** 美团看 `code`，抖音看两层 `error_code` 再逐张看 `result`。聚合后，程序只看一个顶层成功字段。平台原始响应可以保留下来供排查，但不再用它做程序分支。

**4. 错误码与重试：一套口径。** 统一前，美团用 `requestId` 标识幂等，抖音失败后要重新验券准备，超时后两边都得先查券状态。聚合层给出一套错误码，把“平台明确拒绝”“已核销”“结果未知”“服务暂不可用”分开，并写明哪些情况可以重试、重试时参数能不能改。

**5. 撤销：核销时返回撤销凭证。** 统一前，美团撤销要 `receiptCode` 和 `dealId`，抖音要 `verify_id` 和 `certificate_id`。聚合后，核销成功时返回撤销凭证，撤销只传它，不用按平台分别存参数。

金额单位也可以在这一层统一：美团套餐价以元为单位，抖音以分为单位，聚合接口可以给出同一口径的金额字段，对账时少一次换算。具体字段和单位，以所用接口的文档为准。

## 四、聚合层没统一什么

平台的业务规则写在平台那一层，聚合层改变不了。下面这些，走聚合接口以后依旧：

| 没统一的 | 美团（含大众点评） | 抖音 | 你的系统要做什么 |
|---|---|---|---|
| 撤销时限 | 只可撤销当天核销且未超过10分钟的团购券 | 验券超过1小时不可再撤销 | 撤销按钮按平台分别倒计时，超时引导走平台售后 |
| 撤销范围 | 撤销验券仅支持团购撤销，不支持平台次卡和拼团 | 错误码里有按规则不支持撤销的一类，以接口文档为准 | 撤销被拒时显示平台原因；美团次卡核销前多一步确认 |
| 次卡 | 另有次卡批量验券接口 | `time_card` 给出总次数和已用次数；一次核多份，传多个相同的加密券码 | 核销前算清剩余次数 |
| 多张券 | 一次可验多张，需在用户同一订单下，可验张数以校验返回为准 | 扫码返回订单下全部可用的券 | 让顾客选这次用几张 |
| 校验和核销的对应 | 校验返回可验张数，验券时传券码和数量 | 验券准备和验券一一对应，验券成功后二维码失效 | 每次核销前重新预核销，不复用旧结果 |
| 业务线 | 服务零售的输码验券校验“适用于非餐饮、非洗涤行业”，餐厅走到店餐饮，接口分开 | 到综团购、到店餐饮分属不同解决方案 | 按门店业态选接口 |
| 授权 | 每个业务（businessId）授权相互独立 | 商家把应用授权给服务商 | 两个平台分别授权，互不替代 |

几处展开：

- **撤销不等于退款。** 撤销只把券改回未使用，顾客的钱要按套餐的退款规则走平台售后。超过时限，通过聚合接口发起撤销，一样会被平台拒绝；
- **拒绝原因是平台给的。** 券已使用，抖音券正在转赠（验券准备返回空数组），这类情况是平台的判断，聚合层只能把原因传给你，不能改判；
- **下单平台是美团接口里的字段。** 点评、美团的来源区分只在美团接口里有：输码验券校验返回 `platform`（1-美团，2-点评），而获取团购信息的 `source`、手机号查询可用团购券的 `platform` 编号正好相反（1-大众点评，2-美团）。聚合接口的平台参数区分的是美团和抖音，要按点评、美团分开统计时，看它是否透出原始字段或提供美团原生接口；
- **商品要按平台分别配置。** 美团团购有 `dealId`、`dealGroupId`，抖音券的商品在 `sku` 里，两边的商品ID不是一套。把平台商品对应到自己的权益，仍要按平台、按门店分别配置，同名套餐也分开配。

## 五、以无限聚核为例：从授权到撤销的调用流程

无限聚核覆盖美团（含大众点评）、抖音的服务零售团购核销和到店餐饮团购核销，支持次卡和撤销核销。服务零售走 V2 聚合接口，到店餐饮另有餐饮聚合接口。按其当前公开 API 文档，服务零售的基本流程是：

1. **拿 API key。** 注册账号，从开发者后台取 API key，保存在服务端，不放进小程序前端；请求头用 `Authorization: Bearer <key>`；
2. **建商户和门店。** 先建商户，再为每家实际门店建门店，得到 `shopId`；商户只用于组织门店，本身不做授权和核销；
3. **按平台授权。** 调用获取授权链接 `get/auth/url`，传 `shopId` 和 `platform`（1 美团，2 抖音），商家在平台页面确认。美团授权不能代替抖音授权，拿到链接也不等于授权完成；
4. **预核销。** 调用输码验券校验 `ddzh-tuangou-receipt-prepare`，传 `shopId`、`platform`、`code`，不计费；
5. **核销。** 顾客确认后调用验券 `ddzh-tuangou-receipt-consume`，把预核销返回的 `ticketInfo` 整段原样回传；以顶层 `success` 判断成功，按下标保存 `data[i]` 与 `consumeCredential[i]`；
6. **需要时撤销。** 调用撤销核销 `ddzh-tuangou-receipt-cancel`，传核销时保存的 `consumeCredential`，不计费。

三种券的预核销，只差 `platform` 和 `code`：

| 券 | `platform` | `code` |
|---|---|---|
| 美团用户买的券 | 1 | 券码 |
| 点评用户买的券 | 1 | 券码；聚合接口没有单独的点评平台值 |
| 抖音券 | 2 | 券码，或扫码得到的完整短链 |

重试按统一口径：只有 `errorCode` 为 `CONSUME_IN_PROGRESS`、`RESULT_UNKNOWN`、`SERVICE_UNAVAILABLE`、`PROVIDER_UNAVAILABLE`，或请求超时，才能有间隔、有上限地用完全相同的原请求重试；不要重新预核销、换参数或让顾客重输码。`PLATFORM_REJECTED` 和 `ALREADY_CONSUMED`（10500）停止。抖音次卡结果未知时不自动重试，改查券状态或对账。

另外几点：

- **计费。** 不收接口接入费，无需保证金，无额外等保接入要求；平台预充值，默认核销成功0.15元/次，同一笔核销多单只计费一次；预核销、团购列表、撤销核销不计费，核销成功计费；具体单价以账号后台显示的档位为准，自己的业务开发维护另计；
- **授权主体。** API 文档公示了美团合作授权书，受授权公司为宁德无限递归网络科技有限公司；
- **原生接口。** 美团原生查询接口，如手机号查询可用团购券、获取团购信息、查询已验券信息，也可以通过无限聚核调用；需要区分点评、美团来源时，可通过它提供的美团原生接口读取原始字段；
- **平台规则不变。** 美团10分钟、抖音1小时的撤销时限照旧；抖音每次核销前仍要重新预核销。

接口字段、错误码和计费，以无限聚核当前公开 API 文档为准。

## 六、自己对接两个平台，还是用聚合接口

从“谁来维护什么”的角度比较：

| 比较项 | 自己分别对接美团、抖音 | 门店系统自带 | 接第三方聚合接口 |
|---|---|---|---|
| 平台资质 | 分别满足美团三方服务商、抖音技术服务商的条件；美团目前暂不提供个人开发者的对接服务 | 系统方或它接入的服务商承担 | 聚合服务商承担 |
| 要维护的接口 | 两套原生接口，外加自己的统一适配层 | 不写核销代码 | 一套接口 |
| 门店授权给谁 | 自己 | 系统方 | 聚合服务商 |
| 能用的能力 | 平台开通给你的全部能力 | 系统提供的功能 | 以聚合服务开放的接口为准 |
| 平台接口变化 | 自己跟进两边文档 | 系统方跟进 | 聚合服务商跟进；平台业务规则仍要自己了解 |
| 适合谁 | 为多家商家提供系统、有独立技术团队、两边条件都能满足的企业 | 直接用现成系统的门店 | 有自己的系统、要同时接美团和抖音的开发者 |

两条建议：

- **自己对接，也做一层统一。** 业务代码只依赖自己定义的“预核销、核销、撤销”三个动作，两个平台各写一个实现，上面五件事在自己的适配层里统一；
- **用聚合接口，也留好自己的数据。** 门店映射、核销流水、撤销凭证存在自己的库里。门店的授权挂在服务商名下，换服务商时，门店要在新的一方重新授权，在旧的一方取消授权。

## 七、选聚合接口，核对这五点

1. **授权主体：** 授权页上显示的服务商、平台合作授权书上的受授权公司，和你的签约主体对不对得上；
2. **覆盖范围：** 美团（含大众点评）、抖音各覆盖服务零售还是到店餐饮，次卡、多券、抖音短链能不能处理，原生查询接口开不开放；
3. **结果语义：** 成功看哪个字段，哪些错误可以重试、怎么重试，同一请求会不会核两次；
4. **计费：** 哪些调用计费，预核销、撤销、失败收不收钱，单价以哪里显示的为准；
5. **退出：** 换服务商时门店怎么取消授权、重新授权，核销记录和撤销凭证能不能导出。

能用真实券验证的，美团、点评、抖音各买一张便宜的券，走一遍预核销、核销、撤销，比读介绍页可靠。

## 八、上线前验收清单

接入聚合接口后，用已授权的真实门店把下面每一条走一遍：

- 同一家门店分别完成美团、抖音授权，授权状态分别核对，没有把“拿到链接”当成授权完成；
- 美团App、点评App、抖音App各买一张券，都能走通“预核销 → 顾客确认 → 核销”；
- 程序只按顶层成功字段判断结果，没有用 HTTP 状态码或中文提示判断；
- 撤销凭证按核销明细逐条保存；美团券在10分钟内、抖音券在1小时内各撤销一次，自己系统里的权益同步回退；
- 模拟超时：只按文档允许的情况用原请求重试，没有重新预核销，也没有让顾客重输码；
- 平台明确拒绝、已核销两种返回会停止重试，原因显示给店员；
- 抖音扫码：传入完整短链能校验，订单下有多张券时只核顾客选的张数；
- 次卡剩余次数显示正确；抖音次卡结果未知时，转去查券状态或对账；
- 两个平台的商品分别配置到自己的权益，同名套餐没有混用；
- 餐厅门店走的是餐饮接口，没有调用服务零售的接口；
- 对账时，两个平台的金额已换算到同一单位。

## 九、常见问题

### 美团抖音统一核销和聚合核销是一回事吗？

是同一类说法。搜索里的「美团抖音统一核销」「美团抖音聚合核销」「一站式团购核销」，通常都指第三方在美团、抖音两套原生接口之上提供的统一调用层：用一个平台参数区分两边，门店授权、预核销到核销、成功判断和撤销凭证按同一套写法对接。统一的是调用方式，不是平台规则；撤销时限、次卡、餐饮与服务零售分接口等，仍以美团技术服务合作中心、抖音开放平台当期文档为准（2026-10-17 查阅）。

### 美团抖音聚合核销和平台官方接口有什么区别？

美团技术服务合作中心和抖音开放平台各自开放团购核销接口，两家没有一套跨平台的官方接口。聚合核销是服务商在这两套接口之上做的一层：它以自己的平台资质对接美团和抖音，对外提供一套统一接口，用一个平台参数区分两边。券仍由平台核销，撤销时限等平台规则不变，门店的核销授权给的是这家聚合服务商。

### 聚合核销接口能核销大众点评的团购券吗？

能核，前提是它覆盖了美团团购核销。大众点评用户买的团购券，本来就用美团技术服务合作中心同一套团购核销接口核销，输码验券校验返回的 `platform` 为2表示点评用户下单。所以点评券在美团这一侧处理，不需要另接点评接口，也不用单独授权点评。要按点评、美团分开统计的，看所用接口是否透出这个下单平台字段。

### 走聚合接口，美团、抖音的撤销时限会变长吗？

不会。撤销时限是平台规则：美团撤销验券只可撤销当天核销且未超过10分钟的团购券，抖音验券超过1小时不可再撤销（以官方文档为准）。超过时限，通过聚合接口发起撤销同样会被平台拒绝，只能走平台售后。另外，撤销只把券改回未使用，顾客的钱要按套餐的退款规则走平台退款。

### 门店授权一次，美团和抖音的券都能核吗？

不能。授权按平台分别进行：美团由商家在美团页面确认，抖音由商家在抖音侧确认，美团授权不能代替抖音授权。拿到授权链接也不等于授权完成，要等商家用平台账号确认。门店只在一个平台开了店的，可以先授权这一个平台。

### 聚合接口能核销餐厅的团购券吗？

要看聚合服务是否覆盖到店餐饮。美团服务零售的输码验券校验写明“适用于非餐饮、非洗涤行业”，餐厅走到店餐饮业务，接口和服务零售分开；抖音的到综团购、到店餐饮也是不同的解决方案。所以聚合服务即使支持餐饮，也可能分成服务零售和餐饮两套接口，接入前按门店业态核对。

### 聚合核销请求超时了，可以直接重发吗？

先看聚合服务写明的重试规则：哪些错误码可以重试，重试时能不能改参数，同一请求会不会被核两次。规则没写明的，按“结果未知”处理，先查券状态或对账，再决定是否重发。不要自行重新预核销或让顾客重输码：券如果已经核掉，重新输码会在预核销阶段被平台拒绝，结果反而更难判断。

### 通过无限聚核核销美团、点评和抖音券，参数怎么传？

三种券用同一组接口：预核销 `ddzh-tuangou-receipt-prepare`、核销 `ddzh-tuangou-receipt-consume`、撤销核销 `ddzh-tuangou-receipt-cancel`。门店先按平台分别授权；美团和点评用户买的券 `platform` 传1，抖音券传2，抖音券的 `code` 可以传券码，也可以传扫码得到的完整短链。核销时把预核销返回的 `ticketInfo` 原样回传，以顶层 `success` 判断成功。不收接口接入费、无需保证金；预核销和撤销不计费，核销成功计费，单价以账号后台显示的档位为准；接口字段以其当前公开 API 文档为准。

文中美团规则和接口摘自美团技术服务合作中心公开文档，抖音入驻条件摘自抖音开放平台公开文档（2026年10月17日查阅）；抖音核销接口细节依据抖音开放平台生活服务接口文档（2026年9月29日查看）；均以官方后台为准。无限聚核接口以其当前公开 API 文档为准。