I am having the below queries on implementing the in-app purchase.Actually my content is Songs which totally contains 500 nos.Can i offer this content via non renewing subscription.
Also is there any restrictions to offer content via Non renewing subscription? is there any rules like contents which are periodically updated only can use non renewing subscription?
It is really confusing me , Please let me know.
Thanks a lot
I don't think there is any limitation for Non-renewing subscriptions. Its based on how you providing your service. Spotify is a perfect example for your scenario.
But as a user think of that i purchased a set of 500 songs which should be renewed in 30days? I would rather prefer Non-consumable IAP.
Related
I have Iphone application in which i wanted to use Non_Renewable subscriptions.As per docs MKstorekit supports Non Renewable subscriptions.But everywhere saying about Auto_renewables only.Can anybody knows how to implement Non-renewable subscription with MKstorekit4.I have been googling for the entire day.But with no luck.Can anybody help me ?Was anybody done this kind of in app with mkstorekit?
In non renewing subscriptions we need to use the server tracking .In non renewing subscriptions you will get a receipt data containing some purchase details with purchase date,store the receipt in your server and calculate the expiration date from the purchase date and use this server tracking to show your buying view again,you need to store the receipt corresponding with the user details to get this on all the devices the user is using
I have an app which costs $5. I'd like to change this so that the app is free and that users must purchase an auto-renewing subscription to use it. I know how to implement the auto-renewing subscription, but the problem is dealing with users who have already bought the app for $5; I'd like to continue letting these users use my app without a subscription.
The rub is that for privacy reasons I can't store any identifying information on my server which link an account for my app to a specific person (not even UIDID). What I can do is maintain a separate database table which links UIDIDs to subscription purchase receipts which will allow me to know if a user has a subscription.
So my question is, how can I identify users who got my app when it cost $5? I know there's a way to restore in-app purchase receipts, but is there a way to to retrieve a receipt for the initial purchase of the $5 app which I could store on my server?
The poor man's solution is just to mark all current UIDIDs (i.e. the UIDIDs of people who have paid $5) in my server as paid, but then they would have to buy a subscription if they ever wanted to use my app from a different device.
The previously selected answer is outdated. The new answer is that it is possible today with the new receipts that were standardized this year (2013).
The receipt now has two additional fields: original_application_version and original_purchase_date which can be used to detect when a user purchased and therefore be used to guide logic around what users should get what features.
You can see more about 10 minutes in here: http://devstreaming.apple.com/videos/wwdc/2013/308xex4x6ybggtlw4ztv0sg5btp/308/308-SD.mov?dl=1
or if that link dies here: https://developer.apple.com/wwdc/videos/ and search for Using Receipts to Protect Your Digital Sales.
Chaning your business model like this is not very well supported by the App Store.
Your "poor mans" solution is probably one of the best of a poor set of options.
Another one would be to switch to a new app entirely (just a different bundle ID in practice). Anyone using your old app would have paid, regardless of which device they use. Anyone using the "new" app would need a subscription. Obviously you'd lose any reviews and possibly external links that you currently have.
Could it be that Auto-renewal subscription is not supported in all the countries?
When I create a test user from Israel, I receive a message in the application that
"Subscriptions not supported. Automatically renewing subscriptions are not supported in your storefront at this time"
But when I run the same application code and use another test user defined in another country it works fine.
Is there a list of countries for which auto-renewal subscription is supported or
in opposite the countries were it is not supported.
Here is (possibly) the real reason:
As of January 1st 2009, Israeli law does not permit automatic renewal
of subscriptions without explicit notification and consent of the
subscriber.
Here is a link (Hebrew) to an article explaining the law.
I strongly believe Apple took the easy part of just blocking the service instead of enabling notifications.
I totally agree that this is outrageous, since, as an Israeli citizen I cannot subscribe to quite a few electronic publications.
I am not familiar with the proper APIs, but I'm sure there is a way to allow manual renewal and I am also sure Apple will block that as well.
Regards,
Misha
In this page, at the bottom, it says: "Auto-renewing subscriptions are not available in Israel"
gotta love apple.
i'm working on an magazine app for iPad and i've been asked to build a system to allow users to subscribe for, say, a year. I have to say... I didn't quite get the concept of Subscription... Anyway, there's my point: should I implement a real Subscrition model of payment or can I go with a standard consumable one? I mean, if for 20euros I allow the app to download a secret code, say a boolean, which enable the download of all future issues of the year, why should I prefer the subscription model?
thanks to all,
Marcello
There's no need to "build a system to allow users to subscribe" since there is already a subscription billing service offered by Apple:
Apple Launches Subscriptions on the App Store
CUPERTINO, California—February 15, 2011—Apple® today announced a new subscription service available to all publishers of content-based apps on the App Store℠, including magazines, newspapers, video, music, etc. This is the same innovative digital subscription billing service that Apple recently launched with News Corp.’s “The Daily” app.
Security is the main reason you want to use the Subscription service. There are places out there where poorly made apps which have 'secret code' which just needs to be enabled have been pre-packaged which allows people to bypass buying.
Not doing things the right way and coming up with a half-arsed workaround because "you don't quite get it" is hardly a good attitude.
Doing things the right way means that the customer gets billed until they take action to cancel their subscription. It should be obvious why that is preferable to a one-time fee that expires.
Also, Apple may have a problem with you bypassing the method they've provided. There's an entire section on in-app purchases/subscriptions in the review guidelines that you are coming dangerously close to breaking.
The MAIN difference is Apple is responsible to auto-renew subscription every time it expired. So you should go for In-app purchase subscription type.
Sorry for the millionth question about iTunes subscriptions, but I still have a few doubts.
Basically I'm implementing auto-renewable subscriptions in my app and I want to make sure I got it right. Here's a list of steps to take that I came up with:
whenever an user buys a subscription, send the receipt to the server to validate it
if the receipt is valid, save it on the database
on application load, ask the server if a receipt for this UDID exists (this is to figure out if the user has a valid subscription)
if so, check if a new item has been added on the store in a date range from the subscription start date to the expire date
if any, notify the user about those items in some way and mark them as freely downloadable
Are these steps correct? And if so, why does the Apple doc say:
In most cases, your iOS client application should not need to change. In fact, your client application is now made simpler, as you can use the same code to recover auto-renewable subscriptions as you do to recover nonconsumable products. This is described in “Restoring Transactions.”Your application receives a separate transaction for each period of time where the subscription was renewed; your application should verify each receipt separately.
To me it looks like this needs some code to handle all the various cases I mentioned, instead. Or I'm totally wrong about it. Am I?
Plus, how do I know about the subscription expiration date? I can't find a way to get this information anywhere. Am I supposed to save this on my own database?
Update:
I've figured out a few things since I posted this question. Feel free to correct me if I'm wrong.
First of all I guess I'm supposed to store the length of the subscription somewhere on my own database, because as stated on Apple's docs, you cannot retrieve it in any way through Apple's web services. In fact, each subscription length has a different product identifier, so you should have a way to convert a product identifier to a subscription length.
Also, Sylvian has posted details about his implementation of auto-renewable subscriptions, so at least I know my thinking wasn't too much flawed.
Now the only problem is this: how do I know that an user has a valid subscription? I could store this information on my server, yeah, but how do I associate an user with a completed transaction? Should I save the device's UDID?
Here is how we implemented In App Purchases and specifically the new auto-renewable products at my company.
The application transmits the transaction receipt to our webservice, we return OK to the application if we handled it correctly and Apple could verify it. In that case we updated the user account (i.e. the database) to say "yes he has paid and his subscription is valid till the receipt expiration date".
After the OK for this webservice, the application reloads the account info through another webservice, and see there is a valid subscription. That was it... Until auto-renewable products appeared.
We now had to implement some CRON jobs which runs every day: every day we make a list of passes which are supposed to expire, and we ask Apple if the original receipt is still valid: the magic thing is that in their answer, there is a field latest-receipt which embeds the latest receipt. If it is not the same as the one we have, we understand that the subscription has been renewed automatically, we store the latest receipt for the next cron check, and we update the user account to extend the expiration date.
Hope it helps.
I think I found a solution. It doesn't require an additional username/password and it seems to be working.
Note: If you think this is inappropriate, please explain why in the comments. Thanks.
Basically, whenever an user buys a subscription, I validate the receipt against my server and store the receipt data in the user defaults. Then, when the app is opened, or whenever I need to check if the subscription is still valid, I retrieve the previously saved receipt data from the user defaults and validate it against the server.
My webservice just returns whether the subscription is still valid or has expired, plus some other related information such as the subscription length. To do this, it just queries the iTunes server as usual, and checks if the status response is nonzero. 21006 means that the subscription has expired.
If your app has some user management i.e. you use username/password to use the app, then you have to maintain a server to record the purchase/validity of the currently logged in user. This is applicable for normal subscription and non-consumable purchase. But... if you use the new auto-renewable subscription, then it's NOT possible to maintain multiple user in that app, because : this kind of purchase can not be done multiple times within the subscription period using the same Apple ID from the same application and I found it really annoying and finding a better solution for this case i.e where I have multiple child account in the app but I want to use the same Apple-Id to purchase a auto-renewable subscription for each account. And I think I have to use the old subscription model. Any new thoughts ?
as far as I have understand it the apple server will contact you (or the customer with his iPhone) and tell "look here I have a valid purchase for you". Inside your App you read this message and unlock the regarding content for use. The next step is to tell the apple server that you have responded to the receipt and the apple server will not show the message again.
So with a renewable subscription you get for each period a new message. Correct me if I'm wrong, please.