自动发货误判卡密已交付，该怎么排查

做自动发货生意时，不少经营者会把接口返回成功、页面显示已完成直接等同于卡密已交付，遇到用户反馈未收到就急于补发，要么引发重复发卡，要么掩盖了真正的配置问题。这个问题的核心不是补单操作，而是建立一套不依赖主观判断的卡密交付核对方法。下面只解决一个具体问题：判断自动发货中卡密交付状态是否真实有效，并给出可执行的排查步骤。

先排除把订单状态当成卡密状态的误区

自动发货的订单状态和卡密交付状态是两个独立环节，订单成功创建只代表交易流程走通，不代表卡密已同步到发货链路。比如平台完成支付、订单状态变为已完成，但卡密仓库尚未关联、发货规则未生效，系统依然不会自动发卡。判断交付是否完成，必须先把订单状态与卡密状态拆开核对，不能用订单状态替代卡密状态，否则很容易出现“订单已完成，卡密却没发出去”的情况。

实际操作中，要先查询原订单详情，确认订单的实际状态，再进入卡密仓库核对对应卡密的库存变化与领取记录。如果卡密库存没有减少，也没有对应的领取记录，即使订单状态显示已完成，也说明卡密并未实际交付，不能直接判定交付成功，更不能在未核对的情况下直接补发。

从发货配置链路逐项核对，不凭页面判断

卡密未交付的问题，往往出在发货配置的某个环节，而不是单纯的库存问题。常见的误区是只看货源库存总量，忽略货源类型、绑定关系与启用状态。根据官方说明，卡密、卡号加卡密、固定卡密与充值货源用途不同，不能只增加总库存便认为绑定完成。排查时要先确认货源类型是否与售卖商品匹配，再核对货源是否处于启用状态，最后检查是否绑定到了正确的商品或规格，缺一不可。

对于多货源场景，也不能简单认为系统会自动选择最低价货源。低价优先、自营优先和顺序轮询各有分配规则，成本来源与实际履约策略分别配置，排查时必须核对当前绑定和策略，不能以货源列表的排序推断每一单必走某一渠道，否则会误以为货源充足，实际交付链路并未打通。

处理异常订单时，先确认明确失败再补单

当卡密交付出现异常，最危险的做法是跳过核对直接补单。根据官方要求，失败后不能直接补单，必须先查看原订单日志及渠道结果，确认明确失败或已撤销且未交付，再使用允许的补单流程。如果渠道返回的结果不确定，要先人工核查，避免卡密重复发放或充值重复到账。

例如某个订单发货失败，系统既没有返回明确的错误码，也没有给出卡密，这时不能直接重新发卡，要先核对渠道订单与本站订单的对应关系，检查双方既有交付和返回结果，确认确实未交付后再做补单处理。授权过期时要先恢复接入，不能通过重复绑定或重复发货掩盖原订单结果，否则后续核对和售后都会陷入混乱。

核对 Webhook 与查询结果，不依赖单次回调

自动发货依赖接口与 Webhook 协同，很多经营者会把收到一条 Webhook 就当成交付完成，实际上 Webhook 只是状态同步，最终要以查询接口返回的结果为准。Webhook 默认启用且没有额外签名，收到消息后要先检查 JSON 格式和必填字段，保存 eventId，同一个 eventId 再次收到时，不要重复发卡、记录退款或追加售后消息。

卡密消息必须先安全保存，再交给后续发货流程，需要确认商品或订单当前状态时，调用对应的查询接口，而不是只依赖回调消息。如果消息生成时没有配置回调地址，订单仍然正常创建，第三方需要使用查询接口获取当前结果，不能因为没有收到回调就判定交付失败，也不能因为收到一次回调就确认交付完成。

按核对结果决定是否补单，不做重复操作

完成前面的核对后，再根据不同情况做不同处理。如果订单状态正常、卡密库存已扣减、查询接口返回的卡密可正常核销，说明交付完成，可以引导用户重新查看或核对核销方式，无需补单。如果订单状态正常，但卡密未扣减、查询接口无卡密信息，说明发货链路存在配置问题，先修正货源绑定或发货规则，再走补单流程。如果渠道返回明确失败且确认未交付，按平台允许的补单流程处理，不在未确认的情况下手动发卡。

需要注意，这套核对方法只适用于卡密类商品的交付状态判断，直充类商品需要核对渠道到账记录，不能套用同一套标准。如果同时涉及多种商品类型，需要分别建立对应的核对口径，避免用同一套判断标准处理所有订单，导致状态误判。

参考资料：接入指南（2026-09-20）；库存与发货异常（2026-10-18）；店铺与电商接入疑问（2026-10-18）。具体操作与适用范围以对应文档为准。