# 同一团购在美团和点评都在卖，接口里怎么区分来源平台

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

门店的同一个团购，美团App上在卖，大众点评App上也在卖。核销接好以后，运营提了新需求：核销报表要分开看美团来的券和点评来的券，月底对账也要按渠道拆开。开发者回头翻美团技术服务合作中心的接口文档，发现有三个字段用1和2区分美团、点评，可意思不一样，有的1是美团，有的1是点评；验券接口和验券记录里，又找不到来源字段。

点评券和美团券本来就用同一组服务零售团购接口核销，这一点不再展开。本篇只讲技术细节：来源字段在哪个接口、编号怎么对应、代码怎么写、入库怎么统一、统计和对账怎么按来源拆。字段原文摘自美团技术服务合作中心公开接口文档，2026年10月15日查阅。

**一句话回答：** 核销链路上，只有输码验券校验 `/ddzh/tuangou/receipt/prepare` 的返回字段 `platform` 标明下单用户平台，1-美团，2-点评；验券、查询已验券信息、验券记录的官方文档里都没有这个字段，要在校验时存下，验券成功后写进每张券的记录。获取团购信息的请求参数 `source`、手机号查询可用团购券的请求参数 `platform` 也区分美团和点评，但编号是1-大众点评、2-美团，和校验返回正好相反。代码里按接口分别定义常量，入库前统一换成自己的枚举，例如 `meituan`、`dianping`、`unknown`。

- **来源只有一个出口。** 核销链路上能拿到下单平台的，只有输码验券校验返回的 `platform`；
- **三个字段，两套编号。** 校验返回是1-美团、2-点评；获取团购信息的 `source`、手机号查询的 `platform` 是1-大众点评、2-美团；
- **入库只认统一枚举。** 原始数字连同接口名留档，统计和报表只读自己的枚举，取不到或不认识的值记 `unknown`；
- **对账靠关联本地记录。** 平台的验券记录不带来源，按门店和券码关联本地记录补上；不经过你系统核销的券，按公开字段拿不到来源，单列统计；
- **不影响核销流程。** 区分来源只为统计和对账，点评券、美团券的核销调用完全一样。

![美团服务零售团购接口里三个区分美团和点评的字段对照示意：输码验券校验 prepare 返回的 platform 表示下单用户平台，1是美团、2是点评，核销链路上只有这里返回来源；获取团购信息 queryshopdeal 的请求参数 source 表示售卖平台，1是大众点评、2是美团，默认为1；手机号查询可用团购券 querybymobile 的请求参数 platform，1是大众点评、2是美团；后两个与校验返回的编号相反，应按接口分别定义常量，入库前统一成自己的枚举](assets/hero.png)

*示意图：字段和编号摘自美团技术服务合作中心服务零售团购接口文档，2026年10月15日查阅，以官方文档为准。*

## 一、三个字段，两套编号

美团技术服务合作中心服务零售团购接口里，用1和2区分美团、点评的字段有三个：

| 接口 | 字段 | 官方原文 | 1 代表 | 2 代表 |
|---|---|---|---|---|
| 输码验券校验 | 返回参数 `platform`（int） | “下单用户平台，1-美团，2-点评” | 美团 | 点评 |
| 获取团购信息 | 请求参数 `source`（int，必填） | “售卖平台。1-大众点评，2-美团。默认为1” | 大众点评 | 美团 |
| 手机号查询可用团购券 | 请求参数 `platform`（int，必填） | “平台：1-大众点评，2-美团” | 大众点评 | 美团 |

三个接口的路径分别是 `/ddzh/tuangou/receipt/prepare`、`/ddzh/tuangou/deal/queryshopdeal`、`/ddzh/tuangou/receipt/querybymobile`，都属于服务零售（businessId 58），都需要业务授权。

读这张表，要分清三件事：

1. **含义不一样。** 校验返回的 `platform` 是“下单用户平台”，说的是顾客在哪个App下的单，是核销时读到的事实；获取团购信息的 `source` 是“售卖平台”，手机号查询的 `platform` 原文只写“平台”，这两个都是你发请求时选的查询范围；
2. **方向不一样。** 一个是返回值，两个是请求参数。返回值要做“数字→自己的枚举”，请求参数要做“自己的枚举→数字”，两个方向各写各的转换；
3. **编号相反。** 同样是1，在校验返回里是美团，在另外两个参数里是大众点评。校验返回和手机号查询的请求参数都叫 `platform`，编号却相反，写代码时特别容易混。

