自动发卡怎样才能不重发不漏发

自动发卡看似省事，真正容易出问题的往往是交付环节：卡密刚发给买家又被重复推送，或者买家已付款却迟迟收不到卡密。要实现不重发、不漏发，关键在于把货源、订单状态和回调去重统一到一个可验收的标准上。下面按递进步骤说明如何完成整套配置与自检。

货源绑定和库存没对齐，自动发卡会先漏发吗？

会。自动发卡并不是把卡密存在后台就会自动派发，只有货源类型、启用状态与商品规格对应后，订单才能触发发货流程。例如，卡密、卡号加卡密、固定卡密与充值货源用途不同，导入卡密后还要确认实际可售数量是否有效，仅增加总库存并不等于完成绑定。因此，操作时先在货源管理里核对当前货源的启用状态，再回到商品详情确认该规格绑定的是哪一个货源；如果是多规格商品，还要逐一核对规格与货源的对应关系，避免某个规格无货源却仍在售卖。

验收时，可以选一个库存充足、规格明确的商品进行下单测试，下单后立即查看订单日志，确认货源已被选中且卡密进入待发状态；如果订单日志没有货源分配记录，说明绑定未完成，此时应先关闭售卖，而不是寄希望于后续订单自动修复。

重复发卡的常见原因，是回调处理没有去重吗？

重复发卡最常见的原因，正是回调去重没有做好。自动发卡平台通常通过 Webhook 推送订单、卡密或退款事件，第三方收到消息后必须先保存 eventId，同一个 eventId 再次到达时不能再次发卡。若只按订单号判断，一旦同一笔订单出现多条卡密事件，就可能重复触发派发动作。

处理回调时，可以先检查 JSON 格式和必填字段，确认 eventId 完整后再写入本地记录；派发前查询该 eventId 是否已处理，已处理则直接返回 HTTP 200 并返回纯文本 OK，不再调用发货接口。若担心消息丢失，可补充调用 GET /orders/{clientOrderRef} 查询订单详情，以接口返回的订单状态为准，而不是凭消息到达次数决定发卡次数。

网络抖动时重试，会不会造成重复下单或重复扣款？

网络抖动本身不会重复扣款，前提是重试时必须使用原来的 clientOrderRef 和原下单内容。按照订单创建规则，clientOrderRef 需要在当前采购账户内唯一，若网络超时或未收到明确结果，应使用原编号和原下单内容重试，平台会返回第一次创建的原订单，不会再次扣款或重复下单。

需要注意的是，clientOrderRef 不能改成另一件商品、另一规格、另一数量或不同充值资料，否则会返回 IDEMPOTENCY_CONFLICT。若下单参数校验失败，该编号不会被占用，修正后仍可复用；但订单已创建后，不能再用同一编号提交其他内容。验收时，可在网络异常场景下记录原编号，重试后只核对返回的同一订单编号，若返回的不是原编号，说明请求链路有问题，应停止继续提交，先查询订单详情确认结果。

没有配置回调地址，订单还能正常发卡吗？

可以。订单创建时不填写 orderCallbackUrl，平台不会在下单时复制默认回调地址，后续每条订单、卡密、退款或关联售后消息生成时，会使用当时的账户默认回调地址；两条地址都没有时，平台不发送该条 Webhook，但订单仍然正常创建，第三方通过订单详情查询状态、卡密和退款结果。

因此，未配置回调并不等于漏发，真正的风险在于没有主动查询导致卡密迟迟未被拉取。验收方式是：提交一笔不填回调地址的订单，订单显示创建成功后，主动调用 GET /orders/{clientOrderRef} 查询卡密结果，确认卡密字段已返回且格式完整，再将卡密安全保存到本地，避免因依赖回调而漏单。

最终应该怎样选择配置，才能兼顾稳定与可追溯？

如果你的订单量不大、没有成熟的回调处理程序，可以优先不配置订单级回调，依靠订单详情接口主动查询，保证每笔订单都有明确结果；如果你具备接收 Webhook 的条件，建议保留默认回调地址，并在回调处理中强制校验 eventId，把同一笔订单的多条事件收敛为一次发卡。

最终取舍的关键在于：发货链路越依赖自动推送，越必须做好幂等和原始单据核对；如果暂时无法保证去重逻辑，优先用查询接口兜底，宁可多查一次，也不要在状态不明确时补发卡密。

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