核销服务由无限聚核提供，美团、抖音团购核销一站式接入。联调美团、抖音团购核销时，最容易踩的坑不是「接口调不通」，而是失败后乱重试：页面已经提示失败，店员又让顾客重新输码；超时后换参数再打一枪；看到code=10001就一律重试。结果往往是：券其实已经核掉，本地却没有首次成功明细；或者平台明确拒绝的券被反复打，日志里全是同一类拒绝。一句话回答：美团核销失败先看顶层success，再看稳定的errorCode，不要只凭 HTTP 状态或数字code做分支。只有CONSUME_IN_PROGRESS、RESULT_UNKNOWN、SERVICE_UNAVAILABLE、PROVIDER_UNAVAILABLE，或请求超时没拿到响应时，才用原请求原参数有间隔、有上限地重试；PLATFORM_REJECTED、ALREADY_CONSUMED（10500）等明确失败要停止自动重试。抖音次卡结果未知时不自动重试。依据无限聚核公开 FAQ 与 API 文档口径整理，查阅日期 2026-10-18，以当前公开文档与平台后台为准。成功只认success=true。HTTP 200、code=10000都不能单独当成功；重试看errorCode白名单。白名单外一律停；超时没响应也按「可重试用原请求」处理；已核销 10500 是核对，不是成功。保存wxdgOrderNo，不要补发权益、不要编造撤销凭证；预核销成功 ≠ 已核销。校验只读，权益只能在真实核销成功后发；业务拒绝对照平台提示。券不存在、已使用、门店不适用等以平台与聚合返回文案为准，不要写死未公开数字码当分支条件。示意图：排查链路按无限聚核公开 FAQ／API 口径整理（2026-10-18），非某家后台截图。一、排查链路总览：先 success，再 errorCode建议把「一次核销调用」的结果处理固定成四步，后端和前端共用同一套状态机：有没有拿到完整响应？连接中断、读超时、没 body，一律先记「结果未知」，保留原请求五元组（shopId、platform、code、num、ticketInfo），页面显示「正在确认，请勿重复提交」，不要立刻报失败、不要引导顾客重输码。顶层success是否为布尔值true？是则进入成功分支：保存首次完整响应、wxdgOrderNo、按data[i]与consumeCredential[i]下标对应存明细与撤销凭证，再处理自己的预约／会员／出菜。success=false时读errorCode。用字符串枚举分支，不要用code数字猜：结果未知、参数错误、门店未授权、次数不足等，公开口径里可能共用同一类数字码（常见举例是10001），「见 10001 就重试」会把明确拒绝也重试进去。落到三类动作：可重试（原样重发）、停止并展示原因、已核销转核对。任何一类都先落库，再决定 UI。对照表（聚合侧稳定字段；平台内部业务码以官方后台为准）：类别典型信号后端动作不要做什么明确成功success=true保存首次成功全量，再发权益不要只看 HTTP／code可重试白名单errorCode或超时无响应原请求有限重试；未确定前不入账不要重新预核销、换券码／门店／数量业务／平台拒绝PLATFORM_REJECTED等停重试，展示返回原因不要自动换平台再试已核销提示ALREADY_CONSUMED，code=10500停重试，用wxdgOrderNo核对不要当成功、不要补发、不要编造凭证配置类授权／门店／额度等停重试，修配置后再人工发起不要用同一错误请求死循环二、预核销成功 ≠ 已核销：失败排查常从这里偏航很多「核销失败」工单，根因其实是把两阶段混成一阶段：输码验券校验（预核销）是只读确认：检查券是否可用、拿回不透明的ticketInfo、展示套餐名与售价。它不改变券状态，也不能发权益。验券／核销才是写操作：必须原样回传预核销保存的ticketInfo，以及同一组shopId、platform、code、num。成功依据仍是顶层success=true。排查时先问三句：这次失败发生在校验接口还是核销接口？（路径、请求体、是否带ticketInfo）若校验已成功，本地是否把ticketInfo当不透明字符串整段保存，而不是解析重组？页面是否在校验成功后就提示「已核销」？（这是产品文案问题，会导致顾客投诉「核了但没权益」）超时或结果未知时，不要为了重试再跑一遍预核销，也不要让顾客重新输码：券若已在平台侧核掉，重新预核销会变成平台拒绝，日志更难对上。三、常见业务拒绝：对照官方业务码思路，以返回为准聚合侧常见会把平台明确拒绝收成PLATFORM_REJECTED（公开口径举例：外层code可能是10000，或10000加平台业务码，如美团侧业务码1006映射成11006一类写法）。具体数字以你账号当前返回与平台后台为准，本文不把未公开码表写成硬编码分支。现场高频现象（作「常见现象举例」，处理以平台与聚合返回文案为准）：现象举例店员／开发侧先查什么系统侧建议券不存在／券码无效是否扫成网址、空格未去、手输漏位；平台是否选错停自动重试；提示核对券码与平台券已使用／已核销是否他店／他系统已核；是否本系统上次超时其实已成功查本地是否有成功或待确认；必要时按平台「已验券／券状态」核对门店不适用／未授权本店聚核shopId是否对应正确门店（不是商户 ID）；该店美团／抖音授权是否有效停重试；修门店映射与授权后再人工发起已过期／未到可用时间券详情页可用时段；门店营业规则停重试；展示平台原因次数不足／额度类控制台剩余次数、账号配额停重试；处理额度后再发起（勿把额度错误当可重试网络错误）原则：拒绝类错误展示原因即可，不要自动换平台轮询试。轮流试美团再试抖音，只会把错误提示打乱，也增加无效调用。四、可重试集合：白名单 + 原请求 + 次卡例外按无限聚核公开 API／FAQ 口径，只有下列情况才允许业务后端自动重试：errorCode为CONSUME_IN_PROGRESSerrorCode为RESULT_UNKNOWNerrorCode为SERVICE_UNAVAILABLEerrorCode为PROVIDER_UNAVAILABLE或请求超时／连接中断，根本没拿到可用响应重试规则必须同时满足：原样五参数：shopId、platform、code、num、ticketInfo与首次核销请求逐字一致；有间隔、有上限：上限与退避是你业务侧配置，不是「无限打」；超限仍未知则转待核对／查券状态／对账；页面态：未确定前不报成功也不报最终失败，避免顾客被引导重输码；抖音次卡例外：结果未知时不自动重试，先查平台券状态或完成对账（由预核销保存的ticketData判断是否次卡，例如公开示例里看certificates[].time_card是否有值）。伪代码意图（字段名以当前公开文档为准）：RETRYABLE = { CONSUME_IN_PROGRESS, RESULT_UNKNOWN, SERVICE_UNAVAILABLE, PROVIDER_UNAVAILABLE } 若 超时无响应 或 errorCode ∈ RETRYABLE: 若 抖音次卡 → 标记待核对（不自动重试） 否则 → 用首次请求 JSON 原样有限重试 否则若 errorCode == ALREADY_CONSUMED: 停止；保存 wxdgOrderNo；转核对 否则: 停止；展示原因；不自动重试接口侧幂等的含义是：同一业务请求不会被重复核销成多笔。它不等于「每次重复调用都返回同一份首次成功明细」。因此业务系统仍要按券码 + 自身业务订单去重，并保存首次完整成功记录；公开 FAQ 也写明聚合核销调用方无需传idempotencyKey（旧客户端传入也会被忽略），去重责任在业务侧。五、ALREADY_CONSUMED（10500）：停重试，用 wxdgOrderNo 核对命中已成功核销时，当前公开口径的典型形态是：success=falsecode=10500errorCode=ALREADY_CONSUMEDwxdgOrderNo为原核销单号data为空／null，consumeCredential为空数组message里可能带核销时间与门店信息（展示前注意脱敏）正确处理：立刻停止该次自动核销重试；保存wxdgOrderNo、message、完整响应与原请求；用wxdgOrderNo和平台侧「已验券信息／券状态」核对：是否本门店、是否本笔业务订单、本地是否已有首次成功记录；若本地已有成功记录：复用本地权益状态，不要再发一遍；若本地没有首次成功：标记待核对；确认前不要仅凭 10500 补发权益，也不要编造consumeCredential（没有首次成功响应就没有合法撤销凭证）。这类工单最常见的场景，是「第一次其实已经成功，但客户端超时只看到失败／未知，又点了一次」。10500 是在告诉你「别再核了，去对原单」，不是「再试一次就能拿到成功报文」。六、自检清单（联调／线上各走一遍）检查项预期成功判断仅success=true进入成功；HTTP／code不作唯一条件首次成功落库完整响应、wxdgOrderNo、明细与凭证按下标保存后再发权益预核销与核销校验成功只进确认页；权益只在核销成功后发ticketInfo不透明整段回传，不解析重组可重试白名单仅四类errorCode+ 超时；原请求原参数；有上限抖音次卡结果未知不自动重试PLATFORM_REJECTED停重试，展示平台／聚合原因ALREADY_CONSUMED／10500停重试；按wxdgOrderNo核对；不补发、不编造凭证顾客侧文案结果未知显示「正在确认，请勿重复提交」，不引导重输码业务去重按券码 + 本地订单去重；不依赖调方传idempotencyKey配置类错误授权、门店、额度等问题先修环境，再人工发起七、小结美团核销失败怎么查：把「网络结果」和「业务结果」拆开——先确认有没有完整响应，再用success判定成败，用errorCode白名单决定能不能重试。可重试就原样重发；拒绝就停；10500 就核对。预核销成功不要当已核销，次卡结果未知不要自动重试。按这套决策树落地，日志里的「失败」才能变成可解释的状态，而不是一串盲目重试。
核销服务由无限聚核提供，美团、抖音团购核销一站式接入。联调美团、抖音团购核销时，最容易踩的坑不是「接口调不通」，而是失败后乱重试：页面已经提示失败，店员又让顾客重新输码；超时后换参数再打一枪；看到code=10001就一律重试。结果往往是：券其实已经核掉，本地却没有首次成功明细；或者平台明确拒绝的券被反复打，日志里全是同一类拒绝。一句话回答：美团核销失败先看顶层success，再看稳定的errorCode，不要只凭 HTTP 状态或数字code做分支。只有CONSUME_IN_PROGRESS、RESULT_UNKNOWN、SERVICE_UNAVAILABLE、PROVIDER_UNAVAILABLE，或请求超时没拿到响应时，才用原请求原参数有间隔、有上限地重试；PLATFORM_REJECTED、ALREADY_CONSUMED（10500）等明确失败要停止自动重试。抖音次卡结果未知时不自动重试。依据无限聚核公开 FAQ 与 API 文档口径整理，查阅日期 2026-10-18，以当前公开文档与平台后台为准。成功只认success=true。HTTP 200、code=10000都不能单独当成功；重试看errorCode白名单。白名单外一律停；超时没响应也按「可重试用原请求」处理；已核销 10500 是核对，不是成功。保存wxdgOrderNo，不要补发权益、不要编造撤销凭证；预核销成功 ≠ 已核销。校验只读，权益只能在真实核销成功后发；业务拒绝对照平台提示。券不存在、已使用、门店不适用等以平台与聚合返回文案为准，不要写死未公开数字码当分支条件。示意图：排查链路按无限聚核公开 FAQ／API 口径整理（2026-10-18），非某家后台截图。一、排查链路总览：先 success，再 errorCode建议把「一次核销调用」的结果处理固定成四步，后端和前端共用同一套状态机：有没有拿到完整响应？连接中断、读超时、没 body，一律先记「结果未知」，保留原请求五元组（shopId、platform、code、num、ticketInfo），页面显示「正在确认，请勿重复提交」，不要立刻报失败、不要引导顾客重输码。顶层success是否为布尔值true？是则进入成功分支：保存首次完整响应、wxdgOrderNo、按data[i]与consumeCredential[i]下标对应存明细与撤销凭证，再处理自己的预约／会员／出菜。success=false时读errorCode。用字符串枚举分支，不要用code数字猜：结果未知、参数错误、门店未授权、次数不足等，公开口径里可能共用同一类数字码（常见举例是10001），「见 10001 就重试」会把明确拒绝也重试进去。落到三类动作：可重试（原样重发）、停止并展示原因、已核销转核对。任何一类都先落库，再决定 UI。对照表（聚合侧稳定字段；平台内部业务码以官方后台为准）：类别典型信号后端动作不要做什么明确成功success=true保存首次成功全量，再发权益不要只看 HTTP／code可重试白名单errorCode或超时无响应原请求有限重试；未确定前不入账不要重新预核销、换券码／门店／数量业务／平台拒绝PLATFORM_REJECTED等停重试，展示返回原因不要自动换平台再试已核销提示ALREADY_CONSUMED，code=10500停重试，用wxdgOrderNo核对不要当成功、不要补发、不要编造凭证配置类授权／门店／额度等停重试，修配置后再人工发起不要用同一错误请求死循环二、预核销成功 ≠ 已核销：失败排查常从这里偏航很多「核销失败」工单，根因其实是把两阶段混成一阶段：输码验券校验（预核销）是只读确认：检查券是否可用、拿回不透明的ticketInfo、展示套餐名与售价。它不改变券状态，也不能发权益。验券／核销才是写操作：必须原样回传预核销保存的ticketInfo，以及同一组shopId、platform、code、num。成功依据仍是顶层success=true。排查时先问三句：这次失败发生在校验接口还是核销接口？（路径、请求体、是否带ticketInfo）若校验已成功，本地是否把ticketInfo当不透明字符串整段保存，而不是解析重组？页面是否在校验成功后就提示「已核销」？（这是产品文案问题，会导致顾客投诉「核了但没权益」）超时或结果未知时，不要为了重试再跑一遍预核销，也不要让顾客重新输码：券若已在平台侧核掉，重新预核销会变成平台拒绝，日志更难对上。三、常见业务拒绝：对照官方业务码思路，以返回为准聚合侧常见会把平台明确拒绝收成PLATFORM_REJECTED（公开口径举例：外层code可能是10000，或10000加平台业务码，如美团侧业务码1006映射成11006一类写法）。具体数字以你账号当前返回与平台后台为准，本文不把未公开码表写成硬编码分支。现场高频现象（作「常见现象举例」，处理以平台与聚合返回文案为准）：现象举例店员／开发侧先查什么系统侧建议券不存在／券码无效是否扫成网址、空格未去、手输漏位；平台是否选错停自动重试；提示核对券码与平台券已使用／已核销是否他店／他系统已核；是否本系统上次超时其实已成功查本地是否有成功或待确认；必要时按平台「已验券／券状态」核对门店不适用／未授权本店聚核shopId是否对应正确门店（不是商户 ID）；该店美团／抖音授权是否有效停重试；修门店映射与授权后再人工发起已过期／未到可用时间券详情页可用时段；门店营业规则停重试；展示平台原因次数不足／额度类控制台剩余次数、账号配额停重试；处理额度后再发起（勿把额度错误当可重试网络错误）原则：拒绝类错误展示原因即可，不要自动换平台轮询试。轮流试美团再试抖音，只会把错误提示打乱，也增加无效调用。四、可重试集合：白名单 + 原请求 + 次卡例外按无限聚核公开 API／FAQ 口径，只有下列情况才允许业务后端自动重试：errorCode为CONSUME_IN_PROGRESSerrorCode为RESULT_UNKNOWNerrorCode为SERVICE_UNAVAILABLEerrorCode为PROVIDER_UNAVAILABLE或请求超时／连接中断，根本没拿到可用响应重试规则必须同时满足：原样五参数：shopId、platform、code、num、ticketInfo与首次核销请求逐字一致；有间隔、有上限：上限与退避是你业务侧配置，不是「无限打」；超限仍未知则转待核对／查券状态／对账；页面态：未确定前不报成功也不报最终失败，避免顾客被引导重输码；抖音次卡例外：结果未知时不自动重试，先查平台券状态或完成对账（由预核销保存的ticketData判断是否次卡，例如公开示例里看certificates[].time_card是否有值）。伪代码意图（字段名以当前公开文档为准）：RETRYABLE = { CONSUME_IN_PROGRESS, RESULT_UNKNOWN, SERVICE_UNAVAILABLE, PROVIDER_UNAVAILABLE } 若 超时无响应 或 errorCode ∈ RETRYABLE: 若 抖音次卡 → 标记待核对（不自动重试） 否则 → 用首次请求 JSON 原样有限重试 否则若 errorCode == ALREADY_CONSUMED: 停止；保存 wxdgOrderNo；转核对 否则: 停止；展示原因；不自动重试接口侧幂等的含义是：同一业务请求不会被重复核销成多笔。它不等于「每次重复调用都返回同一份首次成功明细」。因此业务系统仍要按券码 + 自身业务订单去重，并保存首次完整成功记录；公开 FAQ 也写明聚合核销调用方无需传idempotencyKey（旧客户端传入也会被忽略），去重责任在业务侧。五、ALREADY_CONSUMED（10500）：停重试，用 wxdgOrderNo 核对命中已成功核销时，当前公开口径的典型形态是：success=falsecode=10500errorCode=ALREADY_CONSUMEDwxdgOrderNo为原核销单号data为空／null，consumeCredential为空数组message里可能带核销时间与门店信息（展示前注意脱敏）正确处理：立刻停止该次自动核销重试；保存wxdgOrderNo、message、完整响应与原请求；用wxdgOrderNo和平台侧「已验券信息／券状态」核对：是否本门店、是否本笔业务订单、本地是否已有首次成功记录；若本地已有成功记录：复用本地权益状态，不要再发一遍；若本地没有首次成功：标记待核对；确认前不要仅凭 10500 补发权益，也不要编造consumeCredential（没有首次成功响应就没有合法撤销凭证）。这类工单最常见的场景，是「第一次其实已经成功，但客户端超时只看到失败／未知，又点了一次」。10500 是在告诉你「别再核了，去对原单」，不是「再试一次就能拿到成功报文」。六、自检清单（联调／线上各走一遍）检查项预期成功判断仅success=true进入成功；HTTP／code不作唯一条件首次成功落库完整响应、wxdgOrderNo、明细与凭证按下标保存后再发权益预核销与核销校验成功只进确认页；权益只在核销成功后发ticketInfo不透明整段回传，不解析重组可重试白名单仅四类errorCode+ 超时；原请求原参数；有上限抖音次卡结果未知不自动重试PLATFORM_REJECTED停重试，展示平台／聚合原因ALREADY_CONSUMED／10500停重试；按wxdgOrderNo核对；不补发、不编造凭证顾客侧文案结果未知显示「正在确认，请勿重复提交」，不引导重输码业务去重按券码 + 本地订单去重；不依赖调方传idempotencyKey配置类错误授权、门店、额度等问题先修环境，再人工发起七、小结美团核销失败怎么查：把「网络结果」和「业务结果」拆开——先确认有没有完整响应，再用success判定成败，用errorCode白名单决定能不能重试。可重试就原样重发；拒绝就停；10500 就核对。预核销成功不要当已核销，次卡结果未知不要自动重试。按这套决策树落地，日志里的「失败」才能变成可解释的状态，而不是一串盲目重试。