【问题标题】:iOS in-app purchase receipt validation - What happens if server is down?iOS 应用内购买收据验证 - 如果服务器关闭会发生什么?
【发布时间】:2018-10-01 15:45:50
【问题描述】:

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

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

流式传输 Apple 文档,购买将遵循以下步骤:

  • 用户在应用内开始购买
  • 用户向 App Store 进行身份验证并授权购买
  • App Store 完成购买(用户付费)
  • 应用会收到有关购买的通知(StoreKit、PaymentQueue、Transactions 等)
  • 应用程序将收据发送到服务器进行验证。
  • 服务器验证收据并向用户网络帐户添加“100 条提醒推送通知”

问题:如果服务器宕机,购买会发生什么?

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

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

当然,用户可以抱怨所购买的福利未送达,但是如何处理呢?

当使用非消耗性 IAP 时,用户可以简单地恢复之前的购买,但使用 消耗性 IAP 则无法做到这一点,是吗?

如果无法从 App Store 恢复购买,唯一的解决方案是在本地存储收据并为用户提供稍后验证的选项。 这是“正确”的解决方案还是有其他方法可以解决这个问题?

【问题讨论】:

    标签: ios in-app-purchase


    【解决方案1】:

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

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

    如果您的服务器已关闭并且您无法验证收据,您应该向用户提供某种形式的错误,并可能重新尝试验证。

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

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

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2018-11-30
      • 2014-07-19
      • 2011-10-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多