1

我们有一个服务器，除其他事项外，它需要在将消耗品退还给用户之前从第三方（通过 API 调用）购买一些东西。显然，它会事先检查 Apple 收据。

处理服务器端应用程序内故障的最佳方法是什么，比如 3rd 方服务失败？此时用户的体验是已经支付但没有收到消耗品，再次尝试会导致他们花费更多的钱。

到目前为止，我想出了：

在设备上

  1. 当 inapp 完成时，将该 productId 的收据存储为“无人认领”
  2. 像往常一样联系服务器。
  3. 如果成功则清除无人认领的收据/productId
  4. 如果错误，那么下次用户尝试相同的应用程序时，跳过实际购买部分并直接进入 2. 之前的收据。

然后在服务器上

  1. 与苹果核对收据
  2. 检查我们是否尚未为用户提供该收据的消耗品（防止重复使用收据）
  3. 给第 3 方打电话
  4. 成功返回消耗品。
  5. 在失败时回复错误（此时客户端将保持收据无人认领并在重试时重新发送）。

提前致谢！

4

2 回答 2

0

我的方法是使它成为一种事务：
将您的步骤 2 分成 2a、2b、2c 和 2d 并涉及客户端服务器

服务器：

=> 2a = 检查我们没有使用收据（在我们的已用和已交付货物的内部数据库中）
-> 如果未使用则交付

客户：

-> 购买并执行 2b
=> 2b 告诉服务器我们收到了数据！

服务器：

=> 2c：等待客户确认 => 2cd= 将收据标记为已烧毁（在我们的数据库中），因为我们已经交付了它

于 2013-01-30T08:59:46.787 回答
0

据我了解，您的主要问题是与购买消耗品相关的 UI/UX。

我不知道您的消耗品如何对用户“可见/可用”，但我的关键是让用户清楚地知道与服务器的交易进入了“临时失败”状态。当您的应用下载遇到任何障碍时，这与在 App Store 中发生的情况相同。它可以标记为“加载/等待”，如果您可以明确指出只需要下载耗材（“安装/重试/下载/回收”而不是“购买”而不是“购买”，那将是很好的） ）。

在同一个地方有一个“在出现问题时联系我们”选项也是非常好的。我不知道为什么您的第 3 方连接可能会失败，但如果它以一种不那么零星的方式发生，我敢打赌，不止几个用户需要抱怨。

至于问题的客户端 - 服务器协议方面，你所描述的对我来说似乎很好。这里的关键是服务器会跟踪哪个收据已经被成功认领；原则上，客户端可以尝试多次重用收据，它只会在第一次尝试时成功（在服务器将收据标记为已交付之前）。如果你想要更多的弹性，我会引入一个从客户端到服务器的显式确认阶段，确认消耗品已成功计算。

希望能帮助到你。

于 2013-01-30T09:26:04.943 回答