恢复购买与收据验证
Restore purchase vs. receipt validation
我有一个具有自动续订订阅功能的 macOS 应用程序。我正在阅读文档，但无法完全理解这个概念。根据文档，我必须将观察者添加到支付队列中。如果重新安装应用程序，我必须提供恢复功能来恢复购买。我的观察者正在监听队列，一旦我调用 SKPaymentQueue.default().restoreCompletedTransactions() 方法，它就会恢复事务。但是，我看不到订阅是否过期或不只是使用观察者。我在支付队列中收到的交易对象只有一些抽象的交易 ID。
文档建议验证收据。我将 base64 编码的收据发送到我的服务器，服务器又将其发送到 verifyReceipt 端点。即使我发送了旧收据，Apple 也会回复 JSON，其中包含 latest_receipt_info，我可以在其中看到订阅的当前状态及其到期日期。如果到期日期早于当前日期，我可以假设订阅不活跃。
问题是为什么我必须调用 SKPaymentQueue.default().restoreCompletedTransactions() 方法来恢复购买，如果我可以刷新收据（如果它丢失了）并将其发送到我的服务器并获取最近的信息？在我看来，这是多余的。所以我的用法是：
- 收听支付队列
- 在我收到具有已购买状态的交易后立即执行收据验证，如果我看到具有特定 productId 和过期日期晚于当前日期的交易，则解锁付费功能
- 当用户单击“恢复”按钮时执行收据验证并解锁付费功能，如果我看到具有特定 productId 和过期日期晚于当前日期的交易
- 在每次启动应用程序时执行收据验证以检查订阅状态
- 如果应用未关闭但订阅已过期，则每 12 或 24 小时执行一次收据验证以禁用付费功能
我是否清楚地理解了这个概念，还是因为我没有看到调用 SKPaymentQueue.default().restoreCompletedTransactions() 方法的好处而遗漏了什么？
您的理解是正确的。 restoreCompletedTransactions() 方法将使您不必在每次启动应用程序时都执行收据验证，这可能最终会变得昂贵，并且只有在用户明确触发它时才会这样做。在收据刷新期间，还有一些情况可能会提示用户输入他们的 Apple 登录信息，如果以编程方式触发，这可能是一种令人困惑的体验。
理想情况下，您将整个收据文件保存在您的服务器上，并按照您提到的每 12-24 小时在服务器端执行一次收据验证。这使您可以使订阅状态保持最新，无论用户是否打开应用程序。然后在每次启动应用程序时，您可以对后端进行轻量级调用以检查订阅状态，而不是在每次启动时都发出完整的收据验证请求。
我有一个具有自动续订订阅功能的 macOS 应用程序。我正在阅读文档，但无法完全理解这个概念。根据文档，我必须将观察者添加到支付队列中。如果重新安装应用程序，我必须提供恢复功能来恢复购买。我的观察者正在监听队列，一旦我调用 SKPaymentQueue.default().restoreCompletedTransactions() 方法，它就会恢复事务。但是，我看不到订阅是否过期或不只是使用观察者。我在支付队列中收到的交易对象只有一些抽象的交易 ID。
文档建议验证收据。我将 base64 编码的收据发送到我的服务器，服务器又将其发送到 verifyReceipt 端点。即使我发送了旧收据，Apple 也会回复 JSON，其中包含 latest_receipt_info，我可以在其中看到订阅的当前状态及其到期日期。如果到期日期早于当前日期，我可以假设订阅不活跃。
问题是为什么我必须调用 SKPaymentQueue.default().restoreCompletedTransactions() 方法来恢复购买，如果我可以刷新收据（如果它丢失了）并将其发送到我的服务器并获取最近的信息？在我看来，这是多余的。所以我的用法是：
- 收听支付队列
- 在我收到具有已购买状态的交易后立即执行收据验证，如果我看到具有特定 productId 和过期日期晚于当前日期的交易，则解锁付费功能
- 当用户单击“恢复”按钮时执行收据验证并解锁付费功能，如果我看到具有特定 productId 和过期日期晚于当前日期的交易
- 在每次启动应用程序时执行收据验证以检查订阅状态
- 如果应用未关闭但订阅已过期，则每 12 或 24 小时执行一次收据验证以禁用付费功能
我是否清楚地理解了这个概念，还是因为我没有看到调用 SKPaymentQueue.default().restoreCompletedTransactions() 方法的好处而遗漏了什么？
您的理解是正确的。 restoreCompletedTransactions() 方法将使您不必在每次启动应用程序时都执行收据验证，这可能最终会变得昂贵，并且只有在用户明确触发它时才会这样做。在收据刷新期间，还有一些情况可能会提示用户输入他们的 Apple 登录信息，如果以编程方式触发，这可能是一种令人困惑的体验。
理想情况下，您将整个收据文件保存在您的服务器上，并按照您提到的每 12-24 小时在服务器端执行一次收据验证。这使您可以使订阅状态保持最新，无论用户是否打开应用程序。然后在每次启动应用程序时，您可以对后端进行轻量级调用以检查订阅状态，而不是在每次启动时都发出完整的收据验证请求。