iOS 使用后端服务器处理本地 SKPaymentTransaction
iOS Handling local SKPaymentTransaction when using backend server
我正在创建一个具有自动续订订阅功能的 iOS 应用。我已经阅读了很多教程和文档，但我对如何处理某些情况有点困惑。
这是我的应用程序的工作方式：
- 用户安装应用程序
- 用户在注册流程中创建帐户
- 要求用户select 计划并在注册流程中付款
- 付款收据已上传到我的服务器，我在我的数据库中激活了他们的帐户。
- 我的服务器定期轮询
/verifyReceipt 端点以更新用户帐户或停用它，具体取决于苹果的最新信息。 （或使用 Apple 的新状态更新通知，两者的目的相同，都是在我的服务器上获取最新的订阅信息）
订阅续订一个月后，我知道交易将出现在用户设备的 SKPaymentQueue 上。因此，很多 tutorials/documentation 建议让您的 AppDelegate 实施 SKPaymentTransactionObserver 协议，以便您可以随时处理交易。
但是，我没有使用AppDelegate。我在注册中使用了视图控制器，用户可以在其中选择要实施的计划 SKPaymentTransactionObserver.
我的理由是，既然我在后端获取信息，我是否需要关心每个月订阅续订时将显示在客户端队列中的交易？我不能忽略这些交易，还是需要对它们调用 queue.finishTransaction？
我还阅读了一些有关在用户删除应用程序并重新安装或获取新应用程序时恢复交易的内容 phone。再一次，我需要担心这个吗？因为我仍然应该知道后端的订阅，当用户获得新的 phone 时，他们所要做的就是登录他们的帐户以获得我的服务，它会检查后端以查看他们的订阅是否是活跃。
我想我更大的问题是：当你有一个后端来处理 IAP 自动续订订阅时，你能否忽略客户端上发生的一些带有支付队列的事情，因为该功能是为那些不支持的应用程序构建的没有后端。
最佳做法是立即在 AppDelegate 中实施观察者，以防 Apple 向用户收费和升级他们的帐户之间出现问题 - 如果他们关闭应用程序或应用程序崩溃，您可能会丢失该交易。
此外，我认为我遇到过忘记调用 finishTransaction 并且烦人的 iTunes 登录提示不断弹出的情况，但我不确定那是否只是 Sandbox 事件。
就像@Paulw11 说的。 不要依赖状态通知。在撰写本文时，他们没有提供足够的信息来更新用户的状态，即任何类型的用户标识符。从后端刷新收据是要走的路。如果新收据被 posted 到 SKPaymentQueue（比如续订），您可以像服务器上用户的任何其他收据刷新一样处理它。
这是一篇很好的博客 post，它提供了有关服务器上应该发生的事情的更多详细信息：iOS Subscriptions are Hard
对于您的恢复逻辑，您不需要使用 StoreKit 恢复方法如果您已经通过基于帐户的系统实现了自己的恢复功能。如果那是你想走的路线，你绝对应该在 AppDelegate 中听 SKPaymentQueue 以避免尽可能多的边缘情况，你可能会失去对某人订阅状态的跟踪。好的 'ol "Restore Purchases" 按钮是修复一些有轻微缺陷的应用内购买代码的好方法:)
I guess my larger question is: When you have a backend to handle IAP
auto-renewal subscriptions, can you ignore some of the stuff happening
on the client with the payment queue because that feature was built
for apps that don't have a backend.
不要忽略付款队列。如果您有自己的基于帐户的还原系统，则可以忽略 "Restore Transactions"。
我正在创建一个具有自动续订订阅功能的 iOS 应用。我已经阅读了很多教程和文档，但我对如何处理某些情况有点困惑。
这是我的应用程序的工作方式：
- 用户安装应用程序
- 用户在注册流程中创建帐户
- 要求用户select 计划并在注册流程中付款
- 付款收据已上传到我的服务器，我在我的数据库中激活了他们的帐户。
- 我的服务器定期轮询
/verifyReceipt端点以更新用户帐户或停用它，具体取决于苹果的最新信息。 （或使用 Apple 的新状态更新通知，两者的目的相同，都是在我的服务器上获取最新的订阅信息）
订阅续订一个月后，我知道交易将出现在用户设备的 SKPaymentQueue 上。因此，很多 tutorials/documentation 建议让您的 AppDelegate 实施 SKPaymentTransactionObserver 协议，以便您可以随时处理交易。
但是，我没有使用AppDelegate。我在注册中使用了视图控制器，用户可以在其中选择要实施的计划 SKPaymentTransactionObserver.
我的理由是，既然我在后端获取信息，我是否需要关心每个月订阅续订时将显示在客户端队列中的交易？我不能忽略这些交易，还是需要对它们调用 queue.finishTransaction？
我还阅读了一些有关在用户删除应用程序并重新安装或获取新应用程序时恢复交易的内容 phone。再一次，我需要担心这个吗？因为我仍然应该知道后端的订阅，当用户获得新的 phone 时，他们所要做的就是登录他们的帐户以获得我的服务，它会检查后端以查看他们的订阅是否是活跃。
我想我更大的问题是：当你有一个后端来处理 IAP 自动续订订阅时，你能否忽略客户端上发生的一些带有支付队列的事情，因为该功能是为那些不支持的应用程序构建的没有后端。
最佳做法是立即在 AppDelegate 中实施观察者，以防 Apple 向用户收费和升级他们的帐户之间出现问题 - 如果他们关闭应用程序或应用程序崩溃，您可能会丢失该交易。
此外，我认为我遇到过忘记调用 finishTransaction 并且烦人的 iTunes 登录提示不断弹出的情况，但我不确定那是否只是 Sandbox 事件。
就像@Paulw11 说的。 不要依赖状态通知。在撰写本文时，他们没有提供足够的信息来更新用户的状态，即任何类型的用户标识符。从后端刷新收据是要走的路。如果新收据被 posted 到 SKPaymentQueue（比如续订），您可以像服务器上用户的任何其他收据刷新一样处理它。
这是一篇很好的博客 post，它提供了有关服务器上应该发生的事情的更多详细信息：iOS Subscriptions are Hard
对于您的恢复逻辑，您不需要使用 StoreKit 恢复方法如果您已经通过基于帐户的系统实现了自己的恢复功能。如果那是你想走的路线，你绝对应该在 AppDelegate 中听 SKPaymentQueue 以避免尽可能多的边缘情况，你可能会失去对某人订阅状态的跟踪。好的 'ol "Restore Purchases" 按钮是修复一些有轻微缺陷的应用内购买代码的好方法:)
I guess my larger question is: When you have a backend to handle IAP auto-renewal subscriptions, can you ignore some of the stuff happening on the client with the payment queue because that feature was built for apps that don't have a backend.
不要忽略付款队列。如果您有自己的基于帐户的还原系统，则可以忽略 "Restore Transactions"。