I am building an app that offers a 30-day subscription to premium services in the app.
I am familiar with in-app purchases (consumables) and have everything setup up for that. However, I haven't found any good tutorial or explanation of what the proper procedure for validating auto-renewable subscriptions.
Can anyone point me in the right direction?
What I would like to do is have the subscription setup like this:
User purchases in-app subscription and is verified
Subscription End-Date (30 days from purchase) is added to network database with user's account info
How to detect when the subscription is renewed so I can update the network database
UPDATE
So I have figured out the original purchasing and receipt verification, so all good on that. Then getting expired date by getting the value of 'expires_date' from the receipt data.
What I need to accomplish now is the best way to check for ALL completed transactions on app load (including any auto-renewed subscriptions) so I can unlock premium services. Using 'restoreCompletedTransactions' allows me to receive old receipt data, but it forces the user to enter a password, and I would like to avoid this. What are the alternatives?
a user purchases a product and you save the receipt. keep track of a timestamp so you know how long the subscription is valid for. on each launch you validate the receipt. you will always get the latest receipt so you know whether the product was renewed. using the timestamp you can make sure the user doesnt get access after their subscription has cancelled.
Related
I'm working on an iOS app that will use Apple's in-app purchasing framework to let the user create auto-renewing subscriptions.
I want my server to check periodically that none of the subscriptions have expired. Apple's Receipt Validation Programming Guide describes a verifyReceipt web service that appears to validate a single receipt.
However, if I want to bulk-verify my entire database every few days, is there a better way to do that than a storm of individual verifyReceipt calls?
You don't need to need to bulk-verify your entire database. A subscription is valid for a fixed duration. If the user cancels their subscription then this takes effect at the next renewal period, not immediately.
Apple customer service can refund a subscription if a user has a case (wrong product purchase is one example they give) but this would be a pretty low figure - and your app should also check for a valid subscription when it starts.
So you should only need to verify subscriptions that are known to be expiring "today".
To my knowledge there's no way to send multiple receipts in one bulk request to validate them in the iTunes servers... You have to send one by one. (Multiple requests)...
I don't know if how you are planing to solve this is the best approach. Apple has extended documentation on how to handle auto renewal subscriptions, most of the times you check the validity of the subscription in the app itself.
Check the in-app purchase documentation. It's a very good read if you plan to depend on in-app subscriptions for your business model:
https://developer.apple.com/library/ios/technotes/tn2259/_index.html
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've been reading the various threads on in-app purchases auto-renewal subscriptions, and I think I've pieced together most of the information I need, but there are a few missing pieces. I'm hoping someone can help me.
The situation:
I have various subscription packages the user can subscribe to (e.g., package A for £1 a month, package B for £2 a month, etc.). I store the user's subscription information in my database. When the user logs in, I check which package he's on and if it's expired or not. My website, android and iOS all use the same database, hence this approach seems to make sense.
Subscribing users via in-app purchase seems straight forward enough. I check paymentQueue and once the payment is cleared, I can update my database.
My questions:
1) My understanding is the user can use iTunes to manage their subscription. Say, they go in to iTunes and cancel their subscription, how can I be notified so I can update my database? Do I need a daemon that checks expired subscriptions to see if the user renewed?
2) If the user wants to upgrade their subscription from Package A to Package B, how do I handle the pricing? Say on Jan 1st, they buy Package A, I charge them £1.00 and set the expiry date to Jan. 31st. On Jan. 15th, they want to upgrade to package B via in-app purchase. Ideally, I would charge them £2 for Package B minus £0.50 of credit they have for Package A and set the new expiry date to feb 14th. However, Apple forces me to associate each package with a tier price. How can I handle this? I don't want the user to wait until the end of the month to put them on a higher tier package...if they upgraded mid-month, it means they want the new content package B will deliver to them immediately.
Any help appreciated!
Thanks!
1) Yes you'll have to reverify your receipt check out the Receipt Validation Programming Guide in the documentation. They mention some important keys:
status - 0 if receipt is valid, or an error code
receipt - JSON response of the receipt
latest_receipt (auto-renewable only) - base 64 encoded receipt for the most recent renewal
latest_receipt_info - JSON version of latest_receipt
With this information, when a purchase is made, send the receipt to your backend for validation, the backend will keep the receipt in the DB and verify with status = 0 that it's a valid receipt. From there, every x days you can validate that receipt with a chron job, daemon, etc. and reverify. The response back each time will have latest_receipt_info that you now need to save to your DB so you have an up-to-date receipt for the next check in x days. This way you will always have the latest receipt. There is no instant notification for telling when a user cancels a subscription, but with this you'll know every x days if they have the subscription still.
2) Pricing like this unfortunately can't be handled. It was not intended for a user to "upgrade" with subscriptions - each subscription is access to it's own exclusive content as of this writing. However, if a customer emails in and complains about it, you could ask for their user name and figure out in your DB if this user has indeed upgraded mid-month and reimburse them appropriately. Very old-school and not feasible for a big user base, but hopefully you won't have that many and can keep them happy.
EDITED
For the second question, Apple's auto-renewable subscription system does not technically offer upgradeable plans between different products.
Every subscription is a stand alone product and it's up to the user to turn on/off subscriptions manually using the Subscription Manager in the iTunes Store.
However if package A and package B offer the exact same content only different duration than what ajay_nasa said is correct, you can create an single auto-subscription product with different duration options. If the user is on 1 month subscription and then the user tries to change to 2-months subscription they will get the following error message asking them go to the App Store's subscriptions manager
So basically the ONLY place the user can actually change the subscription's length is in the App Store. Whether Apple decide to pro-rate the amount left on the old subscription or just append it to the current one is really up to Apple. You need to make sure the user have access to the subscription as long as it's active by reading the Original Purchase Date and Subscription Expiration Date field from each receipt entry and determining the start and end dates of the subscription.
Answering question 1, you can verify subscription receipts in the same way as other IAP, but you'll need to check it periodically to see if the subscription has expired (the verification will tell you if it's expired).
There is more info on the Apple docs here:
http://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html
Actually, Apple's auto-renewable subscription system does offer upgradeable plans.
To achieve this we simply should add duration in existing Auto-Renewable Subscription. Every Auto-Renewable Subscription could be family of Subscriptions so whenever developer wants to achieve upgradation in subscription he should add duration in existing Auto-Renewable Subscription with different productID.
Whenever, user upgrade his plan in between the month then his upgrade plan will be automatically works from next month.
Answering to your question #1
Recently Apple launched a feature to enable server notification whenever the subscription is renewed. However, the subscription should be in-app.
See the links given below for your reference:
https://help.apple.com/itunes-connect/developer/#/dev0067a330b
&
https://itunespartner.apple.com/en/apps/news/45333106?sc_cid=ITC-AP-ENREC
We Need to Check Cancellation-Date provided in Receipt.
I'm trying to work out the best mechanism to handle the auto renewing part so that it handles the continuation of the subscription into the next period.
What the best way of handling this?
Should I have an NSTimer set to check if the current expires_date has been reached .. and then try send a purchase request?
Apple iOS in-app purchases provides the product "Auto-renewable subscription". This product will be renewed automatically by Apple.
When you use this type of product, your app has to verify if the auto-renewable subscription is still valid, since the user might have cancelled the subscription. When an user cancel a subscription, the subscription remains valid until the end of the subscription period.
To validate an auto-renewable subscription, you have to use the purchase receipt and the shared secret generated for your app in-app purchases in iTunes Connect. You have to post this two things to the App Store. This will return a JSON and you have to get from this data the "
subscription's latest purchase date". From that date you have to calculate the expiration date and validate or invalidate the subscription.
You can do all this validation after application launch and/or when the model is updated.
Additional information
You can find information about auto-renewable subscription in Apple documentation. Also, you can check about MKStoreKit, which is a framework that reduces the amount of code that you have to write for the use of StoreKit, and supports Auto-renewable subscriptions.
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