iOS：在App Purchase中管理多个具有升级和低级选项的自动续订订阅 [英] iOS: In App Purchase managing multiple auto-renewable subscriptions with upgrade and down grade option

问题描述

我们正在开发一款适用于iPhone的iOS应用程序，该应用程序将免费提供功能，应用程序将具有4种应用程序购买自动续订订阅选项的高级功能，如下所示：

• 单月订阅


• 单年订阅


• 家庭每月订阅


• 家庭年度订阅

我们将在应用程序内部有一个商店屏幕，可以选择订阅我们的应用程序提供的各种订阅。

我们发现用户可以进入设备设置并管理他们的应用内购买订阅。

我们还在筹划提供用户可以从一个订阅升级到另一个订阅的选项，用户也应该能够降低他们的订阅等级，这将是相反的所有选项并返回到免费版本
可能的升级选项：

• 免费提供任意4个订阅选项


• 每月单身至单身


• 每月一次到家庭每月一次


• 每月一次到家庭每年一次


• 家庭每月每月到家庭

可能的降级评分选项：

• 家庭每年每月到家庭


• 家庭每年一个月到一个月


• 家庭每月到单月


• 每年一次到单月


• 从任意4个订阅选项到免费版

注意：

• 根据Apple的说法我们不能使用Apple家庭共享选项分享In App购买，所以我们是在申请中开发我们自己的家庭共享选项。 （参考： https://support.apple.com/en-in/HT203046 ）

查询：

1. 我们对如何管理iOS应用程序中的订阅有一些疑问？


2. 设备设置选项如何显示我们的4 In App Purchase选项，用于升级和降级，形成一个选项其他？


3. 作为iOS开发人员恢复自动续订订阅，我们需要注意什么？如果用户试图在我们的应用程序中使用具有多个用户帐户的iTunes帐户进行恢复，我们不清楚可能的情况，当用户购买订阅一次并尝试恢复多个用户帐户时，苹果允许哪些预防措施？


4. Apple会拒绝使用自动续订订阅选项的自定义家庭共享选项吗？


5. 我们需要注意哪些要点，苹果将如果我们可以使用上述功能，请不要处理？


6. 如果我们使用iOS应用程序的上述功能，违反苹果指南和应用拒绝的可能性有多大？

如果任何人可以分享他们的观点或提供我们应该采取的方式或者我们正在偏离苹果政策....所有这些反馈将帮助我们让事情在这里移动。

谢谢

决方案

1. 我们对如何在iOS应用程序中管理订阅有疑问？

因为您使用的是自己的用户管理系统，所以应该在数据库中保留与用户关联的订阅状态。当用户在应用中创建购买时，应用应将此收据发送到您的API，然后继续验证它。

一旦持久化，将计划进程排入订阅到期日期无限更新记录和广告，直到过期日期不再存在。

当用户打开应用程序确定订阅时，您的应用应查询您的API状态。不要依赖应用程序本地收据，因为您的用户的家庭成员设备不会关联此购买。

2. 设备设置选项如何显示我们用于升级和降级的4个In App Purchase选项，将一个选项显示给其他选项？

如果iTunes Connect中列出的所有产品都是相同的订阅系列，它们将显示在用户iTunes帐户的订阅管理页面中。

当用户在产品之间切换时，将创建一个交易，并将 SKPaymentTransactionStatePurchased 事件添加到 SKPaymentQueue 。这将是一个具有相同的新交易原始交易标识符是使用来自同一订阅系列的产品进行的首次购买，其中产品标识符反映新产品。

因此，您希望您的应用中的交易观察者在后台运行以接收任何新交易。收到新交易后，您可以a）将整个收据发送给您的API，或者b）通知您的API已收到新的交易，并重新验证已保留的收据。

与（a）一起使用可能会出现问题，因为收据会随着时间的推移变大，每次都需要更多的带宽。

一起去（b） ）也有它的缺点，因为你可以遇到像用户切换iTunes帐户等边缘情况的麻烦。解决方案是存储应用程序 identifierForVendor ，如果不匹配，则要求应用程序发送整个收据。大多数情况下，您只是通知API发生了交易，并且在少数情况下，标识符不匹配，它将发送新的收据。

< blockquote>

3. 作为iOS开发人员恢复自动续订订阅，我们需要考虑什么？如果用户试图在我们的应用程序中使用具有多个用户帐户的iTunes帐户进行恢复，我们不清楚可能的情况，当用户购买订阅一次并尝试恢复多个用户帐户时，苹果允许哪些预防措施？

恢复时，将创建一个具有新交易ID的新交易，即原始交易ID虽然会是一样的。如果在数据库中创建事务表，则可以确保事务，并且它的原始事务仅与单个用户关联，从而阻止用户在具有不同用户的其他设备上恢复购买并获得对订阅的访问权。

使用 SKPaymentTransactionStateRestored 将已恢复的交易推送到队列中，因此，当发生这种情况时，我建议将收据发送到您的API并正常处理收据;将任何新交易与原始用户相关联。

4. Apple将拒绝自定义系列共享选项使用自动续订订阅选项？

我对此表示怀疑，但我不是Apple所以不要用我的话来传福音。 Spotify有一个名为 Spotify Family 用户可以与家人分享他们的Spotify帐户，但不确定是否已为其iTunes应用程序启用此功能。

5. 如果我们可以使用上述功能，我们需要注意哪些点苹果将无法处理？

1. 您需要自己的API以及用户管理和家庭关联


2. 您的用户需要在您的应用上登录/注册


3. 如果他们的父帐户已经购买，您将需要阻止家庭用户购买。


4. 在数据库中保留收据和identifierForVendor。


5. 使用验证API 。


6. 保留一个事务表，并将此表视为自引用，以便事务可以属于原始交易通过 original_transaction_id 。确保 transaction_id 列是唯一的。


