自动发货卡密回调没配好，持续出单也会中断

自动发货店铺能稳定出单，前提是货源充足、链路可响应。不少经营者只在铺货接线上花精力，一旦订单持续涌入，才发现卡密回调没生效，买家打不开收货页面、后台还在重复发卡。持续出单不只是流量问题，更依赖发货结果被完整回收与确认。下面把这套链路拆成三个必须落实的环节，每一项都有可执行的检查与验收。

先确认发货回调地址是否已配置且生效

回调地址是自动发货后结果回传的入口。若未配置或配置错误，卡密到货通知无法送达，店铺只能依赖手工查询，订单量一大就出现延迟。例如你用卡易速做货源对接，需要在商户后台的自动发货配置中填入准确的回调地址，并确认平台欢迎该请求。

配置完成后，验收动作是发一笔真实测试订单，观察后台是否收到对应订单推送。若未收到，先检索接口管理设置，确认地址是否被正确保存；再检查地址格式是否完整、是否漏掉协议头或端口。只要测试订单能在后台看到发货通知，回调配置才算生效，后续批量订单才有回收路径。

收到回调后必须按 EventID 去重

持续出单时，平台可能因网络或重试机制重复推送同一结果。若不识别 EventID，同一套卡密会被重复发放，造成库存被占与账号异常。处理方式是：每条消息先保存 eventId，再次收到相同 eventId 时跳过发货，直接返回成功状态。

去重验收可在后台审计日志中核对：同一订单只应出现一次成功发卡记录。若发现同单多次发卡，说明未做幂等控制或 eventId 记录失效。应立即修正代码逻辑，确保保存记录被持久化，不随内存清空或服务重启丢失。这一环节稳定后，发货流程才能承接持续订单。

结合主动查询兜底，锁住持续出单

回调虽有默认启用，但不保证每次必达。消息生成时若未配置地址，平台不会发送推送，但订单仍正常创建。此时需调用查询接口主动获取结果，例如使用 GET /orders/{clientOrderRef} 拉取订单详情，再从返回字段中确认卡密是否已生成并填充。

持续出单的验收标准，是在订单成交后一定时间内，后台与订单状态一致：前台显示已完成，卡密字段非空，且无重复发卡记录。若出现不一致，先按原单核对状态，不急着重发；只有确认卡密缺失时再发起一次补发，并记录本次处理时间。通过查询兜底，回调配置的漏洞被补上，发货链路才算真正闭环。

自动发货店铺的持续出单，由货源、回调与去重三者共同维持。把地址配准、事件去重与查询兜底串起来，订单再多也不会在发货环节失守。

卡密回调链路稳定后，持续出单还要关注不同场景下的判断边界，把这些边界明确后，后续订单处理才会有清晰依据。

第一个边界是订单类型，游客与会员订单的处理方式不同。游客下单时，平台和店铺无法提前获取买家账户信息，更依赖短信或页面提示完成发货；会员订单则有明确账户绑定关系，回调中可直接关联对应卡密。例如当同一商品在两种购买方式下都能稳定交付，说明货源与回调规则覆盖完整，可承接持续订单；若只有会员订单正常，游客订单延迟或缺失，则需要先确认游客通知通道是否配置到位，再扩大流量投放。

第二个边界是商品订阅状态。订单在成功后平台会自动订阅或续期对应商品，但本地库存与订阅状态可能短时间不一致。处理时先查询当前商品订阅，再核对本轮订单对应的卡密是否已转入发货池，避免凭感觉判断货源充足。

第三个边界是售后与退款触发。持续出单意味着售后也会同步出现，每一笔退款都会一并推送 order.changed，需要在收到消息后立即锁定该单，停止后续重复发卡。验收时，核对该单在订单列表中状态是否变为退款中或已退款，同时检查库存是否回补，确保下一笔订单不会拿到已被核销的卡密。

参考资料：接入指南（2026-09-20）。具体操作与适用范围以对应文档为准。