# 大众点评团购券怎么核销？和美团券是同一个接口吗

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

给健身房、美发店、台球厅做门店系统，美团团购核销刚接好，店主就来问：有顾客拿的是大众点评App里买的券，系统能不能核？要不要再接一个点评的接口，再授权一次？去搜“大众点评核销接口”“点评验券接口”，搜到的多半是原北极星开放平台时期的资料，看不出现在该怎么接。

答案就在接口文档里：点评用户买的券交给哪个接口，返回里怎么标出来，门店要授权几次。下面按美团技术服务合作中心当前公开文档（2026年10月15日查阅）逐条说明。

**一句话回答：** 是同一套接口。美团技术服务合作中心服务零售的输码验券校验、验券、撤销验券，同时处理美团用户和点评用户买的团购券，输码验券校验返回的 `platform` 字段标明下单平台（1-美团，2-点评）。门店按服务零售业务授权一次即可，不用另外申请点评接口，也不用单独授权点评。通过无限聚核接入时，点评券和美团券一样，`platform` 传1（美团）。

- **官方字段写明了点评。** 《输码验券校验》返回 `platform`：“下单用户平台，1-美团，2-点评”；
- **授权一次，两边的券都能核。** 授权按业务划分，服务零售团购在 businessId 58 下授权，授权实体是美团门店；
- **核销流程完全一样。** 输码验券校验、验券、需要时撤销验券，点评券没有单独的分支；
- **来源看字段，不看券码。** 要按点评、美团分开统计的，在校验时保存 `platform`；另有两个查询接口的编号和它相反；
- **大众点评免费试不是团购券。** 它是另一项业务，接口、开通条件和授权都单独算。

![大众点评团购券和美团团购券走同一套接口示意：顾客在美团App或大众点评App购买同一家门店的团购；门店按服务零售业务（businessId 58）由商家用美团账号授权一次，授权实体是美团门店，不需要另外申请点评接口或单独授权点评；核销依次调用输码验券校验、验券和撤销验券，校验返回的 platform 为1表示美团用户下单、为2表示点评用户下单；大众点评免费试是另一项业务](assets/hero.png)

*示意图：依据美团技术服务合作中心《输码验券校验》接口文档和业务授权说明整理，2026年10月15日查阅，以官方后台为准。*

## 一、为什么说是同一个接口

美团技术服务合作中心的文档里，至少有五处能说明点评用户买的团购券和美团用户买的券走的是同一套接口：

| 依据 | 出处 | 原文要点 |
|---|---|---|
| 返回字段 | 《输码验券校验》接口文档 | `platform`：“下单用户平台，1-美团，2-点评” |
| 错误码1024 | 同一接口的业务错误码 | “当前券码所属用户账号已被冻结，请尝试拨打点评客服电话咨询” |
| 测试下单 | 《服务零售测试对接说明》 | 测试门店完成授权后，“使用美团App或点评App，扫码进入测试门店，模拟用户交易，测试团购核销或预订的业务逻辑” |
| 点餐自助核销 | 到店餐饮《顾客点餐自助核销》业务介绍 | 可查询的团购券“包括用户在美团平台、点评平台购买的套餐券及代金券” |
| 北极星对照 | 《北极星迁移指引》《接口明细对照表》 | 原大众点评的北极星开放平台由美团技术服务合作中心承接，团购接口逐个对应到 `/ddzh/tuangou/*` |

第一条是直接证据。服务零售团购核销的推荐接口只有一组输码验券校验、验券、撤销验券，没有为点评另设一组。点评用户下单的券，校验时返回 `platform` 为2，其余字段的结构和美团用户的券一样。

第二条是旁证：同一个接口的错误码里直接出现了“点评客服”，说明这个接口本来就会处理点评用户的券。

第三条说明了授权范围。测试门店只授权一次，用美团App或点评App下的单都能拿来测团购核销。同一份说明里还提醒：“有的门店是点评门店，如果美团App扫码进入不了，请使用大众点评App扫码。”

第四条说明到店餐饮也是这样：餐厅另有一套团购接口，其中的《顾客点餐自助核销》写明覆盖点评平台购买的券。

第五条是历史原因。北极星开放平台原本是大众点评的开放平台，原站标题是“美团 - 北极星开放平台”，现在它的技术及运营服务由美团技术服务合作中心提供。北极星时期的团购接口在新平台都有对应，例如 `tuangou.receipt.prepare` 对应 `/ddzh/tuangou/receipt/prepare`，`tuangou.receipt.consume` 对应 `/ddzh/tuangou/receipt/consume`。过去通过点评开放平台接的团购核销，现在就是美团的服务零售团购核销。

