I have implemented som auto renewable subscriptions in my app and everything works well. I perform a purchase in the app, everything gets synced to a server, and the server then checks the iTunes API as soon as the subscription has expired to detect if the subscription has been renewed.
One thing confuses me though. Every once in a while I get a call to transactionsUpdated within my app with a transaction with status: Purchased. This is usually done after I restart the app.
Why do I get these calls? Has it something to do with the subscription beeing renewed? Can I safely ignore these calls? Everything seems to work fine.
Thanks in advance!
Yes, what Apple is doing is sending you a receipt for an automatic renewal of the subscription. Because all durations are drastically shortened in the sandbox, the subscription will get automatically renewed by Apple every few minutes, for a limited number of times (like 5), before they stop renewing.
Since you're already checking for new receipts at the right time on your server, you can ignore the receipts they're automatically sending to the app on occasion.
Related
I have implemented In-App Purchase Auto-Renewable Subscription into my app but I'm not sure if I have done it correctly as the app constantly asks for iTunes login.
In the user case: I am subscribed to monthly payments and my first month is over and expect it to auto-renew.
The flow I have at the moment is as follows...
(in App Delegate) Check receipt is valid
(if receipt IS valid) check all receipts for latest expiration date
(if expired - which seems to be the case after the first month is over) call SKReceiptRefreshRequest to get latest receipts. I have put a count check on this otherwise it gets stuck in a never ending loop.
Do final check to see if latest receipt is in-fact expired.
Is this the correct way to go about this? If not could you shine some light on this?
It all seems to be working fine apart from the annoyance of iTunes login. Which I guess would only be once a month outside of the Sandbox environment which isn't too bad but just want to be sure I'm doing this correctly.
Thanks
Don't call SKReceiptRefreshRequest. This request is usually only for the "restore purchases" mechanism. This is why you're getting the sign in dialogue. StoreKit will return to you as long as you an observer to the payment queue: https://developer.apple.com/documentation/storekit/skpaymentqueue/1506042-add so you should add yourself to the payment queue on app launch. Then keep that object aline to listen for changes for the entire app lifecycle. You will receive the renewals in the updatedTransactions callback https://developer.apple.com/documentation/storekit/skpaymenttransactionobserver/1506107-paymentqueue
Secondly, you should be doing receipt validation on your own server and not on the client as it will be susceptible to a MITM attack. You can also easily control the logic there and receive Server to server notifications which is best for managing subscriptions.
I have an app where I’m offering Auto Renewal Subscriptions. Here is how it currently works, when the user subscribes, it saves a Bool in UserDefaults as true, after that I can make a receipt request to see if the subscription has expired. My issue or what I don’t fully understand is the logic on how often to make that request, checking for authenticity every time the user launches the app seems like a lot, or do I need to save the expiration date in UserDefaults and just check a couple of days after the expiration date to see if the user renewed? This way we limit the requests we make to retrieve the Apple receipt.
Can someone share the logic used when checking for authenticity in an app using Auto Renewal Subscriptions?
The "right" way to do it is to manage everything server side (with some caching on the device in case the user is offline). Refreshing the receipt on the device is insecure, slow, and could make that annoying "Login with iTunes" prompt keep popping up for the user :)
It also prevents you from ever having complete analytics of your subscriber base since you can only get data points when they are active in the app.
What you would do is store the receipt file in a database after purchase, and refresh it there to keep the subscription status up-to-date. Then your app is asking your database if the user is subscribed (and caching the value in UserDefaults).
Here is a good blog post that outlines what the setup should look like: iOS Subscriptions are Hard
I have an iPhone app that also features autorenewable products as an in-app purchase. The products are subscriptions to our service for up to 1 year in the future. We wanted to remove the whole in-app-purchase and autorenewable product from our app in the next version.
To accomplish this, we removed the signup option inside our app, so no new user should be able to sign up. Now we would like to disable the automatic renewal for all existing users.
How can I accomplish this? Is it sufficient to remove the in-app-products for our app inside iTunes Connect? Do the users get notified about this?
According to Apple (see WWDC 2011 Session 510, In App Purchases for iOS and OS X, at the 48:55 mark), the only things you can do as a developer to prevent subscriptions from auto-renewing are:
Raise the price.
Remove the auto-renewing IAP product from iTunes connect.
In both cases, notification emails are sent to subscribers, though not immediately. The talk says Apple checks 10 days before a (yearly) subscription renewal and sends email at that time. It's not documented anywhere, though, so I'd treat that as an implementation detail.
I've done the latter (removing the product) several times with my own (monthly) apps, and it seems to work as advertised.
One important note: if your app is a Newsstand app, it must have at least one auto-renewing subscription available. If you remove the last one, the app will be removed form the App Store. Users who have already purchased it will still be able to use it, and will be able to download copies from the "previously purchased" section of the app store, but no new copies will show up for purchase in the App Store proper.
It will depend on how you've implemented your system. Do you check receipts (and provide data/service) from your own server, or do it all within the app directly with Apple's servers?
In iTunes Connect you can remove a product from sale, effective immediately or at a future date. I suspect that's enough to stop a renewing subscription. (Remember you can test this with shortened timescales in the Sandbox.) But if not:
If you use your own server to validate receipts, go and give it an incorrect shared secret so that the verification step fails. That means the subscription validity will return as false (although for the 'wrong' reason) so your customers won't be able to renew.
If you do it within the app, generate a new shared secret so the one within your existing structures is incorrect. Then, as above.
If you can, I suggest sending a notification to your current users notifying them of the change, suggesting that they change, and letting them know it will 'fail' in the future but that's ok.
I have implemented a couple of months ago the in app auto renewable subscription on two of my apps. I stored the old receipts of my users and contacted Apple from my server at the end of the subscription period to check if the subscription is still active.
I noticed that some of my users are being auto-renewed form the client code itself.
My app upon entry calls [[SKPaymentQueue defaultQueue] addTransactionObserver:myObserver] and when either SKPaymentTransactionStatePurchased or SKPaymentTransactionStateRestored is returned it calls my server to verify the receipt and give my users the subscription.
I have been trying for quite some time to understand the logic behind the transaction notification the client gets at the end of the renewal period. Does anyone knows why only some of the users get the notifications and the rest require the server to revalidate their receipts? I tried to think maybe it has got something to do with the call to addTransactionObserver. Maybe those users killed the app while it was in the background and entered the app again after the subscription period ended which caused the addTransactionObserver: to be fired and the notification to arrive.
If I can get all of my users to get this notification I wouldn't have to run the server calls anymore at the end of the subscription period as they would be fired from the client when needed.
Any insight would sure help understand this puzzle.
Thanks
Roi
My experience states you'll need to continue periodically verifying receipts on your server. I have noticed the same as you, that these new receipts are sent to the app inconsistently. I think Apple will send the receipt to the client if they happen to freshly launch the app within a certain time frame of the new renewal.
Folks,
I am attempting to verify that auto-renew subscriptions are actually renewing in the sandbox environment. First, it appears that auto-renew subscriptions in sandbox are only valid for 5 minutes. Makes sense. I expect that if I wait for five minutes, then make another call to
https://sandbox.itunes.apple.com/verifyReceipt
With my receipt data, I should see the subscription renewed with an expiry date another five minutes out.
Unfortunately that is not the case. All I see is a response with latest_expired_receipt_info and a status of 21006, which means "This receipt is valid but the subscription has expired" according to the Apple docs.
Can anyone tell me if they are able to test auto-renew subscriptions end-to-end, including this renew component? Or do I have to launch this app and cross my fingers that prod will work as advertised?
Alternatively, is there some sort of client-side magic/API call I have to run prior to re-posting my data to the verifyReceipt URL?
There was some discussion on this topic here, but it's not clear to me if I can/should expect to be able to re-verify subscriptions entirely on the server side by posting to the verifyReceipt URL or if I have to do something on the client side too.
Thanks!
Copied from the Apple's Developer Forum, for those not willing to goto the forum...
Figured it out (but not thanks to the Apple docs):
1 month subscriptions auto-renew every 5 minutes. So far so good. They
auto-renew 5 times and then they stop, so after 25 minutes you'll get
the 21006 error. However even when repurchasing the same subscription
it will NOT auto-renew again on the same test account since it has
already auto-renewed 5 times. So if you want to test renewal and you
have been messing with these subscriptions for a while you need to
create a new itunes connect test user. This is very annoying honestly
and it would be a lot easier if we could just reset the entire
purchase history of a test user account. Also putting all in-app
test information in the Xcode documentation would be a lot better as
opposed to spreading it over Xcode docs/iTunes Connect doc/people
figuring stuff out themselves
Hope this helps.
This conversation in the Apple dev forums may shed some light on this issue for others who discover this post: https://devforums.apple.com/thread/105350?tstart=0
#Lata Sadhwani, App developer
For testing auto-renew subscriptions, the expiration time is 5 minutes
in sandbox (at least for the monthly subscriptions, not sure if this
is different for different periods). So when testing an auto-renew
subscription in sandbox, it should auto-renew every 5 mins and you
know they are working correctly.
But there is one problem. These subscriptions auto-renew only 5 times
(i.e. the purchase happens 6 times). After that you'll get an error
when verifying the receipt. So if you want to test after that, you
will need to test with another IAP test account (yes it is a pain
testing, especially if you have been doing this for quite some time!)
To check if a subscription has been cancelled or is valid, your
receipt verification code will need to parse the response from Apple
servers and they say you should verify each receipt. If the
subscription has expired or has been cancelled, the appropriate error
code will be returned (a non-zero status). If it has been renewed by a
user, the most current receipt is returned by the Apple servers.