自动发卡不到账怎么排查消息漏发

买家付款后始终没收到卡密，后台也看不到发货记录，问题不一定出在缺货或系统故障。自动发卡的稳定性，首先取决于消息能不能准确到达并被正确处理。排查不到账，要先从订单当前状态开始，判断究竟是确实未发货，还是消息已经发出但没有落地。

先确认订单状态和交付条件

第一优先级是打开平台订单列表，核对该笔订单的当前状态。虚拟商品正常发卡后状态应为 success，若仍停留在 pending 或 processing，说明发卡流程尚未完成，这时不论买家是否收到卡密，都要先解决发货环节，而不是先排查通知。同时确认商品和规格是否存在使用限制，尤其当商品处于暂停、销售或禁售状态时，系统可能按规则暂缓发货。

例如，同一件卡密商品在变更订阅关系后未同步接口，导致后续创建的订单无法正常触发发卡，此时订单状态会长时间停留。订单处于这种状态时，优先通过接口核查商品当前可用状态。如果商品已被下游订阅或存在绑定冲突，发货链路会被阻塞，后续所有卡密消息都会延后。

排查 Webhook 地址是否生效

订单发货后，平台会通过 Webhook 将卡密信息推送给接收方。一旦订单未填写 orderCallbackUrl，平台会读取订单生成时的默认回调地址。如果默认地址已失效或配置错误，消息在生成阶段就无法投递。排查时要区分三种情况：订单是否配置了专门的回调地址、默认地址是否为历史遗留的无效链接、地址协议与格式是否正确。

需要特别注意的是，消息生成时若两个地址都为空，平台不会产生 Webhook，订单本身仍正常完成，但卡密不会主动推送。此时只能依靠查询接口主动拉取。如果此前的默认地址在系统迁移或后台调整后失效，且历史订单未配置独立地址，受影响的不止单笔订单。因此检查默认回调地址与单笔订单地址是否一致，是定位漏发的关键一步。

核对消息去重是否影响了交付

第三方接收到卡密消息后，需要保存 eventId 并执行去重判断。如果同一个 eventId 被误判为已处理，或者去重条件设置过宽，卡密消息就会被丢弃，买家看不到凭证，后台也查不到回执。排查时先在接收方日志中搜索该订单对应的 eventId，确认是否收到过消息、是否被去重拦截、是否在保存前已完成卡密写入。

例如，当网络抖动导致同一事件重复推送，接收端未按 eventId 去重而是按业务单号去重，就可能漏掉后续正常到达的卡密消息。这时需要在接收端增加校验：同一 eventId 重复收到直接丢弃；不同 eventId 但同一订单则按新消息处理。去重逻辑不能只看订单号，否则会把重复推送误判为重复发卡，导致该订单始终无法交付。

处理后的验证与修复动作

定位到具体原因后，逐层验证：对状态异常的订单，确认发卡完成后重新刷新订单状态，并与接口查询结果比对，确保数据一致。对地址或去重问题，先修复配置，再通过一次小额订单创建一笔测试交易，确认卡密能正常推送且接收端成功落库。若测试订单正常，再对受影响订单按原 clientOrderRef 触发补发，不重复创建新订单。

最后检查买家侧：确认卡密信息已推送到买家页面或通知渠道，并记录订单全流程，包括创建时间、发货时间、回调响应状态。下一轮排查时，可以先从订单状态入手，再检查地址配置，最后核对去重逻辑，逐步缩小范围并完成修复。

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