付款后卡密没到先查订单状态还是回调地址

付款成功却收不到卡密，首先要区分是订单根本没创建，还是消息已发出但第三方没有落地。自动发卡平台在余额扣款成功后才会创建订单，若账户余额不足，既不会创建订单，也不会改走其他支付方式。排查不到账，先回到订单本身，不要仅凭付款截图判断发货已经触发。

先确认订单是否按幂等规则创建

在商户后台或通过 GET /orders/{clientOrderRef} 查询订单详情，这是定位一切后续问题的前提。只有余额扣款成功才会创建订单；拿不到订单详情，说明交易没有正式进入发卡链路。

• 出现原订单：网络超时或未收到明确结果时，必须用原 clientOrderRef 和原下单内容重试。平台会返回第一次创建的原订单，不会再次扣款或重复下单。
• 出现 IDEMPOTENCY_CONFLICT：说明使用了已绑定过其他商品、规格或数量的 clientOrderRef，不能用同一编号创建另一笔订单，也不要改换商品信息后重复提交。
• 返回 PURCHASE_SCHEMA_CHANGED：模板或数量规则已变化，需重新查询 /goods/tpl、更新本地下单表单后，继续使用原 clientOrderRef 再次提交。

例如买家付款后页面超时，此时最稳妥的做法是保留原订单编号，不要重新生成新订单，也不要让买家重复支付。

核对回调地址是否为该笔订单的有效推送目标

订单创建成功不代表消息一定送达。Webhook 消息生成时只选择一个接收地址并固定下来，之后修改默认地址不会改变已经生成的消息；如果生成时既没有订单地址，也没有账户默认地址，该条 Webhook 就不会发送，但订单仍然正常创建，第三方只能通过查询接口获取结果。

• 订单填写了 orderCallbackUrl 后，订单、卡密、退款及关联售后消息优先发送到该固定地址，且订单创建成功后不能更换。
• 没有填写订单地址时，每条消息生成时读取当时的账户默认回调地址，路径上的路径和查询参数须为公网 HTTPS，且不得包含用户名、密码、# 片段或 IP 地址，也不能返回 HTTP 跳转。
• 历史消息已经进入发送流程后，修改默认地址不会影响其接收目标。

例如开发者曾填写订单回调地址，之后又在后台修改默认地址，此前生成的卡密消息不会改道，应该继续向原地址查询落地记录。

按消息唯一 ID 排除重复处理或漏收

第三方收到卡密消息后应保存 eventId，同一个 eventId 再次收到时不要重复发卡。同时需要检查本地是否因为把某次重复消息静态拦截，导致后续真正发货动作被跳过。

• 重复收到同类消息：保存 eventId 后按同一单返回 HTTP 200，正文用纯文本 OK，避免平台重复重试同一消息。
• 未收到任何消息：不要仅凭付款提示判断已发卡，需调用 GET /orders/{clientOrderRef} 核对订单详细状态与卡密字段。

处理后的验证与关键取舍

定位到原因后，先在本地用防伪标识和唯一单号做一次自检，再确认买家能否凭订单号正常取卡。如果问题出在消息未推送，应以订单详情的最终状态为准，而不是等待另一次 Webhook；如果问题出在重复处理，则以首次落库的卡密记录为准，紧急情况下可关闭本地去重围栏后重跑后续动作，但不得人为制造第二笔扣款或第二份卡密。最终取舍看收款是否已经完成：已完成扣款就必须以原订单为基础修复，未完成扣款则按校验原因修正后重提原单。

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