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
Related
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?
I am implementing In-App Purchases first time in my application and new to In-app purchases Store Kit.
I have few doubts regarding In-app purchases:
What happens if a user purchased a subscription and logged out from the application and another user logs in and trying to purchase the same?
Does iTunes allow the second user to use the First user's purchased product?
If it allows how can we handle the second user's subscription?
What details we will get post Successful/Failed transactions from itunes to save in my database?
For a non-renewing subscription then it is entirely up to you to track expiration and determine what content a user has access to and when.
For example, say your subscription gave access to "the word of the day". If the subscription was active for the month of January, then the user would receive access to new words each day in January. The user should continue to be able to see January's words even after the subscription expires, but no new words.
If they resubscribe in March then they would now get new words throughout March.
You need to track all of this on your server against the user account.
Non-renewable subscription IAPs act much like consumable IAPs. The "Restore purchases" Store Kit function does not restore non-renewable IAP items.
To answer your specific questions:
If a new user logs in to your account system in the app (but the same iTunes account is still active on the device) then a second purchase will succeed and you need to update the subscription start and end dates for the new active account on your server.
You also need to cater for the following:
- The original account logs back in; In this case the original subscription entitlements need to be available
- The original or second account log in to another device; Again, the accounts subscription entitlements need to be available.
No, since non-renewing subscriptions are not restorable, the second user cannot "use" the first user's subscription.
You handle each account in your system independently.
Information about the mechanics of the purchase process are described in the In App Purchase Programming Guide
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 developing an app which requires auto renew subscription monthly and I want to maintain that on per user basis who logged into my app. is it possible anyhow with in app purchase. Also how can we handle cancelation of subscriptions ?
I want to maintain all this on my own server.
In the StoreKit documentation, it mentioned in Cancellation section:
A subscription is paid for in full when it’s purchased and can be
refunded only by contacting Apple customer service. For example, if
the user accidentally buys the wrong product, customer support can
cancel the subscription and issue a refund. It’s not possible for
customers to change their mind in the middle of a subscription period
and decide they don’t want to pay for the rest of the subscription.
To check whether a purchase has been canceled, look for the
Cancellation Date field in the receipt. If the field has a date in it,
regardless of the subscription’s expiration date, the purchase has
been canceled—treat a canceled receipt the same as if no purchase had
ever been made.
Depending on the type of product, you may be able to check only the
currently active subscription, or you may need to check all past
subscriptions. For example, a magazine app would need to check all
past subscriptions to determine which issues the user had access to.
Bear in mind that users can cancel the subscription anytime without opening your App. Therefore, you have to check the status of subscription every time the user logs into your App.
Sorry but I am bit confuse on implementing non renewable subscriptions.
Basic concept of app is user can post item to sell within the app. For each item to post he has to pay $.99. This item will remains there for 20 days.
As per apple documentation this kind of In App Purchase should be non renewable subscription with expiration logic to be implemented on Server side. I am done with everything like creating non-renewable IAP and integrating with app. Server maintains the expiration for each item.
Now my query is since user can post as many item he wants, how should the IAP ids should be maintain.
User Case #1:
- User A posted one item after he pay $.99 for that. So far so good.
- When he try to post next item, he is shown with the message "You have already purchase this, tap to renew or extend it" instead it should be something "Do you want to buy one xxx for $0.99"
Am I missing something here?
Use Case #2: Now say item is expired (after 20 days), For renewing shall I use the same IAP id (Product ID in IAP) to renew? or I need to create different IAP id?
Please guide me on this so that Apple shall not reject the app.
Thanks in advance!!
OK I used following:
non renewable subscription with expiration logic implemented on Server side.
Same Product ID works for me for Buying for first time and renewing after 20 days expiration.
And application got approved!
What I would suggest to you would be using Consummable in-app purchases.
Once the user owns the purchase, manage on your side how long should the registration last (server-side if the user has an account or NSUserDefaults if everything is local).
Once the subscription time is Over, just lock the functionality. During the subscription time, you can either disable the purchase button, or let them own new ones and stack the durations :)
As stated above, I would like to recommend consumable in-app. You have to maintain a database based on post id and date of purchase when user purchases a post.
You'll have to maintain this database such that it can be restorable for example if still 5 days are remaining. So user will be happy.
To maintain this data you can use your server if you have, or else you can use iCloud, any way this is a simple data sheet. Or you can use any third party library which gives free cloud storage.
Last but not least you can save locally, but I would recommend server, iCloud method. So users can restore their purchases.
So this way you can handle multiple subscription logically.