iOS 应用内购买收据验证 - 如果服务器出现故障会怎样？

Question

假设一个简单的 ToDo-List 应用程序可以连接到一个网络服务帐户。 Web 服务允许用户在线编辑他的待办事项列表并在不同设备之间同步数据。

现在我想将 consumable 应用内购买项目添加到 iOS，允许用户购买不同的按使用付费功能。例如“100 个提醒推送通知”可能是一个 IAP 项目...

使用 Apple 文档购买将遵循以下步骤:

• 用户在应用内开始购买
• 用户向 App Store 进行身份验证并授权购买
• App Store 完成购买(用户支付)<-- 从 App Store 的角度购买完成
• 应用收到有关购买的通知(StoreKit、PaymentQueue、交易等)
• 应用程序将收据发送到服务器进行验证。
• 服务器验证收据并将“100 个提醒推送通知”添加到用户网络帐户<-- 从应用程序的角度来看购买完成

问题:如果服务器宕机，购买会怎样？

即使实际购买结果(向用户帐户添加提醒)不会存储在服务器上而是存储在本地设备上，如果服务器出现故障或没有互联网连接，收据验证和购买完成也会失败。

但是，从 App Store 的角度来看，一旦用户授权付款，购买就完成了。该应用程序是否真的完成了购买并为用户带来了任何好处，不会打扰 App Store。

当然，用户可以投诉购买的福利没有送达，但如何处理？

当使用非消耗型 IAP 时，用户可以简单地恢复之前的购买，但是使用消耗型 IAP 是不可能的，对吗？

如果无法从 App Store 恢复购买表格，唯一的解决方案是将收据存储在本地并为用户提供稍后验证它的选项。 这是“正确”的解决方案还是有另一种方法来处理这个问题？

Answer 1

您的顺序在第 3 点不正确。

您的应用程序接收更新后的交易，然后启动验证和保存购买所需的任何逻辑。一旦您的应用程序完成此操作，它就会在支付队列中完成交易。此时，从 App Store 的角度来看，购买已完成。

如果您的服务器出现故障并且您无法验证收据，您应该向用户提供某种形式的错误信息并可能重试验证。

交易将保持待定状态，并在您的应用下次启动时重新呈现给您的付款队列观察员。这就是为什么您的应用程序在启动时应该做的第一件事就是注册一个支付队列观察者对象。

当您最终能够完成收据验证并坚持购买时，您就完成了付款队列中的交易。