![美团技术服务合作中心服务零售团购核销流程图：分商品映射、验券、撤销验券三段，三方服务商先调用获取团购信息建立商家商品和美团商品的映射，商家输入或扫描团购券码后调用输码验券校验，确定验券张数后调用验券，验错或多验时调用撤销验券；整条流程没有按美团、点评区分的分支](assets/official-mt-tuangou-flow.png)

*美团技术服务合作中心官方文档原图 · 2026年10月15日查阅。*

官方的团购核销流程图分商品映射、验券、撤销验券三段，整条链路只有一条，没有“美团券走这边、点评券走那边”的分支。

## 二、一张点评券的核销过程

点评券和美团券在每个环节调用的接口相同，差别只在几个字段上：

| 环节 | 接口 | 点评券和美团券的差别 |
|---|---|---|
| 门店授权 | 服务零售门店授权（businessId 58） | 没有差别，授权一次 |
| 商品映射 | 获取团购信息 `/ddzh/tuangou/deal/queryshopdeal` | 请求参数 `source` 指定售卖平台：1-大众点评，2-美团，默认为1 |
| 校验 | 输码验券校验 `/ddzh/tuangou/receipt/prepare` | 返回 `platform`：美团用户为1，点评用户为2 |
| 核销 | 验券 `/ddzh/tuangou/receipt/consume` | 没有差别 |
| 撤销 | 撤销验券 `/ddzh/tuangou/receipt/reverseconsume` | 没有差别 |
| 查询 | 查询已验券信息、验券记录 | 返回字段里没有 `platform` |

按接口文档，一次核销这样走：

1. **校验。** 店员输入或扫描券码，系统调用输码验券校验，业务参数只有 `receiptCode`（团购券码，必须未验证）。返回可验证张数 `count`、套餐ID `dealId`、商品名称 `dealTitle`、商品售卖价格 `dealPrice`、下单用户平台 `platform` 等；
2. **验券。** 店员确认后调用验券，传 `receiptCode`、验券数量 `count`（不可多于100个）、用于标识幂等性的请求ID `requestId`，以及 `appShopAccount`、`appShopAccountName`。后两个是商家在三方系统里的登录账号和账号名，只用于记录验券者，不参与验券校验。一次可以验多张，多张券需在用户同一订单下，可验张数以校验返回为准；
3. **撤销。** 验错或多验时调用撤销验券，传 `receiptCode` 和套餐ID `dealId`（不是 `dealGroupId`）。接口说明写明：仅支持团购撤销，不支持平台次卡和拼团；只可撤销当天核销且未超过10分钟的团购券。

点评用户的券，校验返回大致如下（示例数据为虚构，只保留部分字段）：

```json
{
  "code": "OP_SUCCESS",
  "msg": "成功",
  "data": {
    "count": 1,
    "receiptCode": "<顾客出示的券码>",
    "dealId": 100001,
    "dealGroupId": 200001,
    "dealTitle": "单次健身体验（示例）",
    "dealPrice": 39.9,
    "platform": 2
  }
}
```

`platform` 为2，表示这张券是点评用户下单的。接下来的验券请求和美团用户的券完全一样，不需要多传任何参数。

## 三、门店授权：一次就够，不用单独授权点评

- **授权按业务划分。** 技术服务合作中心每个业务（businessId）的授权相互独立。服务零售门店授权的 businessId 是58，覆盖团购、评价、预订；文档里团购核销没有另设点评业务，点评用户买的券也在58下核销；
- **授权实体是美团门店。** 授权完成后，58业务返回的 `opBizCode`、`opBizName` 是混淆后的美团门店ID和门店名称，官方建议保存它和三方门店的映射；
- **商家用美团账号确认。** 官方业务授权流程里，商户在美团官方登录授权页输入美团账号和密码，开发者再用授权 code 换取 AccessToken；
- **token 按业务使用。** 用业务A的 appAuthToken 访问业务B的接口，会报“appAuthToken 不属于当前业务 鉴权失败”。服务零售团购核销用58业务下拿到的 token；到店餐饮、大众点评免费试是另外的业务，要各自开通、各自授权；
- **老系统存的点评门店ID。** 北极星时期保存的 `openShopUuid` 是混淆后的点评门店ID，对接技术服务合作中心时与 `opBizCode`（58业务）、`opPoiId`（混淆后的美团门店ID）一一对应，但值不同。迁移时用平台提供的数据互转接口拿到 `opPoiId` 保存，不需要按点评、美团各存一套门店。

