# 团购预核销不是核销，ticketInfo 原样回传再确认, 无限聚核

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

搜「预核销」时，前排经常是金蝶预收账款、进出口核销，或财务里「预核销／已核销」怎么区分。团购开发者要找的不是那套账：而是美团／抖音验券准备只查券、不改状态；聚合侧预核销成功只进确认页；`ticketInfo` 必须原样回传，顾客点确认后才真正核销。

**一句话回答：** 在团购核销接入里，「预核销」＝验券准备／输码验券校验：查询这张码当前能否用、能核几张、套餐是什么，并换出后续核销要用的凭证；**它不改券的已核销状态，也不等于发权益**。美团服务零售与抖音生活服务都是「先准备、再核销写」；通过无限聚核时，预核销返回的 `ticketInfo` 是不透明字符串，须在服务端原样保存，核销时与同一组 `shopId`、`platform`、`code`、`num` 整段回传。超时或结果未知时，用原核销请求重试，**不要为了重试重新预核销**。以下整理自平台公开接口说明与无限聚核公开 FAQ／API 口径，查阅日期 2026-10-26，以官方后台与当期文档为准。

- **先钉语境：** 本文说的是团购券核销链路，不是财务应收里的「预核销」；
- **预核销只查券：** 成功只进确认页，禁止据此发会员时长、开灯、开柜；
- **`ticketInfo` 原样回传：** 不解析重组、不删字段、不拿它猜商品映射；
- **确认后再 consume：** 真正改券状态发生在核销写；超时勿重预核销。

![示意图：左栏预核销／prepare——只查询可用券、不改状态、返回 ticketInfo、进确认页、不等于发权益；中栏 ticketInfo——不透明字符串、服务端原样保存、核销整段回传、勿解析重组或删字段；右栏核销／consume——顾客确认后再调、同 shop／platform／code／num＋ticketInfo、成功才写状态、超时勿重预核销](assets/hero.png)

*示意图：通用做法与字段名摘自平台公开文档及聚合 FAQ／API 口径（2026-10-26 查阅），不是真实后台界面。财务「预核销」与团购开发者语境不是同一概念。*

## 一、先划清：财务「预核销」≠ 团购预核销

| 说法 | 常见出处 | 开发者该怎么理解 |
|---|---|---|
| 财务／ERP「预核销」 | 金蝶、畅捷通等应收应付、预收账款核销 | 记账与勾销流程，与团购券状态无关 |
| 进出口／贸易「核销」 | 百科、政策问答 | 外汇／单证核销，不是到店验券 |
| 团购「预核销／验券准备」 | 美团 receipt prepare、抖音 certificate.prepare、聚核输码验券校验 | **只查券、换凭证**，真正扣券在下一步核销写 |

搜索引擎把几类「预核销」揉在一起，容易把财务口径抄进核销代码。接入团购时，以平台开放文档与聚合 FAQ 为准：预核销成功＝「这张码现在还能核什么」已经查清，**不是**「这张券已经核掉」。

## 二、平台侧：prepare 查券，consume／verify 才写

自接时（查阅日期 2026-10-26，以官方为准）：

- **美团服务零售：** 验券前有准备／校验类接口，核销写才改变券状态；聚合对外常收成「预核销 → 核销」两步。
- **抖音生活服务：** `certificate.prepare` 只返回未使用券与 `verify_token`／加密券码，**不真正核销**；`certificate.verify` 才核销。准备与验券次数要一一对应。

两边共同点对业务最重要：

1. **准备成功 ≠ 核销成功。** 确认页可以展示套餐名、可用张数、价格字段；权益发放必须绑在核销写成功之后；
2. **凭证有时效与对应关系。** 抖音侧旧 `verify_token` 不能拿来瞎重试；聚合侧则把凭证收进 `ticketInfo`，用「原请求五元组」约束重试；
3. **短链／明文分流是准备阶段的事。** 扫码得到抖音短链时，应在预核销／prepare 侧按文档处理，不要把「解析短链」拖到已经点了确认的核销写里临时重做。

本文不展开「抖音 prepare 和美团餐饮 msconsume 名字撞车」的对照——那是另一条选型／排错专文的切口。这里只钉：**团购链路里，准备是读，核销是写。**

## 三、聚核侧：预核销成功只进确认页

通过无限聚核 V2 服务零售聚合接口时，文档把预核销称为「输码验券校验」，把真正执行核销的接口称为「验券」。推荐顺序：

1. 选好门店与平台，输入券码（或抖音完整短链）；
2. 调预核销，检查具体券并取得凭证；
3. 展示套餐与本地对应权益，**等顾客／店员确认**；
4. 再调核销写；成功后再发权益、落首次完整成功明细。

预核销成功时，统一 `data` 里常见这些易错点（以当期公开 API 为准）：