还有一处细节：获取团购信息的参数表把 `source` 标为必填，说明里又写“默认为1”。稳妥的做法是每次都显式传值，不依赖默认。

## 二、哪些接口能拿到来源，哪些拿不到

按官方接口文档，团购核销相关的七个接口里，只有输码验券校验在返回里标出下单平台：

| 接口 | 和来源有关的字段 | 入库时怎么处理 |
|---|---|---|
| 输码验券校验 | 返回 `platform`：1-美团，2-点评 | 在这里取来源，和券码、`dealId` 一起存下 |
| 验券 | 文档里没有 `platform` | 返回的 `result[]` 每张券一条记录，来源沿用校验结果 |
| 撤销验券 | 没有 | 只改核销状态，来源不变 |
| 查询已验券信息 | 没有；`verifyChannel` 是验证方式 | 复核单张券时，来源查本地记录 |
| 验券记录 | 没有 | 按门店和券码关联本地记录，补上来源 |
| 获取团购信息 | 请求 `source`：1-大众点评，2-美团 | 商品映射表记下这次查询的售卖平台 |
| 手机号查询可用团购券 | 请求 `platform`：1-大众点评，2-美团 | 只是查询条件；查到的券仍走校验，来源以校验为准 |

![美团服务零售七个团购接口的来源字段对照示意：输码验券校验返回 platform（1-美团，2-点评），核销链路上只有它带下单平台；验券、撤销验券、查询已验券信息、验券记录的文档里都没有 platform，入库时分别沿用校验结果、只改状态、查本地记录、按门店和券码关联本地；获取团购信息的 source 和手机号查询可用团购券的 platform 都是请求参数，1-大众点评、2-美团，编号与校验返回相反](assets/01-source-fields.png)

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

由此得出两条规则：

- **来源只能在校验时取。** 验券、撤销验券、查询已验券信息、验券记录都不返回 `platform`。输码验券校验又只接受未验证的券：请求参数说明写的是“团购券码，必须未验证”，错误码表里也有1008（“此券码已被验……”）。券核掉以后，不能再拿校验接口回查来源；
- **一次验多张券，来源对整批适用。** 官方《团购核销常见问题》写明，一次验多张券时，多张券需要在用户的同一订单下，校验返回的“可验证张数”是同一订单下的可用券码数量。`platform` 是“下单用户平台”，同一订单只有一个下单用户，所以验券返回的 `result[]` 里每张券都沿用这次校验得到的来源。

### 容易认错的五个字段

接口文档里还有几个字段，名字或编号看起来和来源有关，其实不是：

| 字段 | 出现在 | 官方说明 | 注意 |
|---|---|---|---|
| `platformAmount` | 输码验券校验、验券的返回 | “补贴金额（平台分摊，单位：元）” | 名字里有 platform，其实是平台分摊的补贴金额 |
| `verifyChannel` | 查询已验券信息、验券记录的返回 | “验证方式：15-第三方验证;其他验证方式等”；验券记录的示例值是“IOSAPP二维码” | 说的是券怎么被核销，不是顾客在哪个App下单 |
| `saleChannelName` | 获取团购信息的返回 | 文档没有说明，示例值“不限制” | 含义不明确，不要拿它代替 `source` 判断售卖平台 |
| `mobile` | 手机号查询可用团购券的请求 | “点评用户绑定的手机号” | 同一接口的 `platform` 可以选美团，两者怎么配合文档没有展开，联调时两边各测一次 |
| `shopType` | 服务零售品牌批量授权门店的请求 | “门店类型；标识shopIds类型；1:美团门店ID，2:点评门店ID” | 标的是门店ID类型，不是售卖平台；编号碰巧和校验返回一致，常量照样单独定义 |

## 三、代码：按接口定义常量，统一成自己的枚举

下面是一段 Go 示例。编号取自官方接口文档，类型名、函数名和数据都是虚构的：