![美团业务授权流程图：开发者应用拼装授权URL，平台校验开发者信息后打开官方登录授权页，商户输入美团账号和密码，平台携带授权code跳转到开发者的回调地址，开发者用授权code换取AccessToken，平台校验授权信息后返回Token信息，授权完成](assets/official-mt-auth-flow.png)

*美团技术服务合作中心官方文档原图 · 2026年10月15日查阅。*

按这套授权模型，没有单独“授权点评”这一步：门店授权给你的应用以后，这家门店在美团、点评两边卖出的团购券都能核。

## 四、开发时要注意的六件事

1. **不用问顾客在哪个App买的。** 券码输进来直接走同一个校验接口，下单平台由返回的 `platform` 给出。界面上不必让店员选“美团券”还是“点评券”；店员只需分清美团和抖音，抖音是另一套接口；
2. **`platform` 只在校验时拿得到。** 按接口文档，验券、查询已验券信息、验券记录的返回字段里都没有它。要按来源统计的，校验时把它和券码一起存下来，验券成功后写进核销记录；
3. **另外两个接口编号相反。** 获取团购信息的 `source`、手机号查询可用团购券的 `platform`，都是“1-大众点评，2-美团”，和校验返回的 `platform`（1-美团，2-点评）正好相反。常量按接口分开定义，不要共用一套数字，入库时统一成自己的枚举；
4. **团购列表按售卖平台分别查。** 获取团购信息的 `source` 默认为1，即大众点评。只传默认值，可能拿不到只在美团侧售卖的团购；这是按文档推断，联调时以实测为准。建立商品映射时，两个售卖平台分别查询，按返回结果建对照；
5. **1024照原文提示。** 校验返回1024（“当前券码所属用户账号已被冻结，请尝试拨打点评客服电话咨询”）时，不要重试，把原文显示给店员，由顾客联系客服；
6. **来源不从券码推断。** 判断一张券是点评还是美团用户买的，只看 `platform`，不要从券码本身去猜。

## 五、点评相关能力，各走哪个业务

搜“点评核销”的人，常把几样东西混在一起。在美团技术服务合作中心，它们分属不同业务：

![点评相关能力对照示意：点评用户买的团购券在非餐饮门店走服务零售（businessId 58）团购核销，用输码验券校验、验券、撤销验券，校验返回 platform=2；餐厅门店走到店餐饮业务，顾客点餐自助核销写明含点评平台购买的套餐券及代金券；点评评价是服务零售58业务的评价模块，提供查询评论数据和门店星级接口，不是核销；大众点评免费试是独立业务（业务ID 55），有门店活动映射、验券准备、执行验券等接口，不是团购券](assets/01-dianping-capabilities.png)

*示意图：按美团技术服务合作中心业务文档整理，2026年10月15日查阅，以官方后台为准。*

| 能力 | 属于哪个业务 | 主要接口 | 和团购券核销的关系 |
|---|---|---|---|
| 点评团购券（非餐饮门店） | 服务零售（businessId 58）团购核销 | 输码验券校验、验券、撤销验券 | 就是团购券核销本身，校验返回 `platform` 为2 |
| 点评团购券（餐厅） | 到店餐饮 | 到店餐饮的团购接口，与服务零售分开 | 同样是团购券，按到店餐饮单独开通、授权 |
| 点评评价 | 服务零售（businessId 58）评价模块 | 单一门店查询评论数据 `/ddzh/ugc/queryshopreview`、门店星级和单项分 `/ddzh/ugc/querystar` | 不是核销；同一门店授权，授权范围要包含评价 |
| 大众点评免费试 | 大众点评免费试（业务ID 55） | 门店活动映射、查询活动限制、验券准备、执行验券、已验券码查询、门店验券历史 | 不是团购券，单独开通、单独授权 |

几处补充：