7. 每次交易到期时都要验证收据。

6. 如果我们有违反苹果指南和应用拒绝的可能性使用iOS应用程序的上述功能？

我在指南除了 17.2 ：

要求用户共享个人信息的应用程序（如电子邮件地址和出生日期）才能被拒绝

我认为这个有点矛盾，因为在 17.5 中它表明：

包含帐户注册或访问用户现有帐户的应用必须包含隐私政策o r他们将被拒绝

我想这意味着用户必须能够使用该应用程序而无需注册，但我知道许多应用程序的例子。

We are developing one iOS application for iPhone which will free features as well app will have premium features with 4 in app purchase auto-renewable subscription options as below:

• Single monthly subscription
• Single yearly subscription
• Family monthly subscription
• Family yearly subscription

We will have one store screen inside the application which will have options to subscribe to various subscriptions which our app provides.

We found that user can go to device settings and manage their In-app purchase subscriptions.

We are also planning to provide options like user can upgrade from one subscription to other and user should also be able to down grade their subscription which would be all of the same options in reverse and back to the free version Possible upgrading option:

• Free to Any 4 subscription options
• Single monthly to single yearly
• Single monthly to family monthly
• Single monthly to family yearly
• Family monthly to family yearly

Possible down grading options:

• Family yearly to family monthly
• Family yearly to single monthly
• Family monthly to single monthly
• Single yearly to single monthly
• From any 4 subscription options to Free version

Note:

• According to Apple we can not use Apple family sharing option to share In App purchases so we are developing our own family sharing option in application. (Reference: https://support.apple.com/en-in/HT203046)

Queries:

1. We have some doubts how we can manage the subscription in our iOS application?
2. How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?
3. What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?
4. Apple will reject custom family sharing option using auto renewable subscription option?
5. What are the points we need to take care at our end which apple will not handle if we can go with above features?
6. What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?

It will be great help to us if any one can share their views or provide some guidance on which way we should go or if we are going off track from the apple policy.... all those kind of your feedback will help us to get things moving over here.

Thanks

解决方案

1. We have some doubts how we can manage the subscription in our iOS application?

Because you are using your own user management system, you should persist the state of a subscription associated to the user in your database. When the user creates a purchase in the app, the app should send this receipt on to your API which will then proceed to validate it.

Once persisted, enqueue a scheduled process to run on the Subscription Expiration Date to update the record and ad infinitum until the expiration date is no longer in the future.

Your app should query your API when the user opens the app to determine their subscription status. Don't rely on the receipt locally in the app as your user's family member devices will not have this purchase associated.

2. How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?

If all products listed in iTunes Connect are of the same "Subscription Family", they will appear in the Subscription Management page in the users iTunes account.

When a user switches between products a transaction will be created and a SKPaymentTransactionStatePurchased event will be added to the SKPaymentQueue. This will be a new transaction with the same Original Transaction Identifier as the first purchase made with a product from the same Subscription Family with the Product Identifier reflecting the new product.

For this reason, you want to have your transaction observer in your app running in the background to receive any new transactions. When a new transaction is received you can either a) send the whole receipt to your API or b) inform your API that a new transaction has been received and re-validate the receipt that was persisted.

Going with (a) may become problematic as the receipts will become larger over time requiring more bandwidth from the user each time.

Going with (b) also has it's drawbacks because you can get into trouble with edge cases like the user switching iTunes accounts. A solution for this is to store the apps identifierForVendor with the receipt, and require the app to send the whole receipt if it does not match. Most of the time you will just be informing the API that a transaction has occurred, and on the few occasions that the identifier doesn't match it will send along a new receipt.

3. What are the consideration we need to task care as an iOS developer for restoring the auto renewable subscription? we are not clear with the possible scenario if user try to restore using iTunes account with multiple user accounts in our app, what are the preventions we can take care which apple allows while user buy subscription one time and try to restore on multiple user account?

When restoring, a new transaction with a new transaction ID will be created, the original transaction ID will be the same though. If you create a transactions table in your database, you can ensure a transaction and it's original transaction is only ever associated to a single user, thus preventing users restoring purchases on other devices with a different user and gaining access to the subscription.

A restored transaction will be pushed onto the queue with SKPaymentTransactionStateRestored and so when this happens simply I advise sending the receipt to your API and process the receipt normally; associating any new transactions to the original user.

4. Apple will reject custom family sharing option using auto renewable subscription option?

I doubt it, but I am not Apple so don't take my word for gospel. Spotify have a similar scheme called "Spotify Family" where a user can share their Spotify account with their family, not sure if this is enabled for their iTunes app though.

5. What are the points we need to take care at our end which apple will not handle if we can go with above features?

1. You need your own API with user management and family association
2. Your users need to sign-in/register on your app
3. You will need to prevent family users from purchasing if their parent account already has a purchase.
4. Persist receipts and the identifierForVendor in the database.
5. Handle receipt validations using the validation API.
6. Persist a table of transactions and consider this table self-referential so that a transaction can belong to an original transaction through the original_transaction_id. Ensure the transaction_id column is unique.
7. Validate the receipt each time a transaction is due for renewal.

6. What are the possibilities of violating the apple guidelines and app rejection if we are going with above features with iOS application?

I see nothing in the guidelines except for section 17.2:

Apps that require users to share personal information, such as email address and date of birth, in order to function will be rejected

I think this one is a little contradictory, since in 17.5 it states:

Apps that include account registration or access a user’s existing account must include a privacy policy or they will be rejected

I guess by this, it means a user must be able to use the app without requiring registration, but I know of many examples of apps that do exactly this.

这篇关于iOS：在App Purchase中管理多个具有升级和低级选项的自动续订订阅的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！