# 餐厅怎么接美团、抖音团购核销？到店餐饮接口和服务零售接口的区别

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

给火锅店、快餐店、茶饮店做收银或扫码点餐系统，接团购核销时常遇到两种情况：照着洗车店、健身房那套接口接完，餐厅的美团券却核不了；或者文档里同时出现“到店综合”“服务零售”“到店餐饮”几个名字，不知道餐厅该走哪一套。根子在门店类目：餐厅属于到店餐饮，美团给到店餐饮的是另一套团购接口，返回字段也和服务零售不完全一样。

**一句话回答：** 餐厅的团购券按“到店餐饮”接入。美团的到店餐饮和服务零售（到店综合）是两套团购接口，验券准备、验券、撤销和套餐查询都分开；抖音两类门店用同一套验券接口，门店授权按到店餐饮单独发起。通过无限聚核这类第三方接口接入的，餐饮走 `dining-tuangou-*` 路由，请求和响应结构与服务零售的 `ddzh-tuangou-*` 一致，换路由前缀即可，差别在美团餐饮有一部分字段没有值。

- **先定门店类目。** 以门店在美团、抖音上的经营类目为准，正餐、火锅、快餐、饮品等到店餐饮门店走餐饮接口；
- **授权单独发起。** 餐饮门店用餐饮授权链接，店主用管理这家门店的平台账号确认后才能核销；
- **核销流程不变。** 输码验券校验、验券、按凭证撤销，`ticketInfo` 整段原样回传；
- **空字段要兜底。** 美团餐饮的核销结果里没有平台订单号、手机号和支付明细，对账改用券码和无限聚核账单订单号；
- **代金券、买单分开处理。** 美团餐饮代金券可以正常核销；美团买单核销成功时没有撤销凭证，不能通过聚合接口撤销。

![餐厅团购券走哪套接口示意：服务零售门店（洗车、健身房、台球等）美团走到店综合团购接口，无限聚核路由为 ddzh-tuangou；到店餐饮门店美团走单独的到店餐饮团购接口，抖音和服务零售用同一套验券接口但按到店餐饮单独授权，无限聚核路由为 dining-tuangou；两者请求和响应结构一致，美团餐饮部分字段没有值](assets/hero.png)

*示意图：接口划分按美团、抖音开放平台和无限聚核当前公开API文档整理（2026年10月4日），以平台规则为准。*

## 一、先分清：餐厅属于哪一类门店

| 比较项 | 服务零售门店 | 到店餐饮门店 |
|---|---|---|
| 常见业态 | 洗车、健身房、台球、羽毛球馆等 | 正餐、火锅、快餐、烧烤、饮品等 |
| 美团团购接口 | 到店综合团购接口：输码验券、验券、撤销验券 | 到店餐饮团购接口：验券准备、验券、撤销验券、套餐查询，与服务零售分开 |
| 抖音团购接口 | 生活服务验券准备、验券、撤销核销 | 同一套验券接口，返回字段含义相同 |
| 门店授权 | 按服务零售发起 | 按到店餐饮单独发起 |
| 常见券型 | 单次券、次卡、多人套餐 | 套餐券、代金券；美团还有买单类核销 |
| 无限聚核路由 | `ddzh-tuangou-*` | `dining-tuangou-*` |

接口划分按美团、抖音开放平台的接口说明和无限聚核当前公开API文档整理，2026年10月4日核对；美团餐饮原生路径里的准备／核销接口名常写作 `msprepare`／`msconsume`（2026-10-17 补充），与服务零售的输码验券校验／验券不是同一路径，也与抖音的 `certificate.prepare`／`verify` 无关。日常通过无限聚核接入餐厅时，优先用 `dining-tuangou-*` 聚合路由；只有排查原生报文或调用原生代理时才需要直接面对 `msconsume`。

类目看的是门店在美团、抖音上的经营类目，不是自己系统里怎么配置，拿不准的到平台商家后台查看。在无限聚核里，业务类目在建商户时选定；同一个老板既开餐厅又开台球厅的，把两家店分别建在到店餐饮和服务零售两个商户下。

类目和接口对不上，常见现象是授权完成了，验券却报错。通过无限聚核接入时，类目不是到店餐饮的门店调用餐饮路由，会返回 HTTP 400 和 `BUSINESS_CATEGORY_MISMATCH`，按门店类目换成对应的路由即可。

## 二、餐厅接入六步