```go
// 示例：三个接口的编号各用一个类型，自己的系统只认 Channel
package source

// 输码验券校验 /ddzh/tuangou/receipt/prepare 返回的 platform（下单用户平台）
type PreparePlatform int

const (
	PrepareMeituan  PreparePlatform = 1 // 1-美团
	PrepareDianping PreparePlatform = 2 // 2-点评
)

// 获取团购信息 /ddzh/tuangou/deal/queryshopdeal 请求的 source（售卖平台，默认为1）
type DealSource int

const (
	DealSourceDianping DealSource = 1 // 1-大众点评
	DealSourceMeituan  DealSource = 2 // 2-美团
)

// 手机号查询可用团购券 /ddzh/tuangou/receipt/querybymobile 请求的 platform
type MobilePlatform int

const (
	MobileDianping MobilePlatform = 1 // 1-大众点评
	MobileMeituan  MobilePlatform = 2 // 2-美团
)

// Channel 是自己系统的统一枚举：入库、统计、报表只认它
type Channel string

const (
	Meituan  Channel = "meituan"
	Dianping Channel = "dianping"
	Unknown  Channel = "unknown" // 没返回，或返回了不认识的值
)

// FromPrepare 只接收输码验券校验返回的 platform；字段缺失时传 nil
func FromPrepare(p *PreparePlatform) Channel {
	if p == nil {
		return Unknown
	}
	switch *p {
	case PrepareMeituan:
		return Meituan
	case PrepareDianping:
		return Dianping
	default:
		return Unknown // 不猜，也不中断核销
	}
}

// ToDealSource 用于拉团购列表；Unknown 不能拿来查询
func ToDealSource(c Channel) (DealSource, bool) {
	switch c {
	case Meituan:
		return DealSourceMeituan, true
	case Dianping:
		return DealSourceDianping, true
	default:
		return 0, false
	}
}

// ToMobilePlatform 写法同 ToDealSource，返回 MobileMeituan / MobileDianping，略
```

几点说明：

- **三个编号各用一个类型。** Go 里 `PreparePlatform`、`DealSource`、`MobilePlatform` 是不同的类型，把一个直接赋给另一个，编译不过；`DealSource(p)` 这种显式转换虽然能编译，代码评审时应一律退回。要转换，只能经过 `Channel`；
- **只用 switch 显式映射。** 不要写 `3 - x` 这类“翻转”算式，它只在恰好只有1、2两个值时成立，读代码的人也看不出含义。代码里也不要让数字字面量1、2直接参与来源判断；
- **不认识的值记 `unknown`，不中断核销。** 来源只影响统计，不能因为它让顾客的券核不了；
- **Java 写法相同。** 三个 enum 各带一个 `code` 字段和 `fromCode`/`toCode` 方法，统一枚举另外定义，转换方法只放在统一枚举和各自 enum 之间。

校验返回的解析和验券成功后的入库，可以这样写（示例，只列本文用到的字段）：

```go
// 示例：输码验券校验返回的 data
type PrepareData struct {
	Count          int              `json:"count"` // 可验证的张数
	ReceiptCode    string           `json:"receiptCode"`
	DealID         int64            `json:"dealId"`
	Platform       *PreparePlatform `json:"platform"`       // 下单用户平台，1-美团，2-点评
	PlatformAmount string           `json:"platformAmount"` // 补贴金额（平台分摊），不是来源
	BuyTime        int64            `json:"buyTime"`        // 购买时间
}

// 验券返回 result[] 里的一项
type ConsumeItem struct {
	OrderID     string `json:"orderId"`
	ReceiptCode string `json:"receiptCode"`
	DealID      int64  `json:"dealId"`
}

// SaveConsumed 验券成功后入库：每张券一条，来源沿用这次校验的结果
func SaveConsumed(db Store, shopID int64, prep PrepareData, items []ConsumeItem) error {
	ch := FromPrepare(prep.Platform)
	for _, it := range items {
		err := db.Upsert(Record{
			ShopID:        shopID,
			ReceiptCode:   it.ReceiptCode,
			OrderID:       it.OrderID,
			DealID:        it.DealID,
			SourceChannel: ch,            // 统计、报表只读这一列
			RawPlatform:   prep.Platform, // 原始数字只留档
			RawFrom:       "prepare",     // 原始数字来自哪个接口
			Status:        "succeeded",
		})
		if err != nil {
			return err
		}
	}
	return nil
}
```

`Platform` 用指针：文档没有写这个字段一定返回，解析时按可选字段处理，“没返回”和“返回了不认识的值”都记 `unknown`。

## 四、入库归一化：来源跟着每张券走

