自动发卡平台怎样确认卡密消息不会重复发放

自动发卡平台保障卡密安全，最核心的环节并不是把接口藏起来，而是防止同一条卡密被重复发送，以及避免在传递过程中泄露。如果第三方在接收Webhook时缺少校验，即便平台本身没有重复发卡，下游依然会出现卡密被多次使用、用户重复到账的问题。以下只解决一件事：在接收和处理卡密回调时，怎么用可执行步骤确认不会重复发放。

先明确卡密安全的核心判断标准

判断卡密发送是否安全，不能只看“有没有收到消息”，而要同时满足三个条件。例如，某商户在群里说“今天卡密接口很稳”，却无法回答下面三个问题，就不能确认安全：同一条消息的标识是否唯一；同一订单会不会收到多条卡密；保存和下发环节是否只读原消息，不进行二次复制。下面三步就是围绕这三个条件展开。

检查Webhook回调的接收流程

第一步先核对回调地址。平台会优先发送订单填写的 orderCallbackUrl，如果该订单没有填写，则使用账户管理里保存的默认回调地址。要检查的内容有两项：该订单是否填了 orderCallbackUrl，以及该地址是否符合公网 HTTPS 要求。比如，某订单创建时填写了一个带查询参数的地址，后续所有订单、卡密、退款消息都会优先发到该地址，此时就要以该订单首次保存的地址为准，不能中途更换。

第二步检查消息内容。收到回调后先检查 JSON 格式和必填字段，再保存 eventId。Webhook 没有额外签名，因此不能依赖地址是否私密来判断消息来源，而要通过事件类型和字段来区分。卡密消息属于独立事件，必须确认消息里是否包含订单标识、卡密内容和交付状态，缺少其中任何一项都不能直接发卡。

按去重规则处理重复消息

第三步是最重要的校验。同一个 eventId 再次收到时，不要重复发卡，也不要重复记录退款或追加售后消息。操作上，接收程序要先用 eventId 查询本地记录，命中后直接返回 HTTP 200，响应正文使用纯文本 OK，不再进入发卡流程。例如，网络抖动导致平台重试同一条消息，只要 eventId 相同，就能确认是同一条消息，避免卡密被二次下发。

需要特别注意一种情况：订单创建接口在网络超时或没有收到明确结果时，会用原 clientOrderRef 和原下单内容重试，平台会返回第一次创建的原订单，不会再次扣款或重复下单。但这属于订单创建环节，卡密消息依然要单独按 eventId 去重，不能把订单去重当作卡密去重，否则同一条卡密仍可能在订单状态同步时被误发。

卡密保存与下发要分开验收

第四步验收存储动作。卡密消息必须先安全保存，再交给后续发货流程，保存和下发必须分离。验收时可以检查本地数据库或缓存里，同一订单下是否只存在一组有效卡密，且下发记录只有一条。如果保存阶段同时写了多条下发日志，说明程序没有按 eventId 拦截，需要回到第二步修正。

第五步验收内容安全。对外展示或发送给用户时，不能在公开会话发送完整卡密，也不能把卡密写进日志明文。例如，卡密出现复制多出的空格、被误删字符时，应保留原始记录并交给发卡方核对，而不是直接公开完整卡密。这一步没有具体的安全数值，但有一个可执行的验收点：所有发送路径都能追溯到同一条原始记录，且原始记录只有一份。

适用边界与后续动作

以上流程适用于通过Webhook接收订单和卡密消息的场景。如果订单创建时既没有 orderCallbackUrl，也没有账户默认回调地址，平台不会发送该条消息，此时只能通过 GET /orders/{clientOrderRef} 查询订单详情来获取卡密，这个场景不适用本文的去重流程。

下一步，你可以挑选最近三天里带卡密的订单，逐条核对 eventId、订单号和卡密数量，确认本地记录里每个订单只对应一组有效卡密，即可验证当前流程是否安全。

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