![餐厅接入团购核销六步示意：建商户时业务类目选到店餐饮，生成餐饮授权链接，店主用平台账号确认授权，拉团购列表建立套餐对照，输码验券校验并保存 ticketInfo，验券后按下标保存撤销凭证](assets/01-dining-flow.png)

*流程示意：路由和参数以无限聚核当前公开API文档为准。*

1. **建商户，业务类目选到店餐饮。** 在无限聚核控制台新建商户；调用“创建商户或门店”接口的，`businessCategory` 传 `dining`（服务零售是 `service_retail`），再在商户下建具体门店；
2. **生成餐饮授权链接。** 调用“获取餐饮聚合授权链接”，`shopId` 传具体门店，`platform` 传1（美团）或2（抖音）；成功返回 HTTP 201，`data` 是完整的授权链接，抖音的链接24小时内有效；
3. **店主确认授权。** 把链接发给店主，店主用管理这家门店的平台账号登录确认。生成链接不等于授权完成，确认后核对平台显示的门店名是不是这家店；
4. **拉团购列表，建对照表。** 调用“获取团购信息”，把每个套餐的 `dealId` 和店内的菜品、份数或抵扣面值对应起来；
5. **输码验券校验。** 顾客出示券码后先校验，确认页展示套餐名和售价，保存返回的 `data.ticketInfo` 原文；
6. **验券，保存凭证。** 核销时 `ticketInfo` 整段原样回传；成功后按 `data[i]` 保存对应的 `consumeCredential[i]`，撤销时要用。

```http
POST /api/hexiao/v2/dining/storemap/authorize-url
Authorization: Bearer <key>
Content-Type: application/json

{
  "shopId": 123,
  "platform": 2
}
```

```http
POST /api/hexiao/v2/dining-tuangou-receipt-prepare
Authorization: Bearer <key>
Content-Type: application/json

{
  "shopId": 123,
  "platform": 1,
  "code": "<顾客出示的券码>"
}
```

```http
POST /api/hexiao/v2/dining-tuangou-receipt-consume
Authorization: Bearer <key>
Content-Type: application/json

{
  "shopId": 123,
  "platform": 1,
  "code": "<与校验时相同的券码>",
  "ticketInfo": "<输码验券校验返回的 ticketInfo 原文>",
  "num": 1
}
```

`shopId` 是具体门店的系统门店 ID，传商户 ID 会返回 HTTP 400、`code` 10001。抖音的 `code` 在校验时也可以传顾客扫码得到的完整短链，接口只访问短链的首跳并提取 `object_id`，解析失败时不会继续请求核销。

## 三、美团餐饮：哪些字段没有值

抖音餐饮和服务零售走同一套上游接口，返回字段含义相同。美团餐饮的上游不同，无限聚核把它转成和服务零售一致的结构，但有一部分字段美团餐饮不返回，固定为空值。

![美团餐饮验券成功响应示意：wxdgOrderNo、receiptCode 和 consumeCredential 用于对账和撤销；orderId、mobile、paymentDetail、merchantAmount、platformAmount、receiptEndDate 固定为空，actualPayAmount 为 null](assets/02-meituan-dining-fields.png)

*字段示意：数据为虚构，字段取值以无限聚核当前公开API文档为准。*

按无限聚核当前公开API文档：

| 接口 | 字段 | 美团餐饮的取值 | 开发时怎么处理 |
|---|---|---|---|
| 输码验券校验 | `data.payAmount` | 由套餐售价（元）换算成分 | 可以用来展示售价 |
| 输码验券校验 | `data.actualPayAmount` | 固定为 null | 不要按0处理 |
| 输码验券校验 | `data.ticketData` | 美团餐饮验券准备的原始数据，结构与服务零售不同 | 按美团餐饮单独解析 |
| 验券 | `data[].orderId` | 空字符串 | 不能当对账主键 |
| 验券 | `data[].mobile` | 空字符串 | 不要靠手机号识别顾客 |
| 验券 | `data[].paymentDetail` | 空数组 | 结算金额查结算明细 |
| 验券 | `merchantAmount`、`platformAmount` | 空字符串 | 同上 |
| 验券 | `data[].receiptEndDate` | 空字符串 | 券有效期以平台为准 |
| 验券 | `bizType`、`tgTimesCardFlag` | 固定为0和 false | 不要用来判断券型 |
| 验券 | `data[].dealGroupId` | 与 `dealId` 相同 | 按 `dealId` 对照套餐 |
| 验券 | `data[].receiptCode` | 美团返回的规范券码，可能是14位 | 原样保存，不要按顾客输入的位数截断 |
| 获取团购信息 | `receiptBeginDate`、`receiptEndDate` | 空字符串 | 券有效期以平台为准 |
| 获取团购信息 | `extraMap` | 不返回 | 原始套餐看 `platformResult` |