- **餐厅单独看。** 服务零售的《输码验券校验》在接口说明里写的是“适用于非餐饮、非洗涤行业”。餐厅属于到店餐饮，团购接口和服务零售分开；到店餐饮的《顾客点餐自助核销》同样写明可查询用户在美团平台、点评平台购买的套餐券及代金券。洗涤类门店接入前，先向平台对接运营确认适用的接口；
- **评价和核销共用门店授权。** 授权的 scope 是更新机制，多次授权要传全部所需的 scope；团购核销和评价都要用的，授权时一起带上；
- **免费试是什么。** 大众点评免费试原名霸王餐，是大众点评App官方提供给商家0元使用的积累评价的产品。用户线上报名，中奖后持中奖凭证到店免费体验，并在7天内完成体验评价。它的凭证不是用户花钱买的团购券，有自己的一套验券接口，不要拿团购的输码验券校验去处理；
- **免费试的开通条件。** 按《合作条件说明》，大众点评免费试和服务零售一样，要 Web 应用防火墙证明、等保证明或网络信息安全保险二选一、申请开通时保证金账户余额达到10万元、签署技术合作合同及隐私协议（2026年10月15日查阅，以官方后台为准）。

## 六、以无限聚核为例：点评券怎么核

无限聚核覆盖美团（含大众点评）、抖音的服务零售团购核销和到店餐饮团购核销。点评用户买的券按美团券处理，接法和美团券完全一样：

1. **注册拿 API Key。** API Key 保存在服务端，不放进小程序前端，请求头用 `Authorization: Bearer <key>`；
2. **建商户和门店。** 先建商户，再为每家实际门店建门店，得到 `shopId`；商户只用于组织门店，本身不做授权和核销；
3. **获取美团授权链接。** 调用 `get/auth/url`，传 `shopId` 和 `platform`=1，把链接发给商家，由商家在美团页面确认。拿到链接不等于授权完成；这一次授权覆盖美团、点评两边的券，不需要另做“点评授权”；
4. **校验和核销。** 输码验券校验 `ddzh-tuangou-receipt-prepare`（免费）时 `platform` 传1；验券 `ddzh-tuangou-receipt-consume` 时把校验返回的 `ticketInfo` 整段原样回传；以顶层 `success` 判断成功，按下标保存 `data[i]` 与 `consumeCredential[i]`；
5. **需要时撤销。** 调用撤销核销 `ddzh-tuangou-receipt-cancel`，传核销时保存的 `consumeCredential`，撤销免费。

几点说明：

- **聚合接口没有点评平台值。** 聚合接口的 `platform` 只有1（美团）和2（抖音），点评券传1。需要按点评、美团分开统计的，先看无限聚核当前公开API文档里返回了哪些字段，再决定做法；
- **原生查询接口沿用美团编号。** 通过无限聚核调用的美团原生接口里，获取团购信息的 `source` 是1-大众点评、2-美团，默认1；手机号查询可用团购券的 `platform` 是1-大众点评、2-美团，默认2。这两处和聚合接口的 `platform` 含义不同，别混用；
- **餐厅用餐饮聚合接口。** 到店餐饮门店另有餐饮聚合接口，点评券同样按美团处理；
- **计费和美团券相同。** 预核销、团购列表、撤销核销不计费，核销成功才计费，同一笔核销多单只计费一次，单价以账号后台显示的档位为准；
- **重试按统一口径。** 只有 `errorCode` 为 `CONSUME_IN_PROGRESS`、`RESULT_UNKNOWN`、`SERVICE_UNAVAILABLE`、`PROVIDER_UNAVAILABLE`，或请求超时时，才有间隔、有上限地用完全相同的原请求重试；`PLATFORM_REJECTED` 和 `ALREADY_CONSUMED`（10500）停止，不要重新预核销、换参数或让顾客重输码。

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

## 七、三种接入方式：从点评券的角度比较

| 比较项 | 门店系统自带 | 自己申请成为美团服务商 | 接第三方接口（如无限聚核） |
|---|---|---|---|
| 点评券能否核销 | 系统接的是美团团购核销接口，就同时覆盖点评用户买的券 | 能，同一组接口 | 能，`platform` 传1 |
| 门店授权 | 在系统里完成美团授权 | 服务零售58业务门店授权，商家用美团账号确认 | 获取授权链接时 `platform` 传1，商家在美团页面确认 |
| 区分点评、美团来源 | 看系统报表是否提供 | 校验时保存 `platform`（1-美团，2-点评） | 聚合接口不区分；需要时以无限聚核当前公开API文档为准 |
| 资质和资金 | 按系统方收费 | 服务零售开通时保证金账户余额须达到10万元，另需 Web 应用防火墙证明、等保证明或网络信息安全保险二选一、签署合同（2026年10月15日查阅，以官方后台为准） | 不收接口接入费，无需保证金；核销成功计费，预核销、团购列表、撤销不计费 |
| 适合谁 | 不做开发、直接用成品系统的门店 | 为多家商家提供系统、有独立技术团队的企业 | 有自己的系统，不想自己承担服务商门槛的开发者 |

