I am working on in app purchase which works fine but I want to know that user have purchased product or not at the launching time of application.
How should I know this.
If anybody knows please help.
Thanks in advance.
You can store a "receipt" in the user defaults (NSUserDefaults) then check if the receipt exists when the app is launched.
HOWEVER plainly using NSUserDefaults is prone to hacking so you can use a secure version of user defaults from here.
another solution (and the recommended one if done correctly) will be to store receipts on a server and read available receipts when the app launches. (Note though that if the user has turned device data off you won't be able to read them).
It would be best to get the user's purchase receipt and check all the products they have purchased.
You can follow the guide here to see how you can validate receipts locally.
This document explains the structure of the receipt - the in-app purchase fields have the product identifiers which can be used to find out which IAPs the user has access to.
Related
Currently i have a paid app, i store no information in NSUserDefaults or keychain in order to identify that user has paid, and i dont want to release an update just to do that..
Now i want to use IAP, and considering the above the only way i can find out if user has already bought the app(version prior to IAP) is through purchase receipt validation, and i would like that to be done locally.
Any ideas how it can be done in swift?
Please don't mark this as duplicate, i have already read other similar posts..
If you can think of any other solution, other than purchase receipt validation, that wouldn't require an interim update please advice..
We have a successful app on the iOS app store with in-app purchases. Every time a purchase is completed we send the receipt to our server, our server than checks the receipt with Apple's servers and logs apple's response(including whether the purchase was valid and that they come from our app in that same time and date).
We have quite a few users who use iap cracks that send us receipts that apple says are invalid. However we started now to see cheaters that have receipts that apple replies that are VALID. What is strange in these cheats, that when such a cheater user purchases in our app, he usually purchases all of the purchases with the exact same receipt.
Have you heard of such a way to 'fool' apple receipt validation?(to generate receipts that apple will say they are from our app in the time of the 'purchase')
Is there something we can do to find those cheaters in their 1st purchase (for the next purchases we can simply check times of the next receipts or make sure that our receipts are unique)
Thanks!
Is there something we can do to find those cheaters in their 1st purchase
Actually, if this is the same hack I've seen discussed as a proof of concept recently, the first purchase is legitimate. The "innovation" is in decoding that legitimate receipt and rejigging its IAP ID with a different one while the receipt overall still appears valid. So simply avoiding the duplicates is enough. Didn't think that one was anywhere near production-ready though, so this might be something different.
We also faced similar issue while developing a game of iOS app store where business model was based on In App Purchase only.
Initially we used to check with Apple Servers for the receipts directly from the device. But some hacker has created a hack for the users where they can install the DNS server certificate on their device which spoofs the response from Apple.
The way to do this is let web server check for the receipts from Apple directly with some kind of hashing or md5 check to make sure the response if from Apple.
here is a link which have a detailed information on this https://www.objc.io/issues/17-security/receipt-validation/
Hope this helps.
I have 2 application on appstore
Free app with in app purchase.
Paid app.
Now, I want to keep only one app on appstore from above options 1.Free app with in app purchase and remove the paid app. But here I want to give the app with full functionality to those user who used the paid app (Purchased the paid app).
Here my question is how can I merge these 2 app into single app which will be free and contains in app purchase by keeping the paid app user as it is ?
If anyone have any idea regarding this then please share.
Thanks in advance.
I solved my problem by using the icloud. First I provided the update to both the application by doing following changes.
I used "key value store" icloud option and stored some setting on icloud just need to make sure here "iCloud Key-Value Store" value in .entitlements file (which was automatically created by XCode) in both the application is same for both the application. The setting stored here is accessible to both application and depending on the setting I identified the user and gave access to specific functionality.
Under iOS7, you can use Receipt Validation. Receipt Validation offers you to see information about purchasing the app and in app purchases. If it returns date before you made the app free, that means that the user paid for the app.
This will work only under iOS7.
See Receipt Validation Programming Guide
I too am facing this issue with a couple of my apps. I'm still looking for a good solution, but I came up a less-than-ideal solution in the meantime. You can issue an update to your paid app that will connect to a database (on your web server) and insert a row with information about the purchase (AppleID, maybe some kind of digital receipt). Then in the free version with IAPs, the same database connection can be used to see if the owner of the free app already purchased the other app. Based off of that, you can unlock the IAPs. The only problem is that this is dependent on all previous customers updating to the latest version.
As mentioned, Receipt Validation would probably be more efficient, however this isn't backwards compatible. Good luck!
I'm assuming you're looking to merge the purchase history on Apple's servers; you can't merge the purchase data for two bundle IDs, you'll have to devise some way of having users persist their data on a server that you control. Update your app with a login and tie that login with the purchases as user has made.
The workflow would be something like this:
1) User logs in on paid app
2) User restores purchase history
3) Paid app saves restored purchase history to your server
4) User logs in on free app
5) Free app downloads all purchase data for the logged in user
I am investigating the use of in-app purchase for what essentially would be a "pro" version of my app.
The app itself would be free but once in the user has the option to purchase the pro content (only 1 thing). The "pro" content would already be on the app and there is no need to download it, it would simply "unlock" it.
Is this allowed from the Apple Guidelines?
As only 1 non-consumable would be purchased I think the use of a back-end server isn't required.
Again is that allowed from the guidelines?
And is it safe and simple to just store the result in NSUserDefaults and if installed on another device pull it from SKPayment restore purchased and such?
I've looked at several other questions.
In-App Purchasing?
Retrieve purchased information in In-App purchase
How do I add consumable In App Purchases using NSUserDefaults and not my own server?
And those seem to suggest that my approach is valid, but as I know those things have changed recently I want to make sure I'm taking the right approach.
Thanks!
No problem having the content built in.
Best practice is to perform receipt verification on a server with an authentication protocol between the app and server (this is also true for several other mobile app stores). If you perform the verification on the device, people can use existing tools to get around your IAP checking and steal content. Take a look at https://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/ for some information.
So while a server is not required, it is recommended. Only you can say if protecting your content is worth the hassle of maintaining a server.
I agree with J. Freeman that straight storage in NSUserDefaults seems weak. I store things in a local file but the format is tied to the device and requires a server computed key to create it. Finally, yes you should use SKPaymentQueue restoreCompletedTransactions to get things purchased on another device. Realize that the restored transactions should also have their receipts verified on your server.
Yes that is fine. You do not need a backend to do in-app purchases, and it is ok to ship with your content built in.
The one thing I would say be careful with though is storing the unlock information in NSUserDefaults as someone will easily be able to forge purchases that way. You should store the unlock information in the keychain.
It's my first integration of In-App Purchases. I have everything working: I can buy the item I want, also use restoreCompletedTransactions.
Every time I call restoreCompletedTransactions() I am asked for username and password.
Is this because I am in sandbox mode or will this happen once being live as well?
How do I check if the user has bought it before? (I know I can save it in the user settings, but it would be nice to check if it was bought by polling the Apple server without the user needing to enter username and password).
How do others handle this? Because surely you want to know if they refunded it.
Quote from the Apple Article Instructions on how "not" to do this:
Restoring purchases prompts for the user’s App Store credentials, which interrupts the flow of your app: because of this, don’t automatically restore purchases, especially not every time your app is launched.
The best way to do this would be use receipts.
Steps in general are:
1) Your app would usually request a payment upon first time use
2) Once the customer has paid (or subscribed), then
3) Your app should download the receipt from the AppStore, and then store a copy of the Private Key and certificate details onto your server (or Cloud if it's a non-renewable subscription)
4) Your server should verify that receipt with the AppStore.
5) Optional: Your server can then query-last-receipt to ensure that the user's subscription is always up to date.
6) Once your server is satisfied, then let the app know that content can now be unlocked etc.
In other words, use receipts to verify and not keep retrieving finished transactions otherwise it would put your customers off by keep asking them for the iTunes password every time they need to start your app.
For more information, please watch this apple video
I hope this helps
Regards
Heider