先把“失败”拆成三种状态
一线最容易把接口超时、平台明确拒绝和票已核销混成一种“失败”。正确做法是至少区分：请求未送达或结果未知、平台返回可重试的系统错误、平台返回不可重试的业务错误。抖音开放平台的景区核销说明明确要求服务商在接口失败时控制重试，并提示存在兜底逻辑；日历票多门店核销还需要回传核销门店 POI。
推荐的核销处理链路
- 读取本地状态：先判断该凭证是否已在本景区、本门店、本票项完成核销。
- 生成幂等键：由渠道订单、凭证、票项、核销门店和业务动作组成，避免重复点击产生多次履约。
- 调用平台：保存请求时间、接口版本、业务参数摘要、返回码和追踪号；敏感字段不得明文落日志。
- 有限重试：仅对超时、网络或平台声明的可重试错误执行指数退避；不可重试错误直接转业务处理。
- 结果未知：不要立即放行后再次扣减。应查询渠道状态或进入人工核验，形成可追踪临时凭证。
- 异步补偿：游客入园后的平台状态补写必须可重放、可告警，并能识别已经成功的请求。
日终对账要比三本账
| 账本 | 关键字段 | 常见差异 |
|---|---|---|
| 渠道账 | 订单、凭证、核销状态、退款状态、结算状态 | 平台已核销，本地仍未知 |
| 票务账 | 票码、票项、门店、核销时间、操作终端 | 本地放行但渠道未确认 |
| 闸机账 | 设备、离线批次、识别结果、开闸结果 | 接口成功但设备未开闸 |
差异表应按“可自动修复、需渠道确认、需业务确认、需财务处理”分组，而不是把全部异常交给人工逐条猜测。每条差异都要保留原始订单号、业务键、最近状态、责任方和处理结论。
核销与退款必须互相约束
票已核销后是否允许退款、部分核销如何计算可退数量、渠道退款成功后票码如何失效，都应在商品规则和接口状态机中统一定义。系统不能只根据前端按钮判断，要以渠道规则、票项履约状态和授权审批共同决定。
运营边界：平台接口能力和规则会更新。具体字段、错误码、重试次数、提前核销及部分核销支持范围，以接入时的抖音开放平台文档和双方协议为准。
上线后至少观察五个指标
核销成功率、结果未知率、平均重试次数、人工兜底率和跨账本未结差异数，应按景区、门店、设备、接口版本和时间段拆分。只有总成功率，无法定位是网络、商品配置、门店 POI、设备还是渠道波动。