## 八、上线前核对清单

用测试门店（自己申请的）或已授权的真实门店，把下面每一条走一遍：

- 门店只做了一次美团授权，没有单独的“点评授权”步骤；
- 分别用美团App和点评App买一张券，校验时 `platform` 分别返回1和2（自己申请的路径）；通过无限聚核的，两张券都以 `platform`=1 校验成功；
- 两张券都能验券成功，本地记录归到同一家门店；
- 需要区分来源的，`platform` 在校验时已存下，验券成功后写进核销记录；
- 获取团购信息、手机号查询可用团购券的常量单独定义，没有和校验返回的 `platform` 共用一套数字；
- 商品映射分别查了两个售卖平台的团购，没有只依赖默认的 `source`；
- 撤销一张点评券：当天、10分钟内能撤销，本地状态同步回退；
- 校验返回1024时，界面显示平台原文，没有自动重试；
- 大众点评免费试的凭证没有进入团购核销流程；
- 餐厅门店走的是到店餐饮接口，没有调用服务零售的输码验券校验。

测试门店每个企业目前只能申请1个；用美团App扫码进不了测试门店时，按官方说明改用大众点评App扫码。

## 九、常见问题

### 大众点评有单独的团购核销接口吗？

按美团技术服务合作中心当前文档（2026年10月15日查阅），没有单独为点评设的团购核销接口。点评用户买的团购券和美团用户买的券，用同一个输码验券校验、验券、撤销验券接口核销，校验返回的 `platform` 为2表示点评用户下单。原大众点评的北极星开放平台，技术及运营服务已由美团技术服务合作中心提供。

### 门店已经授权了美团，还要单独授权点评吗？

不需要。授权按业务划分，服务零售团购核销在 businessId 58 下授权，授权实体是美团门店，商家用美团账号确认。授权完成后，这家门店在美团、点评两边卖出的团购券都能核。到店餐饮、大众点评免费试是另外的业务，要用的话各自开通、各自授权。

### 怎么知道一张券是点评用户买的？

看输码验券校验返回的 `platform`：1是美团，2是点评。按接口文档，验券、查询已验券信息、验券记录都不返回这个字段，需要按来源统计的，校验时就要存下来。另外，获取团购信息的 `source` 和手机号查询可用团购券的 `platform` 编号相反（1-大众点评，2-美团），写代码时按接口分开定义。

### 北极星时期接的点评团购接口，现在还能用吗？

不要再依赖它。技术服务合作中心《北极星迁移指引》写的是“原北极星已于2025年6月25日正式下线”；北极星原站首页的《迁移通知》写的是文档中心及控制台“逐步进行下线处理”，已合作企业自2025年7月2日起可登录技术服务合作中心逐步完成迁移。两处说法并存，都以官方当前说明为准。迁移时团购接口按《接口明细对照表》逐个替换，例如 `tuangou.receipt.prepare` 换成 `/ddzh/tuangou/receipt/prepare`，授权从 session 换成 access_token。

### 大众点评免费试的券，能用团购核销接口核吗？

不要这样做。大众点评免费试（原名霸王餐）是大众点评App官方提供给商家0元使用的积累评价的产品，用户中奖后持中奖凭证到店体验，不是花钱买的团购券。它在技术服务合作中心是独立业务，有门店活动映射、验券准备、执行验券等自己的接口，开通条件同样包括 Web 应用防火墙证明、等保证明或网络信息安全保险二选一、保证金账户余额10万元，要单独开通、单独授权。

### 通过无限聚核核销点评券，platform 传什么？

传1（美团）。聚合接口的 `platform` 只有1（美团）和2（抖音），没有单独的点评值，点评用户买的券按美团券处理：门店用 `platform`=1 获取美团授权链接，商家确认一次授权，之后输码验券校验、验券、撤销核销都传1。预核销和撤销不计费，核销成功才计费。

文中平台规则和接口字段摘自美团技术服务合作中心公开文档（2026年10月15日查阅），以官方后台为准；无限聚核接口以其当前公开API文档为准。