I'm looking to implement the new Auto Renewable subscriptions using In App purchase but I am unsure how or when to check if the user is currently subscribed. My understanding is that when the user initially subscribes the app can use the purchase date along with the subscription date to calculate how long their subscription would last. What happens after this date has passed? How do we check if the user has auto renewed or cancelled?
If I use restoreCompletedTransactions
to get a transaction and receipt for each renewal the user will be prompted to enter their iTunes password. Does this mean that if they have bought a 7 day subscription they will have to enter their password every 7 days when the app checks if the subscription is still valid?
Today, I have trouble with this problem.
Follow Apple doc here, I used this way to check subscription is expired or not. My idea: user APPLE REST API response: (request time + expired time) to check expired or not
Hope this help.
Better to use a local solution before making any calls to the Apple api. Every time the app runs it's good a good practice to validate the local receipt and if you need to check if an user has the active subscription, you can first retrieve the purchases from the local receipt and find out is the purchase is still active for today.
I have implemented a small library written in
Swift
to simplify to work with In-App Receipt locally. You can easily fetch the object that represents the receipt (InAppReceipt
) and retrieve an active purchase/all purchases.Feel free to use. Github link
Here is an example of solving your problem:
I am starting a campaign around this issue. Here is my observation and campaign:
Upon auto-renewal, the App Store calls the
paymentQueue
and posts a transaction. The transaction is posted withtransaction.transactionState==SKPaymentTransactionStateRestored
.The issue is that unfortunately this gets posted only to one device. A second device does not get the posting. Therefore, to detect the auto-renewal, or rather to detect the lack of an autorenewal and deny the device a continuing subscription, you have to do a
restoreCompletedTransaction
or "http post a 64-bit encoded JSON containing the last transaction". If the former, the user needs to give their password; that's intrusive - as you have pointed out above. If the latter, lots of additional coding is required. So, my question is...why doesn'tStoreKit
have a command:(does not exist)
- [[SKPaymentQueue defaultQueue] restoreAttachedTransactions:(NSArray *)transactions];
This command would flow just like a
restoreCompletedTransactions
but it would only restore the attached transactions and, most importantly, it would not require log-in by the user. It has the same security protection as the "http post a 64-bit encoded JSON containing the last transaction" and it allows the entire In App Purchase process to be done inStoreKit
rather than requiring web posting code.If this makes sense to you, please suggest how to get this to Apple....thanks.
See this for docs:
http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/VerifyingStoreReceipts/VerifyingStoreReceipts.html#//apple_ref/doc/uid/TP40008267-CH104-SW1
IF you want to check on it from a web server, you ping their API and it returns the status of the auto-renewable subscription and info about the last payment.
If you are on the device then you probably have to call restoreCompletedTransactions which I guess asks for the password.
I don't see any other method. I suppose from the device you could verify the subscription by contacting the same web service used on the server side? I don't know how the pros and cons of that.