Currently, we want to implement auto-renewable subscriptions on iOS. We face a problem where users can purchase multiple subscriptions on a single Apple ID linked to the device. We are having 3 subscription plans as Regular (Monthly), Regular (Yearly), and Special (Yearly). Now, we have decided that Regular plans will be configured in a separate subscription group and special plan on the other since we don't want the Regular users to know that there is a special plan that is less costly than theirs. (Through Manage Subscription Settings on the device)
Scenario 1: If User A subscribes to the Special plan on his Apple Id, his subscription gets active. Now, if on the same Apple ID, user B logs in to the app and is a Regular user then he can purchase any of the Regular plans. But the issue is User A's receipt and User B's receipt cause problems sometime later since their receipts are created on the same Apple ID. We are not able to restrict User B to purchase from User A's device in this case, since the original_transaction_id of the subscription are different as they are from the different subscription groups.
Scenario 2: If we do keep both the Special and Regular subscription plans in the same group, we don't want the regular users to get access to the Special plan as it is cheaper and will affect the profit that we get.
Has anyone come across these scenarios, what would be the ideal way to handle these scenarios?
Related
Our app was rejected in App Store because we were using 3rd party solution for subscription and was decided to use In-App Purchases ( Auto-Renewable Subscriptions). I went through several tutorials and it seems that the subscription has to be created in App Store Connect and only then it will be available to use in app and that's the problem for us.
Our app is something like news app where user can subscribe to some author. List of authors comes from server therefore hardcode every subscription for each author is not the way to go.
So, Is that possible to somehow implement what I want with In-App Purchases? Thanks.
There is no option to create subscription dynamically. Your case is a draw back of iOS subscription platform. I have pointed out this problem to Apple subscription team but they were not ready to accept this and forced us to implement in-app subscription, so we had to restrict the number of subscription in app.
Only possible option is to create a number of subscription groups, lets say 10 groups representing each author.
authorSusbcription1,authorSusbcription2,...authorSusbcription10
I know it's not a viable solution since the number of authors is indefinite. But we don't have any option as of now. You can restrict 10 authors subscription in the app and then prompt users to buy from website if it's exceeds 10.You can show some alert that doesn't violate the in-app rule. For example, "Further subscription is not available in this app" instead of mentioning about your website. Track this user and use an API to send an email to this user asking to subscribe via website.
Unless Apple fix this drawback, we have no other options..!
Dynamic Auto-Renewable Subscriptions creation (and dynamic in-app purchase creation in general) is not possible. Alternatives would be to sell credits to authors (but this is non-auto renewable). Another possibility is to sell tiers of subscriptions that grant access to a number of authors.
I'm currently building an iOS app which includes auto-renewing subscriptions via iTunes. I also provide a secondary subscription service via Stripe for web users, and a subscription on either platform enables premium features for all platforms.
A subscription is therefore tied to the user account in my backend database. I don't particularly care what device they are on.
One problem I am envisaging is that if a user creates a second account on my service, and presses restore purchase in the app, the subscription according to apple must be given. As far as I can tell, showing error such as "You're subscription is already active on another account" would not be allowed.
So I was wondering, instead of rejecting the subscription, can I instead transfer it? Something like this flow:
User creates an account aaa#foo.com
User pays for subscription on aaa#foo.com
User signs out and creates a second account zzz#foo.com
User presses "restore purchases"
Backend transfers the subscription from aaa#foo.com to zzz#foo.com.
User signs out of zzz#foo.com and back in to aaa#foo.com. The first account is no longer "premium", as the second one has the subscription.
Would this be an acceptable approach to take?
Well, in the Apple guideline is not clear enough to know if your option is good. But I think it would be a good option because like that you are allowing user to get their subscription on all of their device as if they use their good account
3.1.2(a) Permissible uses: If you offer an auto-renewing subscription, you must provide ongoing value to the customer, and the subscription period must last at least seven days and be available across all of the user’s devices. While the following list is not exhaustive, examples of appropriate subscriptions include: new game levels; episodic content; multi-player support; apps that offer consistent, substantive updates; access to large collections of, or continually updated, media content; software as a service (“SAAS”); and cloud support. In addition:
Subscriptions may be offered alongside a la carte offerings (e.g. you may offer a subscription to an entire library of films as well the purchase or rental of a single movie).
You may offer a single subscription that is shared across your own apps and services, but these subscriptions may not extend to third party apps or services. Games offered in a game subscription must be owned or exclusively licensed by the developer (e.g. not part of a game publishing platform). Each game must be downloaded directly from the App Store, must be designed to avoid duplicate payment by a subscriber, and should not disadvantage non-subscriber customers.
Subscriptions must work on all of the user’s devices where the app is available. Learn more about sharing a subscription across your apps.
Apps must not force users to rate the app, review the app, download other apps, or other similar actions in order to access functionality, content, or use of the app.
As with all apps, those offering subscriptions should allow a user to get what they’ve paid for without performing additional tasks, such as posting on social media, uploading contacts, checking in to the app a certain number of times, etc.
Subscriptions may include consumable credits, gems, in-game currencies, etc., and you may offer subscriptions that include access to discounted consumable goods (e.g. a platinum membership that exposes gem-packs for a reduced price).
If you are changing your existing app to a subscription-based business model, you should not take away the primary functionality existing users have already paid for. For example, let customers who have already purchased a “full game unlock” continue to access the full game after you introduce a subscription model for new customers.
Apple Review Guideline
I'm implementing an application with Non-Renewal Subscriptions. For that i have referred many sites and most of the answers that i found as like,
We need to manage the expire date by ourself in our server side/local, once you verify a receipt with Apple.
We can implement authentication module as optional to share use the Non-Renewal Subscriptions across multiple devices.
Actually my application doesn't have authentication modules like registration/login to track user on multiple devices. So How can i able to use the Non-Renewable in multiple devices without allowing user to register/login. Do we have any common field to trace the user on multiple devices without authenticating them.
Thanks in advance, Can anyone please give any suggestions to handle this scenario.
You will need some server side support. If you are fine with receiving unauthenticated traffic, you can use the original transaction id. For each subscription purchase you make for a given Apple Id, that purchase will have a unique original transaction id (in the receipt).
If the user initially purchases the subscription on device A, let's say they get back a transaction id of 1234 (note this is not the format, I am just using this as an example). Now the user goes to device B and makes the same purchase. Note this is a subscription, so Apple will already know the purchase was made for that Apple Id. It will indicate the subscription was already purchased, but will let the person still "purchase" (they won't be charged). Upon this, they will get a receipt. This receipt will have the same transaction id.
So here is where your server would need to tie the two together. You would most likely use a UUID, such as [[UIDevice currentDevice] identifierForVendor]. Now your server will know that transaction id 1234 is used by device A and device B.
You can choose how to send this information. You can either send it by way of the receipt (in which case your server will need to unpack it to get the transaction id) or the app can do it for you.
You should do what you can to increase security measures. For example, the method above could be easily spoofed.
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:
We have some doubts how we can manage the subscription in our iOS application?
How device settings options will show our 4 In App Purchase options for upgrading and degrading form one option to other?
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?
Apple will reject custom family sharing option using auto renewable subscription option?
What are the points we need to take care at our end which apple will not handle if we can go with above features?
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
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.
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.
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.
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.
What are the points we need to take care at our end which apple will not handle if we can go with above features?
You need your own API with user management and family association
Your users need to sign-in/register on your app
You will need to prevent family users from purchasing if their parent account already has a purchase.
Persist receipts and the identifierForVendor in the database.
Handle receipt validations using the validation API.
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.
Validate the receipt each time a transaction is due for renewal.
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.
I am completely new to In App Purchases and need to implement a subscription based IAP to grant user access to my app on login.
My app contains two types of users:
Regular user
Business user
In my business user table, I plan to have a column for subscriptionPaid which holds a boolean value and another column for the expDate.
At a high level, my plan is to update these two columns every time a user renews their subscription. Then, when a business user logs in, in addition to checking username and password, I need to check if the subscriptionPaid bool is true.
I had a quick look but I'm wondering if there are events which are triggered when renewals occur whereby I can call my own webservice to update the subscriptionPaid col and the expDate col in my business user table? Is this the best way of implementing such a process?
I know in Android, there is a method getPurchases which a programmer could potentially call on login to my app and then if there is an active one for my app, I will call my update script there to update the subscriptionPaid and expDate fields in my DB. I will be coding in swift, so would need some swift equivalent of the android getPurchases if this option is a better choice?
And finally, Apple can be very strict at times so I am wondering if anyone has any experience or opinion on whether or not what I have described thus far, would fit the following criteria:
Auto-renewable subscriptions. Episodic content. Like non-consumable products, auto-renewable subscriptions remain available to the user indefinitely on all of the user’s devices. Unlike non-consumable products, auto-renewable subscriptions have an expiration date. You deliver new content regularly, and users get access to content published during the time period their subscription is active. When an
auto-renewable subscription is about to expire, the system automatically renews it on the user’s behalf.
This is the type of product I need. See all options below:
https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnectInAppPurchase_Guide/Chapters/CreatingInAppPurchaseProducts.html