Query limits to "verifyReceipt" endpoint for auto-renewable subscription status

How often may my server query https://buy.itunes.apple.com/verifyReceipt in order to verify the status of an auto-renewable subscription?


To ask this another way, does this "verifyReceipt" endpoint have a connection limit (either per minute, per hour, or per day) that my server must respect?


(I could find no mention of query limits in https://developer.apple.com/library/mac/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html)


Thanks!

Replies

It is not known. But why would you query the server a second time in a subscription period prior to expected expiration?

As we have various users who purchased the same auto-renewable subscription, we want to check on those users and see if any of them have cancelled their subscription prior to the expected expiration/renewal date. The reason we're doing this is because Apple does not notify us when a user changes their subscription status.


With that in mind, is there another way to get notified by Apple about changes in a user's auto-renewable subscription status besides querying the "verifyReceipt" endpoint on a regular basis? And if not, are there any limits to how often we can query that endpoint?

There are two types of cancellations you might be concerned about.


1) Cancelling an ongoing subscription and getting a refund for the current subscription period. This is very rare. It generates a 'cancellation_date' in the receipt. Worrying about this issue may be a waste of your time since it happens so rarely. And you will detect it in #2 below.

2) expiration of the subscription where the user has decided not to renew using the autorenewable aspect of an autorenewable subscription. A user can decide not to renew by shutting off autorenewing. Your app does not need to worry about this until the current subscription period ends. Usually the device receives a renewal notice 24 hours before the expiration date and that gets processed by your updatedTransactions method. However you can't rely on getting that call. If the app detects that the subscription has expired and not been renewed, and only then, it can check the receipt. No need to check the receipt more often then this one time each subscription period.

Regarding the second type of cancellation we need to worry about, what should we do if the service provided by the subscription is available not only within our iOS app but also on our website - and a user can subscribe in either location?


For instance, if the user subscribes via our iOS app and then logs into our website during their subscription period, we must support their subscription. And if a user subscribes via our website and then logs into our iOS app, we must also support the same subscription.


So if the user enters our website who originally purchased their subscription via our iOS app, we have to check then if their subscription is still active - hence the request to https://buy.itunes.apple.com/verifyReceipt


Does that make sense? And if so, how should we handle it?

Well, before this gets answered, you have to ask whether you are violating 11.1 or 11.2 or operating under 11.14:


11.1 Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected

11.2 Apps utilizing a system other than the In-App Purchase API (IAP) to purchase content, functionality, or services in an App will be rejected

11.14 Apps can read or play approved content (specifically magazines, newspapers, books, audio, music, video and cloud storage) that is subscribed to or purchased outside of the App, as long as there is no button or external link in the App to purchase the approved content. Apple will only receive a portion of revenues for content purchased inside the App


I assume you are operating under 11.14 not violating 11.1 or 11.2.


When the user tries to log into your website from within the app they hand your website their expiration date which is stored, securely, on the device. When they subsequently log into your website directly, not from the app, your website remembers the last expiration date it received. If it has past, your website tells the user they must update their subscription on the website by logging into the website through the app.


Yes, we are operating under 11.14 and not violating 11.2 or 11.2. Let me give an example to help clear things up using LinkedIn.


LinkedIn offers 3 auto-renewable Premium subscriptions via their iOS app: Job Seeker, Business Plus, and Professional. They also offer the same 3 subscriptions via their website at the same price points.


If someone new to LinkedIn purchases one of these Premium subscriptions via the LinkedIn website, that transaction is handled by LinkedIn. And if the purchase is made via the LinkedIn iOS app, that transaction is handled by Apple.


If the purchase is made via the iOS app and, a few days later, the user then sits down at their computer and goes directly to LinkedIn.com on their computer's browser in order to use their new subscription, how is LinkedIn supposed to know the status of this user's subscription without sending a request to "verifyReceipt"?

Because when the purchase was made in the app (or when a auto-renewal was received by the app) the app sent that information to the LinkedIn website.

Don't know whether this issue has been solved, but I think we've encountered the same problem here.

Maybe the LinkedIn eample didn't make things clear.

Assume that a subscription has just renewed and the user hasn't log in using there iOS APP, which means the renewal receipt hasn't been sent to LinkedIn's server, then how could they known this subscription is still valid or has been renewed?

They can't. When a server discovers a subscruiption has gone past its expiration date it can tell the user they need to open the app to refresh their subscription.

Yep, already found that, it seems not that friendly, but currently no other solution can be found.


Thanks Rich.

Now that the receipt includes also the pending renewal info status, we'd want even more to query the validate receipt endpoint in short intervals.

So I resurface the initial question - what is the limit, if exists, to querying the validateReceipt endpoint?


Thanks