我正在创建一个带有自动续订订阅的iOS应用程序。我一直在阅读很多教程和文档，但我对如何处理某些场景感到困惑。
这是我的应用程序的工作方式：
/verifyReceipt端点以更新用户的帐户或根据来自apple的最新信息停用它。 （或使用Apple的新状态更新通知，两者都有相同的目的，以便在我的服务器上获取最新的订阅信息）订阅续订一个月后，我知道交易将出现在用户设备的SKPaymentQueue上。因此，许多教程/文档建议让AppDelegate实现SKPaymentTransactionObserver协议，以便您可以随时处理事务。
但是，我没有使用AppDelegate。我在注册中使用了视图控制器，用户选择了实施SKPaymentTransactionObserver的计划。
我的理由是，由于我在后端获取信息，我是否需要关心订阅续订时每月将在客户端队列中显示的事务？我不能忽略这些交易，还是需要在它们上面调用queue.finishTransaction？
当用户删除应用程序并重新安装或获取新手机时，我还会阅读有关恢复交易的一些信息。同样，我需要担心这个吗？因为我仍然应该知道后端的订阅，并且当用户获得新手机时所有用户必须登录到他们的帐户以获取我的服务，并且它将检查后端以查看他们的订阅是否有效。
我想我的更大问题是：当你有一个后端来处理IAP自动续订订阅时，你能否忽略客户端上带有支付队列的一些事情，因为该功能是为没有后端的应用程序构建的。
最好的做法是立即在AppDelegate中实现观察者，以防Apple用户和您升级帐户之间出现问题 - 如果他们关闭应用程序或者崩溃，您可能会丢失该交易。
另外，我想我曾经遇到过忘记打电话给finishTransaction的情况，并且令人讨厌的iTunes登录提示不断弹出，但不确定这是否仅仅是Sandbox事件。
喜欢@Paulw11说。不要依赖状态通知。在撰写本文时，他们没有提供足够的信息来更新用户的状态，即任何类型的用户标识符。从后端刷新收据是要走的路。如果将新收据发布到SKPaymentQueue（例如续订），您可以像处理服务器上用户的任何其他收据刷新一样处理。
这是一篇很好的博客文章，提供了有关服务器上应该发生什么的更多细节：iOS Subscriptions are Hard
对于还原逻辑，如果已通过基于帐户的系统实现了自己的还原功能，则无需使用StoreKit还原方法。如果那是你想去的路线，你一定要在AppDelegate中听SKPaymentQueue，以避免尽可能多的边缘情况，你可能会忘记某人的订阅状态。良好的“ol”恢复购买“按钮是修复一些有点缺陷的应用内购买代码的好方法:)
我想我的更大问题是：当你有一个后端来处理IAP自动续订订阅时，你能否忽略客户端上带有支付队列的一些事情，因为该功能是为没有后端的应用程序构建的。
不要忽略支付队列。如果您有自己的基于帐户的还原系统，则可以忽略“还原事务”。