I'm working on an app that will provide data from a web server to users but only if they've bought an in app purchase subscription. I understand the basics of IAPs but how do I securely make sure the data from the server is only accessible to the app, and only if the subscription has been purchased? I don't want to make the user set up an account, I just want to auth the app/purchase securely.
Thanks in advance :)
I'm going to use subscription model too with IAP.
AFAIK, you SHOULD NOT use a unique phone identifier like the IMEI of the phone to identify the user on your server. According to the Apple documentation, you MUST provide a way so that an user can restore his subscriptions on several devices!
Besides, a call to restoreCompletedTransactions of the SKPaymentQueue will restore ONLY nonconsumable products! Subscriptions are not supported by this method.
See these links :
http://developer.apple.com/library/ios/#technotes/tn2009/tn2259.html (section « Frequently Asked Questions », point 10)
iPhone - How to recognize the iTunes user of my app
The only way I know is to use a login/password to identify the user on the web server but this could be quite ugly...
However, if someone know another way, could he describe his solution ?
You should upload store receipts to your server, to be able to check them on Apple's site. And, with request you should upload phone identifier. And, of course, store somewhere in the database. After all, you will have information about which phone id has access to subscription.
And, when you will request subscription-related info from your server, you'll be able to check who has acces (via phone id) and who hasn't.
Related
As the documentation says:
queryPurchaseHistoryAsync():
Returns the most recent purchase made by the user for each SKU, even if that purchase is expired, canceled, or consumed.
So lets say I would like to make an IAP for the user to remove Ads forever from my app.
How do I decide with a fresh install if that user already purchased that IAP if this function also returns the "canceled" IAPS?
I would like to query the actually purchased IAPS, not everything. Becuase that way a user could unlock the Ad free version with a cancelled IAP.
To make it worse, the Purchase class doesn't have status like "cancelled" or "consumed" I cannot decide the state of the user's purchased IAPS.
Am I missing something here?
Thanks in advance
The billing client documentation states it checks for the user.
Then we have the question: Who is the user
If you look at the steps taken for the billing api on https://developer.android.com/google/play/billing/billing_library_overview then you see that a connection to google play is needed.
What happens then is that the current user on android, the account they are signed in with on google play and their mobile device is determined to be the user.
So if they purchased it via google play in app, it will always be assigned to that user on google play and that is what's being queried by this. No matter on which device they are logged in, Their tablet, smartwatch, phone, television, etc...
How to get a list of actually bought products
Instead of using async that gives you everything included abandoned shopping carts I suggest you use https://developer.android.com/reference/com/android/billingclient/api/BillingClient#querypurchases
That way Get purchases details for all the items actually bought and paid within your app. This method uses a cache of Google Play Store app without initiating a network request.
Note: It's recommended for security purposes to go through purchases
verification on your backend (if you have one) by calling the
following API:
https://developers.google.com/android-publisher/api-ref/purchases/products/get
If you read that API link it's easy to check with the online cache if the purchase was valid with a simple GET request.
Personally I would build in a check if the phone is suspect to be rooted before doing the manual background check with the purchases API that sends a request to the store.
Phones that are not rooted have a higher trust level, as the user are probaly not very tech savvy and will not have a shimmer of a clue how to circumvent such checks, and the google play cache will be updated regularly, reflecting trustworthy data.
When a phone is suspect to be rooted(you can read protected directories/write to them), then perform the check online if they bought the stuff each time you deem it neccesary.
I have an Iphone application in which i am trying to implement non renewable subscription.I had done it a manner that after the purchase i am adding that details to user account information.so he can get it on all the devices.I have a login at the start of my application.And after associating the reciept data with the user account i was finding out the expiry date in my server from the purchase date in the reciept data, by using that information i was showing the buy button again to my user.But the apple is rejecting it for the reasons
11.6: Content subscriptions using IAP must last a minimum of 7 days and be available to the user from all of their iOS devices
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
Can anybody know the exact mechanism to implement nonrenewable subscriptions ?
From your description it sounds like your login when they start your app is mandatory. Apple forbids this. They insist that the login be optional, but it must still be available to everyone who wants to use it (when using non-renewing subscriptions).
What I did on my app was, next to where I show the user's purchased subscription level, I have a button that says Save your account.... And when they click it it describes to them how, if they create an e-mail and password than they can share their subscription across all their devices and they can restore their account if their iPhone gets lost or stolen. You want to incentivize the user to do this because a better experience for them means a better experience for you. You could even offer them a perk, like 2-weeks free if they create an account. And since you're using non-renewing subscriptions, you have the power to do this since you're calculating your own expiration date, instead of letting the app store do it for you.
I am working on a application which has a more peculiar requirement. Basically it is something which is not targeted at end users but at a system integrator who will embed an iPad into a larger system and sell it to an end user as a whole.
However, the problem I'm facing is that the system integrators could simply purchase the app once and then keep cloning thousands of iPads from a single iTunes account, my company would not get any revenue from this.
Is there any way around this. I've looked at in app purchases but according to the guidelines I'm supposed to give in app purchase restore functionality so I guess if I don't the app won't get approved.
I could use external authentication servers I guess, but that may be viewed as circumventing the app store.
I've loked at the volume B2B stuff but I'm not quite clear on how that works or if it would help me in this case.
Any ideas?
Thanks
Last time I checked an application can only be installed on five devices, and then the other ones simply refuse to install the application.
If this system integrator managed to circumvent this, it's he who is breaking the App Store rules.
You can't use the App Store mechanisms as you described (you can't change iTunes). In-App purchases of non-consumable items must include a restore option so the user can restore it on all his devices even if it's thousands (this also for subscriptions etc). If you won't enable that you would be rejected.
You can think you can send the Device-ID for each device that purchase the item and have control over that(or any information) but apple would simply reject your app because it's forbidden to send device-ID.
If your service is online you can simply use some kind of tokens created on your servers which would be given to each client (from some kind of private key), This way you must be connected to each purchased item (only those would contact your servers and you would grant access).
Security wise you must consider leaving some of the functionality on your server side. This is not illegal same as you can't access Facebook without username& password.
And now for the easy way, Define your service as consumable item for in-App purchase(if you can). What does it mean? Lets say you are selling a special feature like "Ad-Free" you can sell credits that would be consumed with each app open or any other process you have in mind, You can even set this credit to 1 million for 0.99$ (so the user never gets to that) but still the consumer would have to buy it again and again for each device and it would be absolutely legal by Apple. Pay attention that the problem would be on the consumer side such as that if user have deleted his app you should find a way to help him or refund him on next buy. Also, If you can and would use this method pay attention to save those credits on the restored folder on the device, so if the user would upgrade or restore the device he would still have the credits he bought.
Pay attention that if you are going to use in-App there are lots of methods to steal this content on jailbroken devices and you must use your own server to check the buying process (according to Apple).
Another important thing is that the app without the in-App purchase must have some value to the user.
I have developed an iPhone application that was rejected. With this application I offer an SMS transmission service. On my website each user has an account and he can buy credits on the website to be able to send SMS.
The reason for rejections was that my app uses an external service, my website. They say I have to use in-app purchase for the credits.
So now I am about to extend my api. So if purchase takes place in-app the web server needs to know that there was a purchase and what type of purchase. This is done using HTTP-POST.
I could build a simple url and register the purchase in the user-account, since I can verify that an purchase was performed correctly in the app store. But to prevent hacking and just for security reason I think there has to be some kind of encryption.
E.g. if the payment process in the app was successful I send a HTTP-POST to my webserver. It contains some encrypted key that can be encrypted by the webserver.
What do you think about all this? How can I make my api safe regarding in-app purchase and what security algorithm could I use?
Any other suggestions or ideas?
You should probably look into the Server Product Model, rather than trying to invent some way for your app on the device to tell the server that credit was purchased after the fact. The section on Verifying Store Receipts will come in handy; in short, your app transmits the contents of transactionReceipt to your server (ideally via HTTPS). Your server base64-encodes it, embeds it in a simple JSON object, and posts it to Apple to get the status and verified purchase information.
I have a complete implementation of storekit including the server code.
http://blog.mugunthkumar.com/coding/mkstorekit-4-0-supporting-auto-renewable-subscriptions/
Try this
You should check out this wiki article on public key encryption. This is what you'll probably what to be using.
CommonCrypto is a module available for iOS that deals with this type of encryption. Here is a sample project in the iOS developer library that uses this module.
Yes You are correct. That is the best way. When user purchase credit using In-App purchase(IAP) You will have delegate method for purchase succeed. So you can call your Server API in this delegate method and put some flag with credit number in the user table of your server database. You can send this info encrypted and your server would decrypt it and insert in your database.
Does anyone have any idea of a service provider that provides In App Purchase with subscription model. I checked Urban Airship which has solution built around non-consumable approach and iLime is not available yet. Any pointers in the right direction would be appreciated.
Though i am not aware of the service providers, i will be able to tell you about tracking of subscriptions.
Tracking usually needs the user's connected 5 devices to be enabled with the subscription. For this, you either have to maintain another set of user credentials on the server and ask the user to enter the credentials once the app is loaded onto each device.
another approach is the unique userid for the device once the app is loaded. Upon installation on the second device, the same userid needs to be entered for enabling subscriptions.
Try to look out for newer version of ApalyaTv for more details.