I'm having in-app purchase subscriptions in my app. I'm able to integrate and make subscriptions successfully. There are 3 different subscriptions, monthly, quarter and yearly.
So if user subscribes to monthly user can use that feature for 30 days. There's no server in my case. Only availability of some features will be activated/deactivated according to subscription.
When ever the app starts, i want to check whether user paid for subscription or not. If I'm maintaining some bool value in subscriptions, what if the user has deactivated the subscriptions from settings? How can I detect whether the subscriptions are valid or not?
You can add counter and add that counter value in a database that must be inside your app. Whenever user tries to access subscriptions you can verify from the database.
You have to post the receipt back to apple server and from the response we receive, we can identify the expiry date. Then I'll know whether the subscription is expired or renewed etc.
Visit Apple documentation
Related
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
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.
I am implementing a sample which includes the in-app purchase feature. The subscription is of non-renewal type.
In case of auto-renewal subscription, if the user has made a purchase, and within the validity period if the user retries to make the purchase, the iTunes shows the alert that
You are already subscribed to the purchase
and won't proceed further. The user can restore his subscription using the app restore feature.
But in case of non-renewal subscription type, if a user has made a purchase, and within the validity period if the user retries to make the purchase, the iTunes shows a confirmation alert that
You have already purchased the subscription, to renew or extend the
subscription press buy or press cancel
and if the user presses buy it proceeds further.
So, my doubt is what exactly happens in the later case (non-renewal repeated subscription).
Is the user again charged?
What happens with the user's subscription validity?
Can it be handled and controlled inside the code by me?
In case yes, any idea to proceed with would be highly appreciated and will be very helpful for me.
Thanks in Advance.
For Apple, there is no "within the validity period" for non-renewing subscriptions. The duration of the period, fortunately or unfortunately, is left up to the developer.
Yes, when the user buys a non-renewing subscription a second (or third, etc) time, the are charged again.
Subscription validity is up to the developer.
It seems common for developers to use their own server to track the expiry period of a non-renewing subscription. For example, this helps with the "restore" feature required by Apple.
You can alter the subscription start date from the day of repurchase of the APP. This will enable extended validity.
This validity extension mechanism also serves when the user realizes his subscription is about to expire and renews it before hand rather than letting the subscription end.
From the development perspective, logging the first subscribed time along with the current sub and expire time would serve the purpose.
Yes i am altering the subscription start date obviously, and i am getting this from the transaction. According to this subscription start date i am altering the expiry date as well.
The concern here is to avoid the user from getting charged again in any case if he has already subscribed. And, for that i am using iCloud to support restore functionality in user's multiple devices.
I need to build an app for a system, which already has a subscription on its website. It looks like Apple doesn't allow to use any own subscriptions and forces to integrate any app with iOS in-app subscriptions.
Is it any way to integrate two subscription systems? The main problem is that users can manage iOS subscriptions via iTunes and I can't find whether it's possible to get information about this and to stop subscription in the existing system if it's stopped via iTunes.
So is it possible to get notifications about unsubscribed iTunes users?
Using third party subscriptions
First off, it is possible to support an existing subscription system in your app, but it must be in addition to the App Store subscriptions. Also you have to be very careful about the UI you use. You can't prompt users to bypass the App Store and purchase through your server, but you can offer existing subscribers the ability to sign in with credentials they may have previously obtained through your website.
That said, Apple can be fairly capricious in their rulings on what is and isn't allowed in the App Store. I have worked on apps that have done this sort of thing, but they have been for fairly well known magazine publications. There's no guarantee that they will allow it for everyone.
Detecting unsubscribed App Store subscriptions
As for using App Store subscriptions, when a user purchases a subscription in your app, they will receive a receipt in the SKPaymentTransaction object. This receipt should be posted to your backend server to make sure it is valid before you give the user access to anything. See the In-App Purchase Programming Guide for more details.
When you setup a subscription type, you specify how long that subscription lasts. So if you log the transaction date in the SKPaymentTransaction when you receive a receipt, you can determine exactly when that subscription should expire by adding the duration of the subscription to the transaction date.
If it's an auto-renewing subscription, you will receive a new receipt when the subscription is renewed. So once you have validated that with your backend server, you can update your expiry date based on the new transaction date. If you don't receive a new receipt before the first one expires, it's likely the user has cancelled their subscription.
On the backend, your server can also tell when a particular subscription will expire based on the response from the verification server. First there is the status code which will tell you whether the subscription has already expired, but there is also an expiry date returned in the decoded receipt which will tell you when it is expected to expire if it hasn't already.
For more details, see the Auto-Renewable Subscriptions documentation.
Testing auto-renewing subscriptions
It's worth noting that when you are testing auto-renewing subscriptions in the App Store sandbox environment, the length of the various subscription types is dramatically shortened to make it easier to test. For example a 1 week subscription lasts only 3 minutes in the sandbox environment. You can see the full list of times in the iTunes Connect Developer Guide.
So you want the people that have bought the service from the website to be able to use the app, exactly like if they had purchased it from in App Purchases and in App Purchases people to be able to join the service just like people that joined through the site? As far as I know, Apple doesn't allow you to pay through other services as you said, but let's say someone buys the service from the app. What should happen would be that the money will be transferred to the company. Then after the payment you should include some code doing what the site does after a new person has payed for the service, so create his account as a paid account. Then, the app should also have a login screen where the registered users (no matter where they registered from) will be able to login into the app and use the service. Now the problem is indeed that if the subscription is stopped through iTunes you would never know, though a way around this would be to make a check in the server of this company which should monitor the income coming from one account. Then if this user has stopped paying (or stopped the subscription) you would be able to stop the service from the app. And you should recheck the server for payment after the duration of the subscription has passed, let's say a weekly subscription should be checked every week. (Sorry I would do this a comment but I haven't got enough reputation for this)
I am looking to build a ios application that will use an auto-renewable subscription on a monthly biases. We will be using some VOIP features that we will be charged monthly for. My question is, how can we be notified when a user cancels a subscription in IOS, so that we can cancel the users VOIP telephone number with our provider.
You will need to verify the receipt the same way you do for regular In App Purchases, but obviously you will do this every time the subscription period expires. Check out the documentation on this, Verifying an Auto-renewable Subscription Receipt
So based on this, it appears you will need to setup your server to check for a valid subscription every month (cron job?). This will allow you to cancel the VOIP number in your system if the subscription is no longer valid. Your app would be responsible for verifying a subscription is still valid when it is opened or the user attempts to access features that require a subscription.
Updated For Comment
The sandbox is supposed to return expiration dates in the following scheme.
This is from page 164 of the iTunes Connect Developer Guide
If it is not working this way you may want to file a bug report.
Also, please not the following from Apples IAP doc:
Additionally, a sandbox subscription will only autorenew a maximum of 6 times. After the subscription has auto-renewed 6 times, it will no longer renew in the sandbox.