几处要单独处理：

- **售价有，实付没有。** 美团餐饮预核销的 `payAmount` 由套餐售价（元）换算成分，`dealPrice` 是售价（元），`actualPayAmount` 固定为 null。报表里有“实付”一栏的，美团餐饮留空，不要按0元统计；
- **门市价和售价的来源。** 验券结果的 `dealMarketPrice` 取该券码明细的原价，缺省时取套餐门市价；`dealPrice` 取该券码明细的售价；
- **对账换主键。** 美团餐饮的 `data[].orderId` 是空字符串，本地记录用 `receiptCode` 加顶层 `wxdgOrderNo`（无限聚核系统账单订单号）关联。需要每张券的结算金额时，可以用无限聚核的美团餐饮原生接口“结算明细”按券码查询，券码参数不超过12位；
- **团购列表只有在售套餐。** 美团餐饮的套餐列表由服务端拿到全量后按 `offset`、`limit` 分页，只返回在售套餐，`saleStatus` 固定为2，券有效期字段为空；原始套餐记录在 `platformResult` 里，带 `isVoucher`、`dealMenu` 等字段，结构由平台决定，只用于展示和排查，不承诺稳定。

```go
// 餐饮验券成功后逐项入库：美团餐饮的 orderId、mobile、paymentDetail 为空，不参与关联
func saveDining(ctx context.Context, tx Tx, c Confirmed, resp ConsumeResponse) error {
	noCredential := c.Platform == 1 && len(resp.ConsumeCredential) == 0 // 美团买单：成功但没有撤销凭证
	if !noCredential && len(resp.ConsumeCredential) != len(resp.Data) {
		return markManualReview(ctx, c, resp) // 条数对不上，转人工
	}
	for i, item := range resp.Data {
		rec := Redemption{
			ShopID:      c.ShopID,
			Platform:    c.Platform,
			Category:    "dining",         // 撤销时只走餐饮撤销接口
			ReceiptCode: item.ReceiptCode, // 原样保存，美团餐饮可能是14位
			DealID:      fmt.Sprint(item.DealID),
			DealPrice:   item.DealPrice,   // 售卖价，单位元
			WxdgOrderNo: resp.WxdgOrderNo, // 无限聚核账单订单号，不和 item.OrderID 混用
			Cancelable:  !noCredential,
		}
		if !noCredential {
			rec.Credential = resp.ConsumeCredential[i]
		}
		if err := tx.SaveRedemption(ctx, rec); err != nil {
			return err
		}
	}
	return nil
}
```

## 四、代金券和买单

- **代金券照常核销。** 按无限聚核当前公开API文档，美团餐饮代金券可以正常校验与核销，流程和套餐券一样。代金券在店里按面值抵扣，不对应具体菜品；套餐列表的原始记录里有 `isVoucher` 标识，店内以对照表配置的类型为准。扫码点餐里套餐券和代金券分别在什么时候核销、怎么抵扣，见本站《扫码点餐小程序怎么用美团、抖音团购券？套餐券、代金券的核销时机和抵扣做法》一文；
- **买单没有撤销凭证。** 美团餐饮有一类核销走买单渠道，核销成功时 `data` 有值，顶层 `consumeCredential` 为空数组，不能通过聚合撤销接口撤销，核销成功同样计费。系统里把这类记录标记为“不可在线撤销”，前台不显示撤销按钮，需要处理的到美团商家后台按平台规则操作。收银台怎么识别买单、交班怎么对账，见本站《餐饮收银台怎么接团购验券？扫码枪输码、买单识别和交班对账》一文。

## 五、撤销：凭证不能跨接口混用

```http
POST /api/hexiao/v2/dining-tuangou-receipt-cancel
Authorization: Bearer <key>
Content-Type: application/json

{
  "shopId": 123,
  "platform": 1,
  "consumeCredential": ["<验券成功响应里的 consumeCredential[i]>"]
}
```

