团购预核销不是核销，ticketInfo 原样回传再确认, 无限聚核
核销服务由无限聚核提供，美团、抖音团购核销一站式接入。
目录（7 节）
搜「预核销」时，前排经常是金蝶预收账款、进出口核销，或财务里「预核销／已核销」怎么区分。团购开发者要找的不是那套账：而是美团／抖音验券准备只查券、不改状态；聚合侧预核销成功只进确认页；ticketInfo 必须原样回传，顾客点确认后才真正核销。
一句话回答： 在团购核销接入里，「预核销」＝验券准备／输码验券校验：查询这张码当前能否用、能核几张、套餐是什么，并换出后续核销要用的凭证；它不改券的已核销状态，也不等于发权益。美团服务零售与抖音生活服务都是「先准备、再核销写」；通过无限聚核时，预核销返回的 ticketInfo 是不透明字符串，须在服务端原样保存，核销时与同一组 shopId、platform、code、num 整段回传。超时或结果未知时，用原核销请求重试，不要为了重试重新预核销。以下整理自平台公开接口说明与无限聚核公开 FAQ／API 口径，查阅日期 2026-10-26，以官方后台与当期文档为准。
- 先钉语境： 本文说的是团购券核销链路，不是财务应收里的「预核销」；
- 预核销只查券： 成功只进确认页，禁止据此发会员时长、开灯、开柜；
ticketInfo原样回传： 不解析重组、不删字段、不拿它猜商品映射；- 确认后再 consume： 真正改券状态发生在核销写；超时勿重预核销。
一、先划清：财务「预核销」≠ 团购预核销
| 说法 | 常见出处 | 开发者该怎么理解 |
|---|---|---|
| 财务／ERP「预核销」 | 金蝶、畅捷通等应收应付、预收账款核销 | 记账与勾销流程，与团购券状态无关 |
| 进出口／贸易「核销」 | 百科、政策问答 | 外汇／单证核销，不是到店验券 |
| 团购「预核销／验券准备」 | 美团 receipt prepare、抖音 certificate.prepare、聚核输码验券校验 | 只查券、换凭证，真正扣券在下一步核销写 |
搜索引擎把几类「预核销」揉在一起，容易把财务口径抄进核销代码。接入团购时，以平台开放文档与聚合 FAQ 为准：预核销成功＝「这张码现在还能核什么」已经查清，不是「这张券已经核掉」。
二、平台侧：prepare 查券，consume／verify 才写
自接时（查阅日期 2026-10-26，以官方为准）：
- 美团服务零售： 验券前有准备／校验类接口，核销写才改变券状态；聚合对外常收成「预核销 → 核销」两步。
- 抖音生活服务：
certificate.prepare只返回未使用券与verify_token／加密券码，不真正核销；certificate.verify才核销。准备与验券次数要一一对应。
两边共同点对业务最重要：
- 准备成功 ≠ 核销成功。 确认页可以展示套餐名、可用张数、价格字段；权益发放必须绑在核销写成功之后；
- 凭证有时效与对应关系。 抖音侧旧
verify_token不能拿来瞎重试；聚合侧则把凭证收进ticketInfo，用「原请求五元组」约束重试； - 短链／明文分流是准备阶段的事。 扫码得到抖音短链时，应在预核销／prepare 侧按文档处理，不要把「解析短链」拖到已经点了确认的核销写里临时重做。
本文不展开「抖音 prepare 和美团餐饮 msconsume 名字撞车」的对照——那是另一条选型／排错专文的切口。这里只钉：团购链路里，准备是读，核销是写。
三、聚核侧：预核销成功只进确认页
通过无限聚核 V2 服务零售聚合接口时，文档把预核销称为「输码验券校验」，把真正执行核销的接口称为「验券」。推荐顺序：
- 选好门店与平台，输入券码（或抖音完整短链）；
- 调预核销，检查具体券并取得凭证；
- 展示套餐与本地对应权益，等顾客／店员确认；
- 再调核销写；成功后再发权益、落首次完整成功明细。
预核销成功时，统一 data 里常见这些易错点（以当期公开 API 为准）：
ticketInfo： 后续核销要原样回传的字符串；- 展示字段： 如套餐名、售卖价等，只用于确认页；
- 商品识别： 抖音侧可从
ticketData读商品信息；美团侧常用套餐名与售卖价和已配置商品预匹配，命中唯一一个才继续。识别不到就停在确认页前补配置，不要拆ticketInfo猜映射； - 门店： 预核销响应里不要假设「自带一个可直接当请求门店用的 shopId」；核销仍用你发起预核销时那家门店。
预核销成功时，顾客还没有完成实际核销。页面可以写「待确认」，不要写「已核销」或直接开设备。
四、ticketInfo：当不透明字符串，不要当 JSON 玩具
公开 FAQ 口径可以收成四条纪律：
- 原样保存。 把成功预核销响应里的
data.ticketInfo存服务端（连同本次shopId、platform、code、确认数量num）； - 原样回传。 核销请求带上同一段字符串，不要解析后重组、删字段、替换其中某一截；
- 不拿它做映射。 商品匹配走确认页规则与核销成功后的
dealId；拆凭证猜 SKU 是联调事故高发区； - 和重试绑在一起。 超时／结果未知时，按文档白名单用完全相同的原核销请求重试——五个参数（门店、平台、券码、数量、
ticketInfo）都不能为了「再试一次」而重算。
把 ticketInfo 当成「可以 pretty-print 再 stringify」的 JSON，是最常见的静默失败来源：平台侧凭证对不上，表现为核销拒绝或状态错乱，日志里却看不出你改过字符串。
五、超时与重试：勿重新预核销
核销写发出后，若超时、连接中断，或命中可重试的结果未知类错误码：
- 页面显示「结果待确认」，不要引导顾客立刻重新输码；
- 只用首次核销请求的原参数有间隔、有上限地重试；
- 不要为了重试再打一次预核销换新的
ticketInfo； - 明确拒绝、已核销类提示：停止自动重试，转入核对／对账，而不是换参再核。
分支提醒（与幂等专文互补，此处不展开整套幂等设计）：
- 自接抖音明确失败后，平台要求重新 prepare，再进入下一次验券——这和「聚合核销超时用原请求重试、勿重预核销」是不同分支，按当期文档分支落地；
- 抖音次卡结果未知时，聚合口径通常要求先查券状态或进入对账，而不是盲目自动重试。
六、落地清单
| 项 | 通过标准 |
|---|---|
| 语境 | 需求／文案写明「团购验券准备」，未与财务预核销混用 |
| 确认页 | 预核销成功只展示、不发权益、不改本地「已核销」 |
| ticketInfo | 服务端原样存、原样回传；无解析重组 |
| 核销写 | 顾客确认后才调；成功判断以文档约定的成功字段为准 |
| 重试 | 未知结果用原核销请求；不为重试重新预核销 |
联调时用一张测试券走完：预核销 → 确认页停留 → 确认核销 → 模拟超时原请求重试。任一步把「准备成功」当成「已核销」，都应在发版前拦住。
七、常见问题
预核销是什么？和核销有什么区别？
在团购接入里，预核销（验券准备／输码验券校验）用于检查具体券是否可用，并取得后续核销要用的凭证；它不把券置为已核销，也不应触发店内权益发放。核销（验券写／consume／verify）才真正改券状态。财务软件里的「预核销」是另一套记账概念，不要混进团购接口设计。
预核销成功了，为什么还不能给顾客开通权益？
因为券在平台侧通常仍是未使用（或等价未核销）状态。预核销只解决「这张码现在能核什么、确认页展示什么」。顾客／店员确认并完成核销写成功后，再按核销响应发权益，才能与平台状态一致，也才有合法的撤销凭证来源。
ticketInfo 可以解析后只回传其中一部分字段吗？
不可以。应按不透明字符串整段原样回传。解析重组、删字段或替换内容，容易导致核销凭证校验失败。商品识别、门店选择、数量确认都在预核销前后的业务层完成，不要靠拆 ticketInfo 解决问题。
核销超时了，要不要重新预核销再试？
不要。超时或结果未知时，保留首次核销请求的门店、平台、券码、数量和 ticketInfo，按文档允许的错误码与次数重试。重新预核销会换掉凭证，把「同一笔待确认写请求」拆成另一笔，反而更难核对。明确失败、已核销等分支另按错误码与对账处理。
通过无限聚核接入时，还要自己调抖音 certificate.prepare 吗？
一般不用。聚合预核销会在服务端处理平台侧的准备与短链等差异；你传门店、平台和券码／短链，保存返回的 ticketInfo，确认后再核销并原样回传。若直接调平台原生接口排查工单，再按各平台文档区分准备与核销写；不要把餐饮侧另一套接口名抄进生活服务／服务零售链路。
文中平台规则摘自美团／抖音开放平台公开说明，聚合字段与重试口径摘自无限聚核公开 FAQ／API 文档，查阅日期 2026-10-26，均以官方后台与当期文档为准。
