Okay so I’m making a tweak , when I purchase the app it works fine ( using transactionstate 1 ) , but after I close the app I have to re do the purchase every time .. can someone help.. I’ve tried iapcrackers but they do the same thing.. it’s like there’s no receipt or transactions not saving..
Receipt validation is too complex to explain here. To get a brief overview, I recommend you to read the article from Apple about possible receipt validation techniques and to watch the WWDC video linked in the article.
After you get a brief overview, you can decide if you want to go with local or server receipt validation. As with everything, both have their advantages and disadvantages.
Unfortunately, Apple doesn't provide a good article about local receipt validation and so far I haven't found a framework doing this correctly (as I would expect it). Although, it can be a good start without the hurdle of thinking about server communication.
If you go with the local receipt validation, I recommend you to use TPInAppReceipt to access the receipt and its fields.
For server receipt validation there is this article from Apple, describing roughly the steps you need to do.
Apart from that, there are some third-party solutions for server receipt validation like RevenueCat, ChurnFighter, and Qonversion.
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.
Does anyone know the easy way to check if the user already purchased a subscription or not when the app loads?
I just need to check if the user already purchased the subscription, nothing else. Seems easy, but it is not in reality, because I need to validate a receipt and check a subscription date.... The subscription validation technique seems to be not an easy task and I didn't find a good tutorial or a good guide that describes how to implement it step by step. I've read Apple documentation here
Is there any easy Local Receipt Validation and Subscription Validation technique to check if the user subscribed or not?
Maybe anyone knows a framework or a method to do it fast? Any help appreciated.
Using: Swift 4, Xcode 9.4
The RevenueCat SDK provides a good out-of-the box solution for this.
More than a couple reasons why I like this approach:
Validates receipt server side (without requiring me to set up a server)
Checks for an "active" subscription with a server timestamp so can't be spoofed by changing the device clock
Caches the result so it's super fast and works offline
There's some more details in this question: https://stackoverflow.com/a/55404121/3166209
Which boils down to:
subscriptionStatus { (subscribed) in
if subscribed {
// Show that great pro content
}
}
Ok here is your answer. I have also followed this same tutorial and it helped me. I validated the receipt and confirmed that the payment is made. See the link below. Hope it helps.
In App Purchase in Swift, with Receipt Validation
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
Back last year, that russian hacker created a way to validate in-app purchases without payment and this guy created a class to verify each purchase.
As far as I know, this technique exposed by the hacker does not work on iOS 6 anymore, but I am not sure about that.
I am creating a new app for iOS 6 and trying to minimize the code to a minimum and even better than that, my in-apps involved hosted content with Apple, so I wonder if this added validation is really necessary for my case.
Remember that
I am developing for iOS 6 and up;
my in-apps have hosted content with apple, so even if the hacking technique works the person will never get the content hosted with apple.
any thoughts?
thanks.
The vulnerability should be addressed in iOS6, but that does not mean you should deviate from Receipt Validation best practices in general. See Verifying Store Receipts and
In-App Purchase Receipt Validation on iOS for more information.
As mentioned in the links above, Apple recommend you follow their best practices for receipt validation, be it on iOS 5 or iOS 6. "Simplicity of code" is not a good enough excuse to deviate from these guidelines. If you structure your code into well defined classes, you can abstract away all the receipt validation logic to its own class, making the code that uses it a lot cleaner anyway.
If you connect to the App Store directly from the App for validation, the measures they explicitly state (see "My app performs validation by connecting to the App Store server directly. How am I affected?") should help. If you implement them in an abstracted way (in a category or class), then it should still keep your code clean.
Even if your content is hosted by Apple, you're still giving yourself an extra safeguard against fraud. Apple are not perfect; they could slip up themselves leaving your app open.
Ultimately, when you're dealing with your own revenue, you better play it safe than be sorry afterwards.
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