- **只用餐饮凭证。** 餐饮撤销接口只接受餐饮聚合核销返回的 `consumeCredential`；零售核销凭证、美团餐饮原生接口的核销记录不能用它撤销，餐饮凭证传到零售撤销接口也会被拒。本地记录要存门店类目，撤销时按类目选接口；
- **逐项看结果。** 一次传1到10个凭证，`data[].status` 为 `succeeded`、`rejected` 或 `unknown`；全部撤销成功时顶层 `success` 才为 `true`；
- **被拒看原因。** 平台拒绝时 `message` 为“平台拒绝撤销：<平台原因>”，例如限频、商户余额不足；原因只用于展示和排查，程序以 `status` 为准；
- **结果未知先查再撤。** 撤销接口不做幂等，相同凭证重复请求会再次发给平台；`unknown` 时先查券状态或对账，再决定是否重新撤销；
- **时限以平台为准。** 抖音按开放平台说明是核销后1小时内；美团餐饮的撤销时限以美团规则为准，核错了当场撤；
- **再核销要重新校验。** 撤销后顾客再来用这张券，重新走输码验券校验，不要复用旧的 `ticketInfo`。

## 六、以无限聚核为例

| 功能 | 路由（POST） | 计费 |
|---|---|---|
| 获取餐饮聚合授权链接 | `/api/hexiao/v2/dining/storemap/authorize-url` | 免费 |
| 获取团购信息 | `/api/hexiao/v2/dining-tuangou-deal-queryshopdeal` | 免费 |
| 输码验券校验 | `/api/hexiao/v2/dining-tuangou-receipt-prepare` | 免费 |
| 验券 | `/api/hexiao/v2/dining-tuangou-receipt-consume` | 核销成功计费 |
| 撤销核销 | `/api/hexiao/v2/dining-tuangou-receipt-cancel` | 免费 |

- **已接服务零售的，换前缀即可。** 餐饮路由的请求和响应字段结构与 `ddzh-tuangou-*` 完全一致，按门店类目选前缀；
- **只认 `success`。** 顶层 `code` 通常为10000，但不能单独用来判断成功；
- **重复请求返回10500。** 相同业务请求命中已成功的核销时，返回 `success` 为 `false`、`code` 10500，`message` 里给出核销时间和门店；这不能替代业务系统按券码和自己的订单去重；
- **统一重试规则。** 只有 `errorCode` 为 `CONSUME_IN_PROGRESS`、`RESULT_UNKNOWN`、`SERVICE_UNAVAILABLE`、`PROVIDER_UNAVAILABLE`，或请求超时没拿到响应时，才用首次请求的原样参数有间隔、有上限地重试；`PLATFORM_REJECTED` 和 `ALREADY_CONSUMED`（10500）停止重试。平台明确拒绝的会带平台原因，例如 `code` 11006“此券号不存在，请与消费者确认提供的券号是否正确！”；
- **美团餐饮原生接口。** 除聚合接口外，无限聚核还提供美团餐饮原生接口，请求头用 `X-Store-Id` 传系统门店 ID，返回美团原始报文，可以查门店验券历史、套餐映射、团购券交易快照、结算明细、项目限制条件等。聚合接口核销的记录可以用原生撤销接口撤销，原生接口核销的记录不能用聚合撤销接口撤销。

## 七、三种接入方式怎么选

| 比较项 | 成品餐饮收银或点餐系统 | 自己申请美团、抖音开放能力 | 通过第三方核销接口（如无限聚核） |
|---|---|---|---|
| 餐饮和服务零售 | 看系统是否支持餐饮类目和两个平台 | 美团两条业务线分别对接；抖音按到店餐饮方案授权 | 一套请求结构，按门店类目换路由前缀 |
| 资质和资金 | 按系统方收费 | 美团服务零售团购核销开通时保证金账户余额须达到10万元，到店餐饮的开通要求以美团技术服务合作中心为准；抖音生活服务商家应用代开发要求注册资本不低于100万元等（2026年9月10日核对，以官方后台为准） | 不需要自己满足平台服务商的保证金和安全资质；不收接口接入费，核销按当前账号适用的充值档位计费，撤销核销免费 |
| 灵活度 | 受限于系统现有功能 | 高 | 高：点餐、收银和对账逻辑自己掌控 |
| 主要风险 | 数据和功能依赖系统方 | 周期长，两条业务线都要对接和验收 | 依赖服务商稳定性，要先看文档、错误码和对账能力 |

## 八、上线前验收清单

