自动发卡场景下，卡密泄露如何按环节排查

自动发卡流程跑通后，后台日志突然出现同一批卡密被多次调取，或是用户刚收到卡密就提示已被核销，说明卡密在交付前或交付中已经泄露。泄露原因不唯一，排查要从存储、传输、日志三个环节入手，不能只查发货接口。

从泄露结果倒推可能环节

先确认泄露的是已完成订单还是未支付订单的卡密，这一步决定排查方向。已完成订单泄露，重点看交付与日志环节；未支付订单泄露，重点看库存与存储环节，两者排查路径完全不同，不能混在一起。

例如，某批次未支付订单对应的卡密在支付前就出现在第三方渠道，说明问题出在存储或同步环节，而不是发货链路。这类情况通常伴随导入操作或同步任务，需要优先核对导入格式和有效可售数量，再确认货源类型、启用状态及是否绑定到正确商品或规格，不能只增加总库存便认为绑定完成。

存储环节的排查与验证

存储环节的排查以权限和写入路径为核心。检查导入任务是否使用了具备读取权限的账号，该账号是否同时关联了外部同步或导出任务。核对导入来源是否为可信货源，避免从来源不明的文件直接导入，因为不明来源文件本身可能携带已泄露的卡密。

验证方法是在导入前后对比同一批卡密的状态，确认导入过程中没有产生额外的读取记录。如果导入工具或插件具有远程同步功能，检查其访问地址是否仅允许内网访问，避免将含有卡密的存储地址暴露在公网。

涉及卡密用途时，要区分商品卡密、充值兑换码和余额加款卡，三者入口不同，不能只看卡密两个字判断用途。不同用途的卡密对应不同的核销页面，核对时要按商品说明指向的对应平台，不能把充值兑换码填进余额加款卡框，也不能将卡密发到无关的会话中。

传输环节的排查与验证

传输环节重点关注回调地址和响应逻辑。Webhook 默认启用，第三方可在商户前台个人中心账户管理与接口管理中保存默认回调地址，也可在创建订单时填写该订单自己的回调地址。订单填写后，订单、卡密、退款、对应商品变化及关联售后消息优先发送到该固定地址；未填写时，每条消息生成时读取当时的默认回调地址。

排查时确认订单是否填写了订单级回调地址，填写的地址是否为当前实际接收地址，避免地址被覆盖后卡密仍发往旧地址。同一条消息只选择一个地址并固定下来，之后修改默认地址不会改变已生成的消息，消息生成时两个地址都没有就不发送该条 Webhook，订单仍正常创建。

收到卡密消息后，先检查 JSON 格式和必填字段，保存事件编号，同一个事件编号再次收到时不要重复发卡。卡密消息必须先安全保存，再交给后续发货流程，保存成功后返回 HTTP 200，响应正文使用纯文本 OK。未收到 OK 时，平台会使用同一个事件编号重试，必须先保存卡密和事件编号再返回 OK，避免重复发卡。

日志与售后环节的排查

日志环节主要核对访问记录和工单凭证。查询含有卡密字段的访问日志，按时间排序，查看是否存在非发货流程的读取动作，重点关注导出、详情查询和售后查询操作。日志中出现未在发货流程中的完整卡密，说明泄露来自内部查询或日志记录未做脱敏。

售后工单环节核对凭证时，注意不在公开会话发送完整卡密，已使用、过期或无效时保留提示交给发卡商家核对。兑换过的结果可在原兑换或查询结果入口使用原兑换码查询对应结果，批次链接优先沿用原地址，结果不明确时不换账号重新兑换，避免卡密在多个账号间流转造成二次扩散。

处理后的验证与取舍

完成排查后，用新订单做一次端到端验证：确认卡密在发货前不存在额外读取记录，回调地址为当前有效地址，返回 OK 后不再收到同一事件编号的重复消息。若三次发送都失败，使用订单查询接口获取卡密，查询后再核对该订单的卡密是否被其他流程调取过。

不同环节的排查代价不同。存储环节需要限制账号权限，传输环节需要规范回调地址和响应逻辑，日志环节需要控制访问范围。当资源有限时，优先处理泄露路径最明确、可立即阻断的环节，再逐步完善其他环节，避免因追求全面排查而延误止损时机。

参考资料：接入指南（2026-09-20）；库存与发货异常（2026-10-18）；卡密用途如何区分（2026-10-18）；卡密就绪推送（2026-08-22）。具体操作与适用范围以对应文档为准。