![入库归一化流程示意：第1步调用输码验券校验，读取返回的 platform 并转成统一枚举，1转为 meituan、2转为 dianping、缺失或其他值转为 unknown；第2步写待确认记录，含券码、dealId、source_channel、原始数字和来源接口名；第3步验券成功后，result 数组里每张券各写一条记录，来源沿用校验结果；第4步撤销验券只把状态改为已撤销，来源不变；第5步次日拉验券记录，按门店和券码关联本地记录补上来源，关联不上的计入 unknown；统计和报表只读统一枚举](assets/02-normalize-flow.png)

*示意图：通用做法，接口字段摘自美团技术服务合作中心服务零售团购接口文档，2026年10月15日查阅；表名、字段名为示例。*

一张券的来源，从校验开始一路带到对账：

1. **校验。** 调用输码验券校验，读取返回的 `platform`，用 `FromPrepare` 转成统一枚举；
2. **写待确认记录。** 发验券请求之前，先写一条待确认记录：券码、门店、`dealId`、`source_channel`、原始数字和它来自哪个接口；
3. **验券成功。** 返回的 `result[]` 里每张券各写一条记录，`source_channel` 沿用第1步的值；
4. **撤销。** 撤销验券成功后，只把状态改成已撤销，`source_channel` 不动；撤销验券的返回同样没有 `platform`；
5. **对账。** 次日拉平台的验券记录，按门店和券码关联本地记录补上来源；关联不上的，计入 `unknown`。

核销记录里和来源有关的列，建议这样设计（列名为示例）：

| 列 | 示例值 | 说明 |
|---|---|---|
| `source_channel` | `dianping` | 统一枚举，统计、报表、对外接口只读这一列 |
| `raw_platform` | `2` | 接口返回的原始数字，只留档 |
| `raw_from` | `prepare` | 原始数字来自哪个接口；单独一个“2”，看不出是点评还是别的 |
| `receipt_code` | 虚构券码 | 每张券一条记录 |
| `order_id` | 虚构订单号 | 验券返回的订单ID |
| `status` | `succeeded` | 核销状态，和来源分开存 |

核销状态和来源要分成两列。超时、结果未知是核销状态的问题，按重试和对账规则处理；来源 `unknown` 只表示“不知道顾客在哪个App下单”，两件事不要混在一个字段里。

## 五、拉团购和按手机号查券：请求方向的编号

### 获取团购信息：两个售卖平台分别拉

获取团购信息用于建立商家商品和美团团购的映射。请求参数有三个：

- `offset`：页码，起始值为1，查第一页传1；
- `limit`：页大小，默认值为100，不能超过100；
- `source`：售卖平台，1-大众点评，2-美团，默认为1。

返回的 `result[]` 里有套餐ID `dealId`、团购ID `dealGroupId`、套餐名称 `title`、套餐价格 `price`、售卖状态 `saleStatus`（1-未开始售卖，2-售卖中，3-售卖结束）、团购状态 `dealGroupStatus`（1-在售团单，2-隐藏单）、团购类型 `dealType`（1-团购套餐，2-代金券）等字段。

`source` 默认为1，即大众点评。只传默认值，查到的是大众点评售卖平台的团购，只在美团侧售卖的团购可能查不到。这一点按官方文档推断，联调时实测确认。在确认之前，按下面的方式做比较稳妥：

- 每次显式传 `source`，1和2各拉一遍，各自分页拉全；
- 映射表保留“售卖平台”一列。文档没有说明同一个团购在两个售卖平台返回的 `dealId` 是否相同，不要预设一定相同或一定不同，用真实门店的数据确认后再决定怎么合并；
- 错误码表里有1045（“该门店下没有有效的团购信息”）。分平台拉取时，某一边返回它，记作“这一边没有有效团购”，不要当成整次同步失败；具体返回以联调为准。

### 手机号查询可用团购券：按团购分平台查

这个接口按手机号查某个团购下可用的券码。请求参数里 `mobile`、`dealGroupId`、`dealId`、`offset`、`limit`、`platform` 都是必填：

- `mobile` 的说明是“点评用户绑定的手机号”，国内手机号为11位；
- `dealGroupId`、`dealId` 指定查哪个团购、哪个套餐，不能一次查全部团购；
- `offset` 是起始位置，从0开始；`limit` 是查询数量，不超过30；
- `platform`：1-大众点评，2-美团。