用测试门店和测试券把下面每一条走一遍：

- 到店餐饮门店调用餐饮路由正常；服务零售门店调用餐饮路由，返回 `BUSINESS_CATEGORY_MISMATCH`；
- 传商户 ID 返回 HTTP 400，界面提示选择具体门店；
- 美团、抖音分别完成餐饮授权，平台显示的门店名和这家店一致；
- 美团套餐券、代金券各核销一张：本地记录有券码、套餐 ID、无限聚核账单订单号和撤销凭证；
- 美团餐饮 `actualPayAmount` 为 null、`orderId` 为空：页面和报表不报错，实付不显示成0元；
- 抖音手输券码和扫码短链都能完成校验；
- 核销后撤销一张：本地状态同步回退；餐饮凭证不会被送到零售撤销接口；
- 连点两次核销：业务系统自己拦住；请求已经发出的，收到10500不重复入账；
- 美团买单核销（门店有这类核销时）：记录标记为不可在线撤销，前台不显示撤销按钮。

## 九、常见问题

### 美团餐饮接口里的 msconsume 和聚合 dining-tuangou 是什么关系？

`msconsume`（以及配对的 `msprepare`）是美团到店餐饮原生核销路径上的接口名；`dining-tuangou-receipt-prepare`／`consume` 是无限聚核的餐饮聚合路由，对业务侧提供与服务零售一致的请求结构。接餐厅团购核销时优先走聚合餐饮路由；需要原生报文或原生能力时再使用美团餐饮原生接口。二者撤销凭证不要交叉使用。查阅日期 2026-10-17。

### 餐厅的美团团购券，能用服务零售的核销接口核销吗？

不能混用。美团的到店餐饮和服务零售（到店综合）是两套团购接口，餐厅的券要走到店餐饮这一套，门店授权也按到店餐饮发起。通过无限聚核接入的，到店餐饮门店调用 `dining-tuangou-*` 路由；类目不是到店餐饮的门店调用餐饮路由，会返回 HTTP 400 和 `BUSINESS_CATEGORY_MISMATCH`。

### 抖音餐饮团购核销和服务零售有什么不同？

验券接口相同：抖音餐饮和服务零售走同一套验券准备、验券、撤销接口，返回字段含义也相同。不同在门店授权，餐饮门店按到店餐饮单独授权。通过无限聚核接入时，抖音餐饮门店同样调用 `dining-tuangou-*` 路由，授权用“获取餐饮聚合授权链接”生成的链接，24小时内有效。

### 美团餐饮代金券能通过接口核销吗？

能。按无限聚核当前公开API文档，美团餐饮代金券可以正常校验与核销，流程和套餐券一样：先输码验券校验，再把返回的 `ticketInfo` 原样传给验券接口。代金券在店里按面值抵扣，不对应具体菜品。

### 为什么美团餐饮核销返回的 orderId 是空的？

美团餐饮的验券结果不返回平台订单号。无限聚核为了和服务零售保持同一套结构，把 `orderId`、`mobile`、`merchantAmount`、`platformAmount`、`receiptEndDate` 固定为空字符串，`paymentDetail` 固定为空数组。本地对账用 `receiptCode` 和顶层 `wxdgOrderNo` 关联，需要每张券的结算金额时查结算明细。

### 美团买单核销成功后能撤销吗？

不能通过聚合接口撤销。按无限聚核当前公开API文档，美团买单核销成功时 `consumeCredential` 为空数组，没有撤销凭证，核销成功同样计费。系统里把这类记录标记为不可在线撤销，需要处理的到美团商家后台按平台规则操作。

### 已经接了无限聚核服务零售接口，加餐饮要改多少代码？

改动集中在四处：按门店类目把路由前缀从 `ddzh-tuangou-` 换成 `dining-tuangou-`，请求和响应结构不变；餐饮门店改用餐饮授权链接；处理美团餐饮的空字段和买单无撤销凭证；餐饮和零售的撤销凭证分开保存，撤销时按类目选接口。

### 一个老板同时开了餐厅和台球厅，怎么接？

按类目分开接。在无限聚核里业务类目在建商户时选定，餐厅建在到店餐饮商户下，台球厅建在服务零售商户下，两家店分别授权、分别调用对应路由。自己的系统按门店记录类目，调用时据此选择路由前缀。

餐饮核销、撤销接口的字段和错误码以无限聚核当前公开API文档为准。