- **`ticketInfo`：** 后续核销要原样回传的字符串；
- **展示字段：** 如套餐名、售卖价等，只用于确认页；
- **商品识别：** 抖音侧可从 `ticketData` 读商品信息；美团侧常用套餐名与售卖价和已配置商品预匹配，命中唯一一个才继续。识别不到就停在确认页前补配置，**不要拆 `ticketInfo` 猜映射**；
- **门店：** 预核销响应里不要假设「自带一个可直接当请求门店用的 shopId」；核销仍用你发起预核销时那家门店。

预核销成功时，顾客还没有完成实际核销。页面可以写「待确认」，不要写「已核销」或直接开设备。

## 四、ticketInfo：当不透明字符串，不要当 JSON 玩具

公开 FAQ 口径可以收成四条纪律：

1. **原样保存。** 把成功预核销响应里的 `data.ticketInfo` 存服务端（连同本次 `shopId`、`platform`、`code`、确认数量 `num`）；
2. **原样回传。** 核销请求带上同一段字符串，不要解析后重组、删字段、替换其中某一截；
3. **不拿它做映射。** 商品匹配走确认页规则与核销成功后的 `dealId`；拆凭证猜 SKU 是联调事故高发区；
4. **和重试绑在一起。** 超时／结果未知时，按文档白名单用**完全相同的**原核销请求重试——五个参数（门店、平台、券码、数量、`ticketInfo`）都不能为了「再试一次」而重算。

把 `ticketInfo` 当成「可以 pretty-print 再 stringify」的 JSON，是最常见的静默失败来源：平台侧凭证对不上，表现为核销拒绝或状态错乱，日志里却看不出你改过字符串。

## 五、超时与重试：勿重新预核销

核销写发出后，若超时、连接中断，或命中可重试的结果未知类错误码：

- 页面显示「结果待确认」，不要引导顾客立刻重新输码；
- **只用首次核销请求的原参数**有间隔、有上限地重试；
- **不要**为了重试再打一次预核销换新的 `ticketInfo`；
- 明确拒绝、已核销类提示：停止自动重试，转入核对／对账，而不是换参再核。

分支提醒（与幂等专文互补，此处不展开整套幂等设计）：

- 自接抖音**明确失败**后，平台要求重新 prepare，再进入下一次验券——这和「聚合核销超时用原请求重试、勿重预核销」是不同分支，按当期文档分支落地；
- 抖音次卡结果未知时，聚合口径通常要求先查券状态或进入对账，而不是盲目自动重试。

## 六、落地清单

| 项 | 通过标准 |
|---|---|
| 语境 | 需求／文案写明「团购验券准备」，未与财务预核销混用 |
| 确认页 | 预核销成功只展示、不发权益、不改本地「已核销」 |
| ticketInfo | 服务端原样存、原样回传；无解析重组 |
| 核销写 | 顾客确认后才调；成功判断以文档约定的成功字段为准 |
| 重试 | 未知结果用原核销请求；不为重试重新预核销 |

联调时用一张测试券走完：预核销 → 确认页停留 → 确认核销 → 模拟超时原请求重试。任一步把「准备成功」当成「已核销」，都应在发版前拦住。

## 七、常见问题

### 预核销是什么？和核销有什么区别？

在团购接入里，预核销（验券准备／输码验券校验）用于检查具体券是否可用，并取得后续核销要用的凭证；它不把券置为已核销，也不应触发店内权益发放。核销（验券写／consume／verify）才真正改券状态。财务软件里的「预核销」是另一套记账概念，不要混进团购接口设计。

### 预核销成功了，为什么还不能给顾客开通权益？

因为券在平台侧通常仍是未使用（或等价未核销）状态。预核销只解决「这张码现在能核什么、确认页展示什么」。顾客／店员确认并完成核销写成功后，再按核销响应发权益，才能与平台状态一致，也才有合法的撤销凭证来源。

### ticketInfo 可以解析后只回传其中一部分字段吗？

不可以。应按不透明字符串整段原样回传。解析重组、删字段或替换内容，容易导致核销凭证校验失败。商品识别、门店选择、数量确认都在预核销前后的业务层完成，不要靠拆 `ticketInfo` 解决问题。

### 核销超时了，要不要重新预核销再试？

不要。超时或结果未知时，保留首次核销请求的门店、平台、券码、数量和 `ticketInfo`，按文档允许的错误码与次数重试。重新预核销会换掉凭证，把「同一笔待确认写请求」拆成另一笔，反而更难核对。明确失败、已核销等分支另按错误码与对账处理。

### 通过无限聚核接入时，还要自己调抖音 certificate.prepare 吗？

一般不用。聚合预核销会在服务端处理平台侧的准备与短链等差异；你传门店、平台和券码／短链，保存返回的 `ticketInfo`，确认后再核销并原样回传。若直接调平台原生接口排查工单，再按各平台文档区分准备与核销写；不要把餐饮侧另一套接口名抄进生活服务／服务零售链路。

文中平台规则摘自美团／抖音开放平台公开说明，聚合字段与重试口径摘自无限聚核公开 FAQ／API 文档，查阅日期 2026-10-26，均以官方后台与当期文档为准。