The following extract is from the Apple documents how to restore in App purchases in iOS 7. They say that you can store the receipts and find out later what they user already bought or you can refresh the App Receipt. My questions are:
1) Is there the one app receipt or are there many single receipt?
2) Does it make more sense to store these receipts instead of just storing directly which features the user has already bought
3) How can I examine the receipt that I get from that refresh? All my tries to parse it failed so far.
4) Is there any framework that has a lot of features (saving receipts / bought products on iCloud, making purchases easier, handling downloads, handling all kinds of connection problems, etc.) already? Maybe even with remote server support (and validation).
I hope somebody can help! :)
Refreshing the App Receipt
Create a receipt refresh request, set a delegate, and start the request. The request supports optional properties for obtaining receipts in various states during testing such as expired receipts—for details, see the values for the initWithReceiptProperties: method of SKReceiptRefreshRequest.
request = [[SKReceiptRefreshRequest alloc] init];
request.delegate = self;
[request start];
After the receipt is refreshed, examine it and deliver any products that were added.
1) Is there the one app receipt or are there many single receipt?
There is a single app receipt. Before that, Apple provided receipts for each transaction. Those receipts still exist but are deprecated.
2) Does it make more sense to store these receipts instead of just storing directly which features the user has already bought
Not anymore (for iOS 7 apps).
3) How can I examine the receipt that I get from that refresh? All my tries to parse it failed so far.
This is a complex issue. I suggest reading this unapologetically long answer: https://stackoverflow.com/a/20039394/143378.
4) Is there any framework that has a lot of features (saving receipts / bought products on iCloud, making purchases easier, handling downloads, handling all kinds of connection problems, etc.) already? Maybe even with remote server support (and validation).
There are 3 that I'm aware of:
CargoBay
RMStore
MKStoreKit
To date, MKStoreKit appears abandoned and CargoBay doesn't support app receipts. CargoBay has features that RMStore hasn't, and viceversa. I'd check them both and see which one fits your requirements better.
In any case, I recommend reading the StoreKit documentation before using any libraries. The libraries provide code, not understanding.
Disclaimer: I developed RMStore.
Related
in iOS with in-app purchases, it is necessary to verify receipts with subscriptions. is it necessary to verify receipts for consumables also?
No you don't need to verify receipts for consumables.
You don't need to verify receipts for subscriptions either. What's important here is that you can restore running subscriptions; but for that you can use purchase ID.
As always make 100% sure you've given the user what was paid for before telling iOS that the purchase was successful!
(There are all kinds of other considerations why you would like to keep purchase related information on a server, but that's not what you ask about.)
Necessary, no. Recommended, yes.
All purchases; consumables, un-consumables and subscriptions are susceptible to fraudulent attacks. Often though iap crackers or network spoofing. Validating the receipt can mitigate this problem.
You can validate the receipt locally in the app (see Validating Receipts Locally), though it is still susceptible to cracking.
The safest way to prevent fraud is to perform server-side validation by sending the receipt to your server then sending it on to Apple (see Validating Receipts With the App Store).
However, do not validate the receipt with the app store in the app itself. It's really easy to spoof the network request and return a positive (valid) result.
If you notice a large discrepancy between the actual purchases in your reports from Apple and your in-app purchase analytics (assuming you have that), you may want to invest in server-side validation, otherwise, if it's not a problem, don't worry about it.
The Apple docs on receipt validation say to perform receipt validation immediately after launch. This amounts to checking for data at the path returned by [[NSBundle mainBundle] appStoreRecieptURL], refreshing via SKReceiptRefreshRequest if it's not there, and validating it. The aforelinked docs reference both iOS and macOS.
Is it actually necessary on iOS? If so, why? Is it to prevent users from using my app on a jailbroken device, or without having bought it from the app store (in which case I probably don't care if my app is free)? Or does it have implications for other operations like restoring or validating in-app purchases? For example, does the receipt data have to be there already in order to validate a transaction for an in-app purchase?
Note: I am not using in-app subscriptions. I have in-app purchases, but I don't use the receipts from them after verifying them and recording the purchase server-side.
you don't need to do so, that is optional only and could be done on iOS7+, if you interested in doing that.
briefly, implementing the validation is purely a financial decision, and even if you validate recipes you are recommended not to disable the content in case of failure as the validation could fail in standard environment as well anytime (e.g. in case of no connection), and such overreaction may ruin your consumers' experience.
altogether, doing the validation'd rather make sense on OSX in practice when you are allowed to disable the content in case of failure, regardless the reason; but if you feel you have more consumers than your income suggests or the amount of the stolen content is way beyond your margin, it may be worth to do it on iOS as well.
NOTE: in general you can read more about the technical details of receipt validation in Apple's Documentation.
The simple answer to your question is NO, It is not necessary.
Here is the detailed explanation for you.
According to Apple Documentation here, apple has given two methods of validating the receipts, they are given it as guidance only to prevent unauthorized copies of your application from running. For more guidance apple has pointed towards the apple review guidelines.
In the review guidelines here, Apple does not mention anything related to the verification of receipts as mandatory.
If at all the receipt validation is mandatory, Apple would have provided a simple API to validate it.
Titbit: You can see a lot of rejections when it comes to app store receipt validations. But all those issues are because the receipt validation is not done properly.
But my personal recommendations will differ from the above answer. First thing for you to consider is "Never underestimate hackers". Validate the receipts several times apart from the start of the app. Read this article for more information.
You would generally only validate the receipt to prevent piracy by users who haven't bought your app or if you are using auto renewing subscriptions.
Whilst you can interrogate the receipt for IAP information, its actually easier (and required by app review) to give a button somewhere to "restore previous purchases" and call
[[SKPaymentQueue defaultQueue] restoreCompletedTransactions];
It is also a better UX for the user to possibly be prompted for their Apple ID and password having pressed a "restore purchases" button rather than unexplained at app startup.
The reasons I would give are:
The user can change their product if you are using subscription groups from outside of your app.
An auto-renewing subscription can renew outside of your app.
The app does not receive transactions initiated outside of the app until the app restarts.
The user can make purchases on another device using the same appleID whilst outside of your app on the current device.
Within our appDelegate:application didFinishLaunchingWithOptions we initialise a class that calls
[[SKPaymentQueue defaultQueue] addTransactionObserver:self];
to monitor for purchases initiated from within the app.
It's not necessary, but beneficial for the following reasons:
You'll always get the definite set of purchased products and not require the user to manually restore the products.
You have (limited) fraud protection, especially if you combine local and remote validation.
It's way more simple to compute the expiration date for automatically renewing subscriptions using the recipe.
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've read Apple's documentaion a few times now and I didn't really get much smarter from it. So I hope somebody here knows how to deal with receipt validation:
I know there was a problem pre iOS 6. But is Receipt Validation needed nowadays on iOS 7? Does it really add extra security? It seems like it can cause problems if Apple changes the format of their receipts (parsing them on device).
In what I've seen, iOS7 doesn't change the need for whether or not you should do receipt validation, just how receipt validation is possible. iOS7 has enabled receipt validation on the device (e.g., see link from https://stackoverflow.com/users/1226963/rmaddy above, and see A complete solution to LOCALLY validate an in-app receipts and bundle receipts on iOS 7).
Does on-device receipt validation add extra security? It seems to me that it does. It gives you one more tool with which to secure your purchases. In my app (yet to be released), I want to support iOS6 and iOS7 so I decided to have a back-end server to do receipt validation for the iOS6 case. And since I have that server in place, for iOS7 receipts, I do on-device validation first and if that succeeds, I do server validation as a second check.
Whether or not you do receipt validation (in iOS5, iOS6, iOS7 etc) really depends on how much your security means to you. If you don't have much in the way of security needs, then why spend much time on security. If you do, then do more.
What if Apple changes the format of the receipts? Well, of course, this can and likely will happen. Given that the iOS6 to iOS7 change restructured receipts and in-app purchases considerably, it seems we should expect iOS8 to do so again. That's the future. Deal with what we have now.
Receipt validation is not required, but needed in these cases:
In case of auto-renewable subscriptions when a purchase has just been made – to get an expiration date.
When restoring in-app purchases. If user has reinstalled the app or launched it from a new device, you must provide a mechanism to restore his purchases and give access to features he already paid for.
A couple of years ago, when jailbreak was commonly used, developers used to validate receipts to verify that payment wasn’t hacked – I believe those days are gone now, and it’s not so necessary anymore.
Here is a complete FAQ about App Store receipt validation from our blog:
https://blog.apphud.com/receipt-validation/
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.