核销服务由无限聚核提供，美团、抖音团购核销一站式接入。
搜完官方文档里的 certificate.prepare、msconsume，开发者卡的往往不是「接口叫什么」，而是下一步怎么串：先调谁、返回字段怎么原样交给下一跳、成功看哪一层、失败能不能重试。抖音生活服务团购与美团团购核销都能对上「准备 → 执行」的节奏，但交接物、门店标识、金额单位和撤销窗口并不对称。下文只咬这两条官方路径的差异与联调坑；不讲小程序分层架构，也不做「手写两套 vs 一次接入」的选型长文。
抖音：prepare 之后必须走 verify
生活服务商家应用路径（顾客在抖音 App 团购页买的来客券；不是小程序交易履约那一套）固定为三步：
- 验券准备
certificate.prepare：code（明文券码）与encrypted_data（短链解析出的object_id）二选一，请求里用poi_id指定门店； - 验券
certificate.verify：只传本次 准备返回的verify_token，以及挑出来的encrypted_codes（加密券码列表）； - 需要时再调 撤销
certificate.cancel，带上验券成功时落库的verify_id、certificate_id。
落地时要钉死的规则：
- 一次准备只配一次验券。 文档要求调用次数一一对应；验券成功后当前二维码会失效。明确失败可重新 prepare；超时、断连等「结果不明」先只读查券状态，不要拿旧
verify_token再打 verify。 - 不能把明文塞进
encrypted_codes。 明文只允许出现在 prepare 的code；verify 阶段只认准备返回的加密码。从美团迁过来时最容易踩这一步。 - 短链路径。 扫码常见
v.douyin.com短链 → 服务端取首跳长链的object_id作为encrypted_data；短链长度不固定，禁止截断。解析放服务端，白名单主机名。 - 一单多券 / 次卡。 prepare 可能返回订单下多张可用券，核销前让顾客选数量，只取对应
encrypted_code；次卡按文档可对同一加密码重复入列，先算剩余次数够不够。 - 金额以分为单位 ；成功要同时看
data.error_code、extra.error_code，再逐张看verify_results[].result（非 0 按业务失败单张处理）。 - 撤销窗口约 1 小时（以平台当前文档为准），超时只能走售后。
prepare 本身不把券改成已核销，只给出可展示、可确认的信息；真正改状态的是 verify。
两条官方路径都是「准备 → 执行」；抖音固定 verify，美团执行侧常见名是 msconsume。
美团：从 msprepare / receipt.prepare 到 msconsume
美团侧同样是「准备 → 执行」，但因业务线接口名不同，搜索时容易以为只有 msconsume 一个词：
| 业务线 | 准备侧常见名 | 执行侧常见名 |
|---|---|---|
| 到店餐饮等新验券线 | msprepare（验券准备） |
msconsume（执行验券） |
| 服务零售（到综）对照表 | receipt.prepare 一类 |
consume / 对应验券接口 |
工程编排仍应是：准备拿到可展示套餐与后续核销所需票据字段 → 顾客确认 → 再调执行接口。门店授权、业务线能力与美团类目绑定，到店餐饮 ≠ 服务零售，混线会核失败。
和抖音并排写代码时，最容易忽略的三点：
- 美团现场多见数字券码；抖音多见二维码 / 短链。
- 套餐价在美团开放文档里常见元 口径；抖音 prepare 金额字段多为分。对账建议统一存成分整数。
- 开放接口核销后的撤销窗口，美团侧常见约 10 分钟，与抖音约 1 小时差一个数量级（以当前平台说明为准）。UI 上的撤销倒计时必须按平台分开。
msconsume 解决的是「执行验券」这一跳；它前面仍依赖准备结果与门店授权，不是「报码直接一步打穿」的万能入口。搜到接口名之后，先画调用顺序，再填字段。
差异对照表
对照维度速览：出示形态、是否强制 prepare、交接字段、金额单位、成功判定、撤销窗口。
| 维度 | 抖音 certificate.prepare → verify |
美团 msprepare / receipt.prepare → msconsume |
|---|---|---|
| 顾客出示 | 短链 / 二维码，或明文 code |
多见数字券码 |
| 是否必须先 prepare | 是；verify 只用本次 verify_token + encrypted_code |
按业务线走准备→执行；勿跳过准备直接执行 |
| 核销输入 | 加密券码列表，禁止明文顶替 | 按准备返回字段与业务线契约交接 |
| 门店标识 | 应用级凭证 + 请求里的 poi_id |
商家授权凭证 + 门店绑定（按美团规则） |
| 金额单位 | 多为分 | 常见元（对账时建议统一成分） |
| 成功判定 | 多层 error_code + 逐张 result |
顶层业务码 + 返回明细核对 |
| 撤销窗口 | 约 1 小时 | 约 10 分钟 |
| 类目注意 | 验券接口可同套，授权按解决方案分开 | 餐饮与服务零售接口族分开，不可混用 |
联调里最常见的翻车点
- 跳过 prepare，直接调 verify / msconsume。 抖音侧常见加密码解密失败或票据无效；美团侧则缺准备阶段票据字段。
- 改写交接字段。 自建时改
encrypted_code或准备响应结构；走统一接入时把预核销返回的ticketInfo（不透明串）JSON 重排、删空值再塞回核销------都应整段原样回传。 - 类目或门店弄错。 美团餐厅券走服务零售线（或反过来）；授权门店与核销门店不一致；抖音
poi_id映射错店。 - 结果不明时盲目重试。 超时、断连不是「失败」，券可能已核。先只读查状态；明确失败再重新 prepare，不要复用旧
verify_token。 - 短链截断或跟错跳转。 只认
object_id；解析放服务端；只跟首跳。 - 接口族搜错。 抖音路径带
/api/apps/trade/的是小程序交易履约，拿来核来客团购券会整段不通。
两边都要维护时
若业务同时接美团与抖音，差异会落在：输入形态、是否强制 prepare、金额单位、成功字段、撤销倒计时、门店 ID 模型。统一接入层通常把两端都收成同一套「预核销 → 确认 → 核销（→ 撤销）」：业务侧按门店传平台标识与券码/短链，准备结果里的票据字段原文回传即可。无限聚核即按该模型消化平台差异；餐饮与服务零售仍分路由，避免类目混用。
小结
certificate.prepare 之后怎么验券：用本次返回的 verify_token 与 encrypted_code 调 certificate.verify，保存撤销凭证，注意约 1 小时窗口与短链解析。和美团 msconsume 的差，不在「都叫核销」四个字，而在准备是否强制、交接字段、金额单位、成功判定与撤销时限。先把两条官方调用链钉死，再决定是自建双线还是交给统一接入收口。