Webhook 发货链路及 API 动态请求相关问题

[wenaryHY]

目前在本地测试环境中测试 Webhook 远程发卡及发货配置时，发现以下几个问题。

1. Webhook 远程发卡后，虚拟物品无法同步卡密

问题描述

在本地测试环境中，如果启用 Webhook 链路调用远程发卡，但未配置「发货配置」，订单虽然可以通过 Webhook 正常完成远程发卡，但 Halo 本地订单的「订单详情 → 发货列表 → 虚拟物品」会出现发货失败，无法获取卡密。

错误日志：

ERROR VirtualFulfillmentProcessor: Fulfillment 1 failed permanently after 3 retries: No enabled delivery config found for product variant 1

从日志来看，即使 Webhook 链路已经完成远程发卡，本地的 VirtualFulfillmentProcessor 仍然会尝试通过「发货配置」获取虚拟物品，因此最终导致履约失败。

测试结果

订单	Halo 状态	Webhook	卡密	邮件	备注
订单 1	❌ 永久失败	✅ 收到	❌ 失败	—	未配置发货配置，未绑定 SkuCode，虚拟物品发货失败
订单 2	✅ 成功	✅ 收到	❌ 未同步	✅ 3 封	设置了资源下载方式，但未配置发货配置
订单 3	❌ 失败	✅ 收到	❌ 未同步	✅ 2 封	Webhook 发卡成功，数字商品已交付，但邮件通知缺失

初步判断

目前来看，在启用 Webhook，且不依赖「发货配置」中的 API 请求方式时：

1. Webhook 可以正常调用远程发卡接口；
2. 远程发卡已经成功完成；
3. 但本地订单的「发货列表 → 虚拟物品」仍然会尝试通过「发货配置」获取卡密；
4. 当未配置发货配置时，会直接抛出：

No enabled delivery config found for product variant 1

因此导致 Halo 本地订单无法同步远程发卡结果中的卡密。

另外，在配置「资源下载方式」后，订单虽然不会直接因为缺少发货配置而失败，但目前仍然存在卡密 / 卡密链接未同步的问题。

期望行为

如果订单已经通过 Webhook 完成远程发卡，希望远程发卡结果能够同步回当前订单，例如：

Webhook
  ↓
远程发卡成功
  ↓
获取发卡结果 / 卡密
  ↓
同步至 Halo 订单
  ↓
订单详情 → 发货列表 → 虚拟物品
  ↓
显示卡密 / 卡密链接

也就是说，Webhook 发货链路是否应该可以独立完成发货结果同步，而不再依赖本地「发货配置」中的 API 请求方式？

如果 Webhook 本身不会直接返回卡密，是否应该在 Webhook 调用完成后，再通过对应的 GET 接口查询本次发货结果 / 卡密，并将结果同步到 Halo？

想确认

这里可能是我遗漏了某个配置或使用步骤，想确认一下目前 Webhook 发货的正确流程：

• Webhook 调用成功后，是否应该通过某个 GET 接口获取本次发货的卡密？
• 如果是，应该使用哪个接口，以及通过什么参数关联当前订单或 SkuCode？
• 或者 Webhook 本身应该返回卡密，随后由 Halo 直接完成虚拟物品同步？
• 在 Webhook 发货模式下，「发货配置」理论上是否可以不配置？

---

2. 多商品配置 API 动态请求时，疑似存在配置之间的影响

问题描述

在使用「发货配置 → API 动态请求」时，如果不同商品分别配置了不同的 API 请求，例如：

商品 A → API A
商品 B → API B
商品 C → API C

在实际测试中发现，当用户只购买其中一个商品时，其他商品对应的 API 配置似乎也可能参与当前订单的校验或处理流程。

目前还无法确定具体的执行逻辑，因此这里只记录实际观察到的现象，希望确认当前发货配置的匹配机制。

例如：

商品 A → API A
商品 B → API B
商品 C → API C

用户实际购买：
商品 A

观察到：
当前订单的处理似乎仍会受到其他 API 配置的影响

如果其他商品的 API 配置存在异常，可能会进一步影响当前订单的履约。

想确认

这里主要想确认一下：

• API 动态请求的发货配置，是根据当前订单中的商品 / Variant 精确匹配的吗？
• 当前订单履约时，是否只应该处理实际购买商品对应的 API 配置？
• 不同商品之间的 API 配置是否存在共享校验或其他关联逻辑？
• 如果确实只应该匹配当前购买的商品，是否存在当前配置匹配范围过大的情况？

目前这一项不确定是否属于实现问题，希望先确认具体的匹配及校验逻辑。

---

3. 使用优惠券进行 0 元购时，Webhook 调用失败

问题描述

当用户使用优惠券抵扣订单金额，使订单最终金额为 0 元 时，Webhook 调用会失败。

例如：

商品金额
  ↓
优惠券抵扣
  ↓
订单金额 = 0 元
  ↓
订单完成 / 进入履约流程
  ↓
Webhook 调用失败

目前来看，Webhook 链路可能对订单金额或支付状态存在额外判断，导致 0 元订单无法正常触发或完成 Webhook 发货。

期望行为

如果订单通过优惠券完成 100% 抵扣，最终订单金额为 0 元，只要订单已经满足「已支付 / 可履约」条件，就应该与正常支付订单一样进入 Webhook 发货流程。

例如：

正常支付：

订单创建
  ↓
支付成功
  ↓
Webhook
  ↓
远程发卡
  ↓
同步发货结果


0 元购：

订单创建
  ↓
优惠券 100% 抵扣
  ↓
订单金额 = 0
  ↓
订单完成 / 视为支付完成
  ↓
Webhook
  ↓
远程发卡
  ↓
同步发货结果

想确认

• 0 元订单是否应该被视为已支付 / 可履约订单？
• Webhook 是否存在针对订单金额的额外判断？
• 当前 Webhook 失败是否与订单金额 amount = 0 有关？
• 如果是 0 元订单，是否需要走单独的支付完成逻辑？

---

总结

目前主要发现三个问题：

1. Webhook 远程发卡成功后，Halo 本地虚拟物品无法同步卡密，并且似乎仍然依赖「发货配置」获取履约结果。
2. 多商品分别配置 API 动态请求时，实际订单似乎可能受到其他商品 API 配置的影响，需要确认具体的匹配及校验逻辑。
3. 优惠券 100% 抵扣形成 0 元订单后，Webhook 无法正常调用。

其中第 2 项目前仅为测试过程中观察到的现象，尚不能确定具体原因，希望先确认当前的配置匹配及校验机制。

[w-flac]

问题2补充：在发货配置中 设置了api，但未启用，期望走的是webhook的链路，但似乎依然会请求api

[ruibaby]

感谢反馈。

1. 目前 Webhook 的主要作用可能还只是起到一个通知作用，我认为不太适用于调用远程服务去生成卡密并发货，这里推荐对接卡密发货配置。不过后续仍然可以考虑让虚拟物品支持不提前配置，而是手动发货，这样的话，应该可以实现通过 Webhook + 调用 Halo API 去完成发货了。
   2/3. 这个问题我们会再确认一下。