自动发货壁垒怎么建，靠Webhook确认流程
自动发货的商品和价格易被复制，Webhook确认与重试机制却难以复刻。本文以卡易速公开接口规则为依据，给出可落地的搭建步骤与验收标准。
自动发货的商品描述和价格很容易在同行间快速模仿，但一套可稳定运行、可回溯的Webhook确认机制，却是同行难以直接拿走的。买家付款后希望尽快拿到卡密，经营侧又要保证每一笔交付都能准确落库、不重复发卡，想要建立长期壁垒，可以从规范Webhook的接收、确认和重试流程入手。本文只解决一个问题：按卡易速已公开的接口规则，怎样搭建一套可复用的Webhook确认流程，并用明确的标准验收结果。
先确认现有链路是否满足基础条件
搭建流程前，先核对现有链路是否满足三个基础条件。卡易速Webhook默认启用，不需要额外设置事件开关，前提是要在商户前台“账户管理>接口管理”保存默认回调地址，或者在创建订单时填写当前订单的orderCallbackUrl。其次要准备可接收HTTPS请求的回调服务，不能只依赖HTTP地址，避免身份无法核实。最后要确认回调服务具备本地保存eventId与卡密的能力，且支持在3秒内返回响应。这三点不满足时，后续的确认和重试流程都无法稳定运行。
按固定顺序搭建接收与确认流程
满足基础条件后，按固定顺序搭建，避免遗漏关键动作。
- 保存回调地址：在商户前台保存默认回调地址，或在创建订单时填写orderCallbackUrl。订单填写后，订单、卡密、退款等消息优先发送到该地址，不会受后续默认地址修改的影响。
- 配置接收校验：回调服务收到消息后，先检查JSON格式与必填字段，再保存eventId，不能先处理卡密再存eventId。
- 处理重复消息：同一个eventId再次收到时，不重复发卡、不记录退款、不追加售后消息，直接返回成功。
- 保存卡密并响应：卡密消息必须先安全保存，再交给后续发货流程，数据保存成功后返回HTTP 200，响应正文去除首尾空白后忽略大小写等于OK。
- 异步处理耗时业务：保存成功后立即返回响应，耗时的发货、同步等流程在返回后异步处理，不能拖慢响应速度。
设置可验证的重试与容错动作
Webhook消息最多发送3次，第一次立即发送，没有收到OK时，在第一次发送后的第15秒和第30秒各重试一次。三次使用同一个eventId、回调地址和请求正文，第三次仍失败后停止发送，且不提供发送记录查询。经营侧需要设置两个容错动作：收到卡密消息时先存库再处理，避免因流程中断导致卡密丢失；商品消息用于同步变化，需要确认商品当前状态时调用商品查询接口，不直接用回调消息下结论。订单和退款可以通过GET /orders/{clientOrderRef}查询，售后可以查询售后详情，不能用重新创建订单、重复下单或关闭安全校验来排查问题。
用明确标准验收搭建结果
流程搭建完成后，从三个维度验收，全部符合才算完成。
- 响应达标：回调服务返回的HTTP状态为200，响应正文去除首尾空白后忽略大小写等于OK，且接收到消息后3秒内完成保存并返回，超时、空正文、JSON或其他文本均视为失败。
- 去重有效：手动重复推送同一条带eventId的消息，不会重复发卡、记录退款或追加售后消息，库存和订单状态不受影响。
- 容错可用：模拟一次失败后，第15秒和第30秒能收到重试消息，第三次失败后停止发送，此时通过查询接口能拿到订单、卡密或售后的真实状态，不会因回调失败导致业务中断。
以上步骤全部落地且验收通过后，你的自动发货链路就有了可回溯、可复用的确认机制，这就是别人难以复制的业务壁垒。
参考资料：接入指南（2026-09-20）。具体操作与适用范围以对应文档为准。