I have an app with an auto-renwable item in the inApp-Purchase.
Let's say, with an period of 7 days.
If a test-User buys the item...
How can I check the expiration-date?
I can observe it with restoreCompletedTransaction, but there will be an Dialog to the user. Which is not so nice. Is there any other way without a server?
How can I handle the test-phase?
I don't see a way to shorten the 7 days... does it mean I have to wait 7 days, to see that I'm handling it right if the user doesn't subscribe again?
thank you
xnz
You can send the receipt to a server of yours and have it check and re check the receipt. When the subscription is prolonged your server receives an additional receipt indicating that.
I am not sure if this is possible within the app. You need a certificate and a shared-secret to verify auto renewables. It might be a bad idea to have the certificate and the shared-secret within your app.
You can find Apples documentation here:
http://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/RenewableSubscriptions/RenewableSubscriptions.html
There is some info by Apple that recommends to verify the receipt on your own server for security reasons:
http://developer.apple.com/library/ios/#releasenotes/StoreKit/IAP_ReceiptValidation/index.html
They also say, to know the status of your IAP (in the article, Consumable, but I guess it would work for subscriptions too) you can save the receipt, recall it when needed and verify it again, receiving an updated receipt.
Related
Good day! I'm trying to implement notifications for auto-renew subscriptions and some parts of the whole system are not clear for me. Could you please help?
First of all, when user creates a subscription I get a receipt from user's device, verify it and create a record in database with all needed information. Now, the notifications are coming to server.
INITIAL_BUY notification - When does it come and why? I just got a receipt from device, verified it and I'm happy. Why do I need it?
Correct me if I'm wrong, this part is unclear for me, When user UPGRADES subscription level I get CANCEL notification for oldSubscription and a receipt with a new purchase for newSubscription, right?
So theoretical question is - if on my server side content available in oldSubscription and content available in newSubscription are different entities than when I get CANCEL for oldSubscription I just deny user's access to oldSubscription content and when I get receipt from client I create newSubscription with access to new content, right?
DOWNGRADE and CROSSGRADE. As far as I see I get DID_CHANGE_RENEWAL_PREF or DID_CHANGE_RENEWAL_STATUS. So I will get auto_renew_status in notification for this subscription and when payed period will expire I will get a receipt from user device with info about new purchase? Or I have to figure out how to handle DOWNGRADE and CROSSGRADE only by DID_CHANGE_RENEWAL_PREF and DID_CHANGE_RENEWAL_STATUS notifications?
Thank you
The problem with server receipt validation is that there is not only one way. There are endless possibility to implement this and it depends on your use case of the usage of subscriptions and how you want the communication between your app and server to happen.
In your second paragraph is the first example of those possibilities: your server will get the receipt from the device only if you implemented it that way. Also, maybe you update your database solely based on the notifications instead of the send receipt. You see, it is all up to you ;-)
Regarding you questions:
1)
Occurs at the user’s initial purchase of the subscription.
See documentation
Theoretically this is correct, but your described use case isn't an upgrade. Would be odd, if the better subscription wouldn't contain the content of the lower one.
There isn't much to handle with down- or crossgrade. The notifications only tell you that there will be a change with the next auto-renewal. Because, the user is still eligible to access the better content until the next auto-renewal. After the better subscription expired you will receive a normal DID_RENEW with the down- or crsssgrade product id.
We have got a problem with auto renewable subscription.
First, I would like to tell you my case from the beginning to understand my problem totally.
So, I have an app that contains auto renewable subscription. I managed to buy a product from my app, but I would like to validate the receipt from my server. If I understand it well, then I should send the receipt data to my server that will send the receipt data to Apple and verify that receipt.
First question is that, do I know it right that verification means that we send a request to https://sandbox.itunes.apple.com/verifyReceipt ?
Secondly, what happens if I cannot send the receipt data for the server? I mean, in this case should I save the receipt data locally and try to send it again in a different time (my app can be used after registration so I have to send the user id with receipt data to my server)?
Furthermore, there is a subscription status URL for auto renewable subscription in iTunes connect. We set up an URL for this but we do not get any notification from Apple's server. We configured the server as explained in Apple's documentation (protocols, etc.) but we still don't get any notification. Do you have any suggestion why is it?
Do I know it well, that the notifications should be sent automatically if any status update change happens? If not then what should I do in my app or on my server? (e.g. how to detect if user cancels a subscription?)
Do I have to implement both logic for the best user experience?
To validate the receipt you can send it on apple servers, "can" because you can validate the receipt also in app. In this case is not fully safe, because someone can attack you app and tamper your validation code.
Apple has 2 different kind of servers test and production, when you are debugging you send receipt to the test servers, that also means that auto renewable subscription have shorter time, if I remember well a month in test is 5 minutes.
This is documented very well in apple documentation.
A receipt is always present in your app even if it's free. It's up to you how to manage those kind of situation, in my opinion a receipt should aways be valid from the beginning until the server responds in a different way.
The third question is not clear. There is a system to refresh a subscription but this should be done with user permission as far as I know, the subscription itself seems to be already updated automatically from time to time by the purchase mechanism.
You must implement all the logic to manage a subscription, cancellation, revocation etc.
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.
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.
We have issues fully understanding the receipt validation flow in iOS.
Here is what we currently do (in development):
In applicationDidFinishLaunching and in applicationWillEnterForeground we validate the receipt on the server side, if there is no receipt or the receipt is invalid, we try to refresh the receipt and revalidate it.
Here are some issues/questions:
What are the cases where there is no receipt available on the device ?
Should we always issue a receipt refresh request when there is no receipt ?
Why is this alert box sometimes shown on startup ? I understand this is shown on a receipt refresh request ?
When should a receipt verification happen ? We currently do it whenever a purchase is made to verify the purchase, is this correct usage ?
In production a receipt is always available on device. In test after
the first install there is not. So if you want to do a correct test,
you must restore a purchase even if it doesn't exist a purchase on that user in the test
environment. Why is that? App downloaded from the appstore always comes with a receipt even if they are free.
Depends on the business logic you want to apply. If you are validating the receipt against a server each time the use launch the app, of course you need the receipt. If it is not present (but in production is always) or not valid, you can ask for a refresh or restore, but as far as I remember you should always ask the user first if he/she want to do that (can be a reason for reject).
Restore and Refresh are not the same thing.
This usually appear in purchase/restor/refresh. But also If the account has some pending requests because the app has crashed or you interrupted the debugging before the request end somehow, you will be bored by a lot of that. There is no way to flush them programmatically, just login until they stop. Of course it will not be a valid test.
It's up to you and about the kind of purchase. If it is an autorenewable subscription, you can validate the receipt against a server, then store the the "end date" on the client and make another check after the date is expired. Pay attention that receipts can be quite big, because the have also all history values.
As Zhang mentioned, if there is no purchase or restore took place, there will be no receipt in the store
Locate the receipt. If no receipt is found, then the validation fails and you should not request receipt refresh again. Only when you will restore process by yourself, you should request for the receipt again.
This will be shown always when you will try to refresh the receipt (or you will pick from settings that you want not to ask for a password for 15 minutes).
Yes.
For more information, look here:
https://www.objc.io/issues/17-security/receipt-validation/#about-validation
If a user downloaded the app from the App Store – yes, receipt always exists.
However, in sandbox if your app was installed via Xcode or Testflight, then there won’t be a receipt until you make a purchase or restore.
Take a look at this complete FAQ about receipt validation in our blog:
https://blog.apphud.com/receipt-validation/
1.No purchase/Restore took place.
2.Nope.See 1
4.Sure.For consumable products,remember to save hash on your server,in order to defeat replay attack.