Had asked a question here - https://stackoverflow.com/questions/19523482/preparing-for-in-app-purchase
As I did not want to mix an additional question in there - asking separately
Do I need to implement - validate receipts on my own using my own server ?
Was reading this link:
http://www.digitaltrends.com/mobile/how-a-russian-hacker-cracked-apples-ios-in-app-purchasing/
So am confused if I need to implement validating receipts using my own server or is this unnecessary
I am able to test in sandbox - basic stuff - but wanted to understand the details
Any pointers or suggestions would be welcome
Thanks
akila
You don't need your own server, yet jailbroken devices will be able to get your in-app purchase for free if they have the right package installed.
Related
I have an app that needs to use IAP. I tested with sample code and sandbox user and the transactions are made successfully. Where I cannot proceed is the receipt validation part. Firstly - the app uses consumable products /tokens/ - somewhere I read no need for validation in this case. But I wonder why - if the transaction can be fake successful in the rest of the cases, why not when consumable. So part of the question is - should I validate consumable purchases?
If the answer is yes - I read validation should be unique for the app and not just some generic solution. Some client side solutions I've found here and here. I wonder if't is okay just to use one of those or this would be not secure enough (considering it won't be unique, I don't expect anyone to examine them). Or is it better and more secure for this to be done server side?
I hope these questions are not too broad and thank you in advance for your help.
Before marking this question as duplicate i want to understand one thing. This scenario has been argued many times here, but i still have few doubts?
We have a auto renewal concept in our app, I know that once purchase done receipt will be generated. Using Apple API we can validate the receipt, My question is what would be the case if user didnt open the app for a long time? How will i send the receipt verification to my server to maintain the subscription status?
What if user once finishing the auto renewal later he deleted the app and installed it in new device? How will i track the subscription status without opening the app?
Is there any API we can use directly to question the apple server about the transaction details ?
I tried my hard to understand the things, but still am logging in this. If someone have idea just help me to understand it!! Thanks in advance.
I've just made iOS app with IAP to purchase virtual coins(Consumable). And the backend is Ruby on Rails. I have some concerns for now about the whole solution.
My current IAP process describes as following:
STEP 1 - iOS Client sends request to our backend and get product ids.
STEP 2 - Client retrieve product list through Store Kit with ids from step1
STEP 3 - User click buy and client sends a payment request to Store Kit
STEP 4 - When finish transaction the client send the receipt token to our backend
STEP 5 - Server verifies the receipt first to make sure it's a valid verification
STEP 6 - Server calls App Store to verify the receipt and deal with the exchange(Recharge account in DB)
STEP 7 - Client gets the response back and displays account balance
I worked on e-commerce/payment solutions before, and IAP takes the other way, though usually the payment gateway will send the receipt server-to-server for verification. And we always have message queue sort of solutions to make sure all transactions are stable and maintainable.
My questions are:
What's the best practice to verify IAP receipt? How to avoid the interruption of verification from our server? (e.g., User spend money and finish the transaction on the client, but fails when verify the receipt on server. No IAP restore transaction support.)
Apple IAP more likely a perfect client solution. Especially in my case, after user's payment, he wants to receives the coins immediately, and not the case we tell him the transaction is processing and his account will be fulfilled soon. To have responsive UX on mobile device is prioritized. Do you still use message queue stuff on server?
Thanks for your time.
You might find http://helios.io/ useful. It combines four useful iOS related gems, one of which is https://github.com/mattt/rack-in-app-purchase
Question 1: According to Apple's docs here, you should always validate receipts on the server. There are a couple of ruby gems that can help with talking to Apple's server on the backend:
https://github.com/gabrielgarza/monza
Hosted: https://getmonza.com
https://github.com/nomad/venice
https://github.com/nov/itunes-receipt
Question 2: This depends how concerned you are with fraud. If you don't validate receipts then you expose yourself to fraud. I would highly recommend validating on the server side.
Checkout this WWDC video that for a nice fundamentals on In App Purchases.
If I understand the question correctly, it looks like there's a gem called itunes-receipt that can be used for this. The gem can be found here: https://github.com/nov/itunes-receipt
There's also an NSScreencast addressing this issue, and the instructions within the show notes look fairly complete. http://nsscreencast.com/episodes/45-validating-iap-receipts
I've got in-app purchases working just fine, and I'm going the server validation route. The server needs to know whether I'm in the sandbox or not, so for now I'm just sending it a "&sandbox=1" parameter. Of course when the full version of the app is out I won't be sending this parameter.
I'd rather not have this hardcoded in my app, as that will make testing difficult in the future, and it's one more (big) thing to remember to change before submitting builds to Apple.
Is there a way I can ask StoreKit if I am in the sandbox so I can then determine whether or not I need to send this parameter to my server? Alternatively, is there any other best practice for handling server validation?
Thinking about this more, should I just have the server always check the live system first, then the sandbox? If apple IDs are segregated between the live and sandbox systems then it wouldn't do any harm would it?
Thanks.
After a bit of digging I found this from Apple's Technical Note TN2259:
How do I verify my receipt (iOS)?
Always verify your receipt first with the production URL; proceed to verify with the sandbox URL if you receive a 21007 status code. Following this approach ensures that you do not have to switch between URLs while your application is being tested or reviewed in the sandbox or is live in the App Store.
So it looks like I should axe the &sandbox parameter completely and just do that. I really had to dig for this answer so I'm posting it here in hopes that someone else runs across it!
I encountered that very same problem, where my app was rejected because the "production" version of my app that I submitted was hardcoded to connect to a PHP script on my server that validates receipts with the real AppStore server (whereas my development build points to another PHP script that validates receipts with the sandbox server). However, after a few exchanges with Apple engineers, I found out that they use sandboxed user accounts to tests submitted applications, which explains why they got an error.
Instead of conditionally building my app to point to one script or the other, I will use a single script that tries the production server first and then falls back to the sandbox server if it receives the 21007 status code, as explained above!
Thanks a lot!
Always verify your receipt first with the production URL; proceed to verify with the sandbox URL if you receive a 21007 status code.
Unfortunately, the technical note fails to mention this is only valid for auto-renewing subscriptions!
As the In-App Purchase Programming Guide mentions below table 7-1:
Important The non-zero status codes here apply only when recovering information about a auto-renewable subscription. Do not use these status codes when testing responses for other kinds of products.
For non-renewing subscriptions, the production server does not return a status code, but a proper receipt.
In case you are forced to use non-renewing and implement your own subscription expiring logic, a possible solution is to send your app version along to your server, and keep track of which versions are in development at the moment, as such you can redirect to the sandbox.itunes server to verify receipts where appropriate, and mimic the x-minute expiring time of a subscription (as sandbox.itunes does for auto-renewing) for development on your server.
I read (almost) all the answers on verifying in-app purchase, and actually I already implement it in a server-side fashion. But managing a server sometimes could be too much expensive, and in theory you could do the verify from your app: basically is just sending a json to Apple and get the answer back.
Of course I know that on jailbroken devices the receipts may be fake (that's why you verify them) but (I beg pardon my ignorance) why I can't trust an https connection to the Apple server?
I mean if the user hack my app, there's no real way to be sure of anything, but if the hack is a general method to provide fake receipts testing with Apple could be enough right?
To be clear, what is the security level of an in-app verify of recipts? Can it add some degree of protection os is useless?
This answer explains quite well why you must use server side checking to limit the effect of some "general purpose" crackers, like "IAP cracker"; besides chaining the iTunes json request in your content delivery API is quite convenient and the answer is fast.
Of course if your aim is to provide some content already in the app but locked, you may feel it is not convenient to setup a server specifically for this, but I will ask you to do this experiment:
make an app with some good content and this content already locked in the app (so no content server need)
add some analytics just to track the usage of this locked feature
after some month, compare the number of purchases with the number of new users using the paid feature.
at this point it will be clear for you that adding a server script just for receipt validation is a good investment; besides there are some services, which are very cheap (e.g.: urban airship) we already do this for you, so you don't need to setup an hardware for this.
I hack inapp cracker and discover a way to block it client side: the receipts and transaction IDs it creates have a predictable scheme that's easy to spot. I put all the details here:
spot fake receipts client side
update
hope this helps