自动发卡平台客诉增多，卡密回传缺失如何排查

当自动发卡平台出现集中的未收到卡密客诉，先查货源是常见做法，真正需要优先核对的却是卡密回传链路。尤其在卡易速这类同时支持 Webhook 回调与查询接口的平台，回传一旦中断，订单仍可正常支付，用户侧却拿不到凭证，后续售后成本会持续增加。本文只解决一个问题：卡密回传缺失时，怎样按优先级定位原因，并用可执行的步骤完成处理。

先核对回传日志，判断卡密消息是否生成

排查不能凭订单已支付或已发货判断，必须调取平台侧回传日志，确认卡密消息有没有发出。卡易速的 Webhook 默认启用，订单创建后，卡密、退款、商品变化等消息会在生成时选择回调地址，同一条消息只选一个地址；若默认地址与订单自定义地址都不存在，该条 Webhook 不会发送，订单仍正常创建。因此，要先确认卡密消息是否生成、目标地址是什么、接收响应是什么，据此区分是配置问题还是接收问题，避免在无依据的情况下反复改货源或退款。

区分默认地址与订单级地址，排除配置覆盖问题

回传地址有两层来源，容易被忽略。一是商户前台账户管理下接口管理中保存的默认回调地址，二是创建订单时填写的订单级回调地址，后者优先级更高。排查时要把客诉订单逐一核对：该订单是否单独填写地址，默认地址是否在消息生成前已经保存。很多人只在后台配置过一次默认地址，之后修改默认地址不会改变已经生成的消息；若客诉订单恰好生成于地址缺失或无效的时段，就会出现整段缺失。核对结果应落到三类：地址正确但未收到、地址为空导致未发送、地址填错导致响应异常，前两类可直接进入接收端排查。

检查接收端响应与保存逻辑，排除本地处理中断

当平台日志显示消息已发出且地址正确，就要转向接收端逐项核对。按卡易速的回传规则，第三方收到消息后应先检查 JSON 格式与必填字段，保存 eventId 用于去重，卡密必须先安全保存再交给后续发货，数据保存成功后返回 HTTP 200，响应正文为纯文本 OK。排查时优先确认：接收接口是否返回 200 与 OK、卡密是否完整保存、保存后是否写入发货队列。常见错误是接收接口只做日志记录却未持久化卡密，或把卡密交给前端展示却不落库，导致后续补发时找不到原始数据。若响应异常，应先修复接收端再重发，不能在卡密未保存的情况下重复触发发货。

处理后用查询接口验证，避免二次客诉

修复后不能只凭主观判断，需要用平台接口完成一次完整验证。对于单笔客诉订单，应调用订单详情接口核对卡密状态；卡易速中订单详情接口属于基础兜底接口，可直接获取订单当前结果，比依赖 Webhook 更可靠。验证动作包括三步：先查订单详情确认卡密是否生成，再用一笔小额测试订单走完整回传链路，最后核对用户端是否实际收到。若测试订单同样失败，说明接收端逻辑仍有问题，需回到上一步继续修复；若测试成功，再对历史缺失订单按原单逐个补发，补发时仍遵循 eventId 去重，同一 eventId 再次收到时不要重复发卡。

回传问题的最终取舍，取决于订单量与售后成本。单量小、缺失偶发时，以订单详情接口做兜底查询，客诉出现时按原单核对再补发，成本最低；单量大、缺失集中在特定时段时，则要补齐默认回调地址、规范接收端保存逻辑，并在上线前用测试订单验证，把链路稳定性前置到配置阶段，才能减少反复补发带来的人力消耗。

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