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

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

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

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

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

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

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

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

二、餐厅接入六步

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]，撤销时要用。

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

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

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

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

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，解析失败时不会继续请求核销。

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

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

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

几处要单独处理：

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

// 餐饮验券成功后逐项入库：美团餐饮的 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 为空数组，不能通过聚合撤销接口撤销，核销成功同样计费。系统里把这类记录标记为“不可在线撤销”，前台不显示撤销按钮，需要处理的到美团商家后台按平台规则操作。收银台怎么识别买单、交班怎么对账，见本站《餐饮收银台怎么接团购验券？扫码枪输码、买单识别和交班对账》一文。

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

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。

六、以无限聚核为例

• 已接服务零售的，换前缀即可。 餐饮路由的请求和响应字段结构与 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，返回美团原始报文，可以查门店验券历史、套餐映射、团购券交易快照、结算明细、项目限制条件等。聚合接口核销的记录可以用原生撤销接口撤销，原生接口核销的记录不能用聚合撤销接口撤销。

七、三种接入方式怎么选

八、上线前验收清单

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

• 到店餐饮门店调用餐饮路由正常；服务零售门店调用餐饮路由，返回 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文档为准。