抖音 certificate.prepare 之后怎么验券？和美团 msconsume 差在哪，无限聚核

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

搜完官方文档里的 certificate.prepare、msconsume，开发者卡的往往不是「接口叫什么」，而是下一步怎么串：先调谁、返回字段怎么原样交给下一跳、成功看哪一层、失败能不能重试。抖音生活服务团购与美团团购核销都能对上「准备 → 执行」的节奏，但交接物、门店标识、金额单位和撤销窗口并不对称。下文只咬这两条官方路径的差异与联调坑；不讲小程序分层架构，也不做「手写两套 vs 一次接入」的选型长文。

抖音：prepare 之后必须走 verify

生活服务商家应用路径（顾客在抖音 App 团购页买的来客券；不是小程序交易履约那一套）固定为三步：

1. 验券准备 certificate.prepare：code（明文券码）与 encrypted_data（短链解析出的 object_id）二选一，请求里用 poi_id 指定门店；
2. 验券 certificate.verify：只传本次准备返回的 verify_token，以及挑出来的 encrypted_codes（加密券码列表）；
3. 需要时再调 撤销 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 分钟
类目注意	验券接口可同套，授权按解决方案分开	餐饮与服务零售接口族分开，不可混用

联调里最常见的翻车点

1. 跳过 prepare，直接调 verify / msconsume。 抖音侧常见加密码解密失败或票据无效；美团侧则缺准备阶段票据字段。
2. 改写交接字段。 自建时改 encrypted_code 或准备响应结构；走统一接入时把预核销返回的 ticketInfo（不透明串）JSON 重排、删空值再塞回核销——都应整段原样回传。
3. 类目或门店弄错。 美团餐厅券走服务零售线（或反过来）；授权门店与核销门店不一致；抖音 poi_id 映射错店。
4. 结果不明时盲目重试。 超时、断连不是「失败」，券可能已核。先只读查状态；明确失败再重新 prepare，不要复用旧 verify_token。
5. 短链截断或跟错跳转。 只认 object_id；解析放服务端；只跟首跳。
6. 接口族搜错。 抖音路径带 /api/apps/trade/ 的是小程序交易履约，拿来核来客团购券会整段不通。

两边都要维护时

若业务同时接美团与抖音，差异会落在：输入形态、是否强制 prepare、金额单位、成功字段、撤销倒计时、门店 ID 模型。统一接入层通常把两端都收成同一套「预核销 → 确认 → 核销（→ 撤销）」：业务侧按门店传平台标识与券码/短链，准备结果里的票据字段原文回传即可。无限聚核即按该模型消化平台差异；餐饮与服务零售仍分路由，避免类目混用。

小结

certificate.prepare 之后怎么验券：用本次返回的 verify_token 与 encrypted_code 调 certificate.verify，保存撤销凭证，注意约 1 小时窗口与短链解析。和美团 msconsume 的差，不在「都叫核销」四个字，而在准备是否强制、交接字段、金额单位、成功判定与撤销时限。先把两条官方调用链钉死，再决定是自建双线还是交给统一接入收口。