自动发货多快才算合格，不受订单规模影响

判断自动发货速度是否合格，不能在订单高峰期直接拿后台订单刷新状态来算，也不能拿平时偶尔出现的秒级推送当作常态。虚拟卡券从买家付款到真正可用，中间至少跨过支付确认、订单状态变更、卡密生成和消息可取四个动作。任何一个环节缺少可查证的时间记录，速度就没有横向对比的基础。所谓合格，指的是让发货速度口径固定之后，在店铺自身的订单规模与货源条件下也能稳定复现，而不是制造一次看上去很快的演示。

合格的基础是从确定的时间起点对齐到确定的结果终点。计时起点应取支付渠道完成扣款后、平台账户确认资金入账的时间，不要从买家点击付款开始。取买家发起时间会把支付网关排队时间混入发货速度，导致旺季测评直接失真。计时终点应取卡密消息已生成且买家在查询接口中能稳定查到该订单和卡密的时间，不能只看后台是否显示已发货。尤其当订单填写了独立的 orderCallbackUrl 时，还要确认消息是否在同一地址投递完成，而不是默认推送到默认回调地址就视为完成。

不同订单规模下，发货时延的合格边界并不相同，高峰与平峰也不能用同一把尺子量。衡量时要把平均响应与极端延迟拆开看：平峰期单个订单从入账到出码，合理的目标是在人工可感知范围内迅速完成；高峰期则需要观察同一时段内全部订单是否都能在设定的时间边界内持续出码，而不是只看最先完成的几个订单。只要付款后仍由人工手动复制卡密再补发，即使平均耗时很低，也不符合自动发货的合格标准，因为交付链路不可控且无法复现。

用测试订单验证真实发货速度时，应在真实环境准备一个非干扰性的测试订单，并记录对应 clientOrderRef。发起后通过查询接口读取订单状态，分别核对入账时间、出码时间和通道可取时间，而不能只凭后台的完成提示。涉及 Webhook 的，要在日志中保存并比对 eventId，确认同一事件未被重复推送或重复发卡；同时检查消息生成时是否存在订单地址配置或默认回调缺失导致的漏收，再以接口查询结果作为最终交付依据。若多次测试延迟忽快忽慢，需要先从货源出码和系统凭据环节排查，而不是直接调整计时口径来迁就结果。此类标准只适用于已配置好自动发卡与回调通知的店铺；若渠道尚未开通通知、或订单本身存在人工复核要求，仍需退回人工核验，按实际等待时长设定下一阶段的验收标准。

在用测试订单验证真实发货速度时，除了记录时间外，还必须把中断与异常也纳入统计。例如，商品在发货前需要先完成订阅或续期，商品变化消息没有及时接收，就会导致卡密生成被延迟，这种延迟既不能算在买家身上，也不能被简单的秒级口径掩盖。判断是否合格时，需要把这类需要人工处理的中断单独标记，不能混入自动发货的正常耗时，否则会连带掩盖货源或接口配置问题。

验收时还要区分不同货源的交付条件。例如，同一货源在平峰期能快速出码，不代表在促销或现金流紧张时也能保持同样速度；当货源涉及外部渠道对接时，发货快慢还受上游限流和渠道冷却配置影响。只有在货源稳定、回调地址有效、测试订单能连续完成的前提下，得到的速度数据才适合作为店铺自己的合格基准，再据此去设置后续的监控与预警阈值。

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