自动订阅应用内购买:恢复后续续订

发布于 2024-10-18 03:18:24 字数 338 浏览 3 评论 0原文

根据 Apple 应用内购买编程指南:

App Store 每次续订订阅时都会创建一个单独的交易。当您的应用程序恢复以前的购买时,Store Kit 会将每笔交易传送到您的应用程序。

假设我的应用程序订阅仅限客户端(无服务器组件)。验证后续续订是否已计费的最简单方法似乎是每月恢复以前的购买。

但是,每次调用 restoreCompletedTransactions 时都会弹出用户的 iTunes 密码提示,这似乎是糟糕的用户体验。是使用服务器收据验证码(以及新的“共享秘密”)的唯一途径吗?

According to the Apple In App Purchase Programming Guide:

The App Store creates a separate transaction each time it renews a subscription. When your application restores previous purchases, Store Kit delivers each transaction to your application.

Let's imagine my app subscription is client-side-only (no server component). The simplest way to verify that subsequent renewals have been billed seems to be restoring previous purchases every month.

However, this pops up the user's iTunes password prompt every time you call restoreCompletedTransactions which seems like bad user experience. Is the only recourse to use the server receipt verification code (along with the new "shared secret")?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

暖伴 2024-10-25 03:18:24

App Store 会调用 paymentQueue 并在每次自动更新时发布交易。交易以 transaction.transactionState==SKPaymentTransactionStateRestored 发布。

问题是不幸的是这仅发布到一台设备。第二台设备未收到该帖子。因此,要检测自动续订,或者更确切地说,要检测缺乏自动续订并拒绝任何设备的持续订阅,您必须执行 RestoreCompletedTransaction 或“http post 包含最后一笔交易的 64 位编码 JSON”。如果是前者,用户需要提供密码;正如你所指出的,这是侵入性的。如果是后者,则需要大量额外的编码。所以,我在回答你的问题时的问题是......为什么 StoreKit 没有命令:(

不存在) - [[SKPaymentQueue defaultQueue] RestoreAttachedTransactions:(NSArray *)transactions];

该命令的流程就像restoreCompletedTransactions 一样,但它只会恢复附加的事务,最重要的是,它不需要用户登录。它具有与“http 发布包含最后一笔交易的 64 位编码 JSON”相同的安全保护,并且允许整个应用内购买流程在 StoreKit 中完成,而不需要 Web 发布代码。

如果这对您有意义,请建议如何将其发送给 Apple...谢谢。

The App Store calls the paymentQueue and posts a transaction each time it auto-renews. The transaction is posted with transaction.transactionState==SKPaymentTransactionStateRestored.

The issue is that unfortunately this gets posted only to one device. A second device does not get the posting. Therefore, to detect the auto-renewal, or rather to detect the lack of an autorenewal and deny any device a continuing subscription, you have to do a restoreCompletedTransaction or "http post a 64-bit encoded JSON containing the last transaction". If the fomer, the user needs to give their password; and as you point out, that's intrusive. If the latter, lots of additional coding is required. So, my question in answering your question is...why doesn't StoreKit have a command:

(does not exist) - [[SKPaymentQueue defaultQueue] restoreAttachedTransactions:(NSArray *)transactions];

This command would flow just like a restoreCompletedTransactions but it would only restore the attached transactions and, most importantly, it would not require log-in by the user. It has the same security protection as the "http post a 64-bit encoded JSON containing the last transaction" and it allows the entire In App Purchase process to be done in StoreKit rather than requiring web posting code.

If this makes sense to you, please suggest how to get this to Apple....thanks.

携君以终年 2024-10-25 03:18:24

如果您没有服务器组件,则可以存储此信息的唯一位置是本地文件/数据库/配置中。restoreCompletedTransactions

选项用于当本地数据库出现问题时,您应该在高级设置上的某个位置放置一个按钮面板恢复所有以前的交易。

因此,您必须信任本地存储的数据。通常,这是安全的,因为您无法更改本地文件系统(除非您越狱)。如果您不想那样信任您的用户,您可以选择对其进行加密...

If you have no server component, the only place you can store this information is in a local file/database/config

The restoreCompletedTransactions option is there for when there is something wrong with your local database, you should put a button somewhere on your advanced settings panel to restore all previous transactions.

So, you will have to trust the data you store locally. Normally, this is safe as you cannot change your local filesystem (unless you jailbreak). If you don't want to trust your users like that, you can optionally encrypt it...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文