自动发货总怕漏发：先查触发条件再查数据链路

很多人以为自动发货只要店铺对接了货源就会顺理成章发出卡密，却忽略了触发条件改动、回调地址失效等环节同样会导致漏发。排查这类问题时，必须按从触发到落库的顺序逐层核对，不能只凭订单页面状态猜测原因。

先确认订单是否触碰了自动发货规则

自动发货并非对所有支付状态开放，必须先看待发货订单是否满足已设置的触发条件。需要打开商品配置页，核对当前生效的发放规则是否包含该类支付方式，以及是否存在限制条件导致流程中止。例如，如果规则限定“已支付且未退款”才触发，那么停留在“待处理”状态的订单就不会进入发货队列，这类订单需要先核对支付渠道的到账状态，再判断是否需要人工介入。

同时还要检查商品是否处于有效上架状态。如果商品在后台显示停用或被关联了已失效的货源，即使买家完成支付，也不会产生发货动作。这一步检查能先排除规则层面的漏发，避免盲目排查数据链路。

再确认货源返回的卡密是否成功落库

假设触发条件没有问题，就需要核对货源返回的数据是否被正常接收和保存。这里要做的是：查看订单记录中是否包含上游返回的卡密字段，如果该字段为空，说明货源在调用时未返回数据，或请求参数存在缺失。例如，如果商品模板要求传入渠道商品标识，但实际请求中未填写，就会导致货源返回空数据，进而无法生成卡密。

如果卡密字段完整，还要确认卡密是否已写入发货记录。有些情况下，货源返回了卡密，但后续的落库步骤因系统错误被跳过，这就属于本地数据丢失，需要排查落库接口或数据库写入环节，而不是继续从货源侧找原因。

检查消息推送与兜底通道是否可用

卡密生成后通常依赖消息推送传递给买家，如果推送通道配置有误，即使卡密已生成，买家也无法及时收到。这一步要核对两件事：一是消息生成时是否选择了有效的回调地址，二是相关通知渠道是否稳定。

作为参考，部分发货系统的 Webhook 在订单创建时若未填写专门地址，会读取后台默认回调地址；同一条消息生成后地址即固定，之后修改默认地址不会改变已生成的消息。如果默认地址失效或被停用，就会导致消息未能送达。此时需要先确认后台配置的默认地址是否可用，再检查具体订单是否填写了独立回调地址，并核对该地址当前是否能够正常接收请求。

如果以上检查均正常，就要启用兜底通道。例如，在主推送失败后，可用短信或站内信向买家发送包含卡密的消息，同时在后台设置自动重试机制，避免因单次推送失败造成漏发。

用模拟订单走完整的验收流程

只是逐项检查设置还不够，需要用一笔模拟订单走完从支付到发货的全流程，这是确认漏发原因是否被排除的最后手段。模拟订单要覆盖以下步骤：提交支付后观察订单状态是否变为已支付、是否触发了发货规则、货源是否返回了卡密、卡密是否成功写入发货记录、买家端是否收到卡密消息。

每一步都要记录实际结果，并与预期流程逐点对照。只要有一个环节未达到预期，就可以直接定位到对应问题模块，再针对性修复。通过这套流程，才能把漏发问题从模糊的不确定中拉回到可验证、可修复的范围，让自动发货真正稳定运行。

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