返回的 `result[]` 里只有团购券码 `serialNumber`。查到券码之后，核销仍然走输码验券校验；入库的来源以校验返回的 `platform` 为准，不用查询时传的参数推断。

### 同名的 offset，含义也不一样

同名不同义的不只是 `platform`。获取团购信息的 `offset` 是页码，起始值为1；手机号查询可用团购券和验券记录的 `offset` 是起始位置，从0开始。分页代码按接口分别写；要共用翻页函数的，把起始值和步进方式作为参数显式传入。

## 六、对账和统计：按来源拆分

来源字段的用途主要有两个：运营按渠道看核销量，财务对账时按来源分开统计。它不改变核销流程，也不改变撤销规则。

平台侧的数据来自验券记录接口（`/ddzh/tuangou/receipt/querylistbydate`）：按日期拉验券记录（`type` 为0）和撤销验券记录（`type` 为1）。返回的每条记录有券码 `receiptCode`、流水号 `flowId`、验券时间 `verifyTime`、退款状态 `refundStatus` 等，但没有来源。逐张比对平台记录和本地记录的通用做法这里不展开，下面只讲多出来的“来源”这一维：

```sql
-- 示例：平台验券记录关联本地记录，按来源统计某门店一天的核销张数
-- 表名、字段和数据均为虚构
SELECT COALESCE(r.source_channel, 'unknown') AS source_channel,
       COUNT(*)                              AS consumed_count
FROM mt_verify_log v                -- 验券记录接口拉回后落表
LEFT JOIN redemption_record r
       ON r.shop_id = v.shop_id
      AND r.receipt_code = v.receipt_code
WHERE v.shop_id = 10001
  AND v.verify_date = '2026-10-14'
  AND v.record_type = 0             -- 0 验券记录，1 撤销验券记录
GROUP BY COALESCE(r.source_channel, 'unknown');
```

结果一般是三行：`meituan`、`dianping`、`unknown`，三行相加等于平台当天的验券记录数。几点说明：

- **以平台记录为主表。** 用 `LEFT JOIN` 从平台记录出发，平台核了而本地没有的券不会漏掉，会落进 `unknown`；
- **`unknown` 单列，不分摊。** 店员在商家后台或其他系统核掉的券，没经过你的输码验券校验，按公开字段拿不到来源。不要按美团、点评的比例把它分摊进去。`unknown` 突然变多，说明店内绕开你的系统核销变多，或者你的系统写库有遗漏，交给逐张对账去查；
- **撤销按原记录归类。** 撤销验券记录（`type` 为1）用同样的方式关联，来源取原核销记录的值；
- **金额别重复相加。** 按来源汇总金额时，校验返回的 `paymentDetail` 是订单维度的支付明细，一单多张券时不要按券重复相加。

## 七、通过无限聚核接入时怎么拿来源

通过无限聚核这类第三方接口接入的，同样的问题换一种问法：聚合接口的 `platform` 和美团原生的 `platform` 是两回事。

- **聚合接口只分美团和抖音。** 无限聚核聚合接口的 `platform` 只有1（美团）和2（抖音），获取授权链接 `get/auth/url`、输码验券校验 `ddzh-tuangou-receipt-prepare` 等都按这个取值。点评用户买的券按美团券处理，传1；聚合接口没有单独的点评值；
- **又一个“2”。** 聚合接口的2是抖音，美团原生校验返回的2是点评。统一枚举里再加一个 `douyin`，聚合接口的 `platform` 单独定义一个类型，转换同样只经过统一枚举；
- **需要来源平台时读原生字段。** 需要来源平台时，可以通过无限聚核提供的美团原生接口读取原始字段，以无限聚核当前公开API文档为准。按它的公开文档，原生的获取团购信息沿用 `source`（1-大众点评，2-美团，默认1），手机号查询可用团购券沿用 `platform`（1-大众点评，2-美团，默认2）。官方文档里手机号查询的 `platform` 是必填、没写默认值，两处写法不同，调用时都显式传值；
- **拿到之前记 `unknown`。** 只走聚合接口时，美团侧记录在拿到原始字段之前，来源记为 `unknown`，不要因为 `platform` 是1就默认成 `meituan`，否则点评券会被算进美团。

