自动发货速度多快才算合格，该以哪些时间点来衡量

自动发货速度是否合格，不能只看一句“秒发”，而要回到可测量的时间点。虚拟卡券从用户付款到真正可用，至少跨支付确认、订单状态、卡密生成和通知可取，缺失其中任一阶段记录就无法建立判断基准。因此，合格的底线是把全过程拆成可观察、可复现的时间段，而不是拿营销表述当验收依据。

合格的发货速度，应以哪个时间点作起点和终点？

起点只能取资金或订单已确认的时间，不能取用户点击支付的时间。买家点击后，支付通道需要完成清算，订单才能进入可发状态；若以点击动作计时，会把不属于发货链路的等待计入，导致判定失真。更稳妥的做法是用订单状态已变更为已支付的记录作为起点，这一点可通过订单查询接口核对，买家侧页面显示往往存在同步延迟，不适合直接取用。

终点则应取卡密生成且买家可实际取用的时间。仅看后台日志写入卡密并不充分，还要确认卡密消息已生成，或买家能在订单页自助取用。若消息未能投递，仍应通过查询接口获取当前结果，而不能默认已经交付。只有起点是客观状态、终点是可获取结果，测出的耗时才具备稳定性，后续才能用于同类订单比较。

在什么订单规模下，收货速度才算真正合格？

小订单量时可设更严标准，但不能只追求灌输式瞬时出码，还要保证状态可追溯。合适的方法是先在低峰期测出基线，再在高峰期允许更宽的耗时区间，两者分开验收。低峰可按较短目标验收，高峰则优先保证不出现异常停滞，而不是强压秒级目标。只要同一时段多次复测落在稳定区间，就认为该场景下速度合格。

规模扩大后，单看总耗时会掩盖真实瓶颈，应当把链路拆成支付确认、出码、通知三段分别设限。确认阶段盯着订单状态是否及时更新；出码阶段核对卡密消息是否生成并保存；通知阶段确认投递路径或自助取用是否可完成。分段都有明确记录，即使某一段偏慢，也能定位原因并决定是否需要调整阈值，这比单纯追求总时长更符合实际经营需要。

怎么用接口与测试订单验证真实发货速度？

验证应从订单查询接口入手。创建一笔测试订单后，先记录支付确认时间，再按固定间隔查询订单详情，观察状态是否推进；随后核对卡密消息是否触发，若配置了Webhook，还需检查回调是否到达，消息需先保存后再进入后续流程。同一个事件若重复收到，不能因eventId相同而重复发卡或重复统计，否则会把假重复计入速度测试。

建议在相近时段连续测试多笔，分别记录每个阶段的实际耗时，取多数落在的区间作为合格线，而不是取单笔最快值。若个别订单耗时异常，先核对订单号和事件是否对应，再判断是投递地址缺失、接口不稳定还是链路阻塞，在原因未确认前不要调整阈值。这样建立的标准才能用于后续优化，而不是依赖一句“即时到账”来掩盖不可复现的问题。

除了接口检查，卖家还要区分自动发货给用户的可取速度与商家掌握结果的速度，即“用户感知”与“系统记录”的差异。用户只能看到自己何时收到卡密，但系统还需完成保存、对账和防重校验，比如识别同一订单或同一事件的重复投递。因此在解释合格速度时，应以买家可核对的那一端为基准，后台的再处理时间只能单独看，不能悄悄计入发货延迟。

另一个容易被忽略的是通知链路。若订单设置了 orderCallbackUrl，消息会优先发往该地址，而不再读取默认回调地址；若该地址不可达，又没有可用查询记录，速度判定会失去客观依据。此时应回查订单详情接口，以当前可获取结果为准，而不是把投递失败直接算成发货延迟。

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