核销流程本身不受影响：API Key 保存在服务端，请求头用 `Authorization: Bearer <key>`；预核销免费，验券时把预核销返回的 `ticketInfo` 整段原样回传，以顶层 `success` 判断成功，按下标保存 `data[i]` 和 `consumeCredential[i]`。预核销、团购列表、撤销核销不计费，核销成功才计费，单价以账号后台显示的档位为准。

## 八、上线前核对清单

按《服务零售测试对接说明》，测试门店可以用美团App或点评App扫码进入、模拟下单。用测试门店或已授权的真实门店，把下面每一条走一遍：

- 美团App、点评App各买一张券，校验返回的 `platform` 分别是1和2，入库后 `source_channel` 分别是 `meituan`、`dianping`；
- 一次验多张券，`result[]` 里每张券各一条记录，来源一致；
- 撤销一张点评券，记录状态改为已撤销，来源仍是 `dianping`；
- 单元测试构造一个缺少 `platform` 的校验返回，记录为 `unknown`，核销照常完成；
- 代码里三个编号各有类型或枚举，没有数字字面量1、2直接参与来源判断；
- 获取团购信息每次显式传 `source`，1和2各拉一遍、分页拉全；只传默认值能否拿到美团侧团购，已用真实门店实测；
- 手机号查询两个平台各测一次，查到的券码仍经过校验，来源以校验返回为准；
- 次日用验券记录关联本地，按来源统计的几行相加等于平台记录总数；
- 报表没有用 `platformAmount`、`verifyChannel`、`saleChannelName` 判断来源；
- 通过第三方聚合接口接入的，美团侧记录在拿到原始字段前记为 `unknown`，没有默认成美团。

## 九、常见问题

### 怎么判断一张美团团购券是在点评App买的？

调用美团技术服务合作中心服务零售的输码验券校验 `/ddzh/tuangou/receipt/prepare`，看返回的 `platform`：官方说明是“下单用户平台，1-美团，2-点评”，返回2就是点评用户下的单。验券、撤销验券、查询已验券信息、验券记录的文档里都没有这个字段，所以要在校验时存下来，验券成功后写进每张券的核销记录。

### 获取团购信息的 source 和输码验券校验的 platform 是一回事吗？

不是。`source` 是获取团购信息 `/ddzh/tuangou/deal/queryshopdeal` 的请求参数，表示“售卖平台”，1-大众点评，2-美团，默认为1；`platform` 是输码验券校验返回的“下单用户平台”，1-美团，2-点评。两者一个是请求参数、一个是返回值，编号正好相反。手机号查询可用团购券的请求参数 `platform` 也是1-大众点评、2-美团。代码里按接口分别定义常量，入库前统一成自己的枚举。

### 已经核销的券，还能查出是美团还是点评用户买的吗？

按美团技术服务合作中心当前公开文档的字段，查不到。验券、查询已验券信息、验券记录的返回里都没有 `platform`；输码验券校验的券码参数要求“必须未验证”，核销后不能再拿它回查。核销前没存来源的记录，统计时单列为“未知”，不要按比例分摊到美团或点评。

### 获取团购信息不传 source，会漏掉美团的团购吗？

有这个可能。官方参数说明是“售卖平台。1-大众点评，2-美团。默认为1”，只用默认值查到的是大众点评售卖平台的团购。按官方文档推断，只在美团侧售卖的团购可能查不到，联调时用真实门店实测确认。稳妥的做法是每次显式传 `source`，1和2各拉一遍并分页拉全，映射表里记下售卖平台。

### verifyChannel 或 platformAmount 能用来区分美团和点评吗？

不能。`verifyChannel` 是验证方式，查询已验券信息里的说明是“验证方式：15-第三方验证;其他验证方式等”，说的是券怎么被核销；`platformAmount` 是“补贴金额（平台分摊）”，是金额。区分顾客在哪个App下单，只看输码验券校验返回的 `platform`（1-美团，2-点评）。

### 通过无限聚核接入，能区分点评券和美团券吗？

无限聚核聚合接口的 `platform` 只有1（美团）和2（抖音），点评用户买的券按美团券处理，传1，所以聚合接口这一层只分得出美团（含点评）和抖音。需要来源平台时，可以通过无限聚核提供的美团原生接口读取原始字段，以无限聚核当前公开API文档为准。拿到原始字段之前，美团侧记录的来源记为未知，不要默认成美团。

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