Should iOS non-renewing subscriptions be checked regularly?

4
votes

I'm currently implementing In-App purchases for our iOS Application. Specifically, I'm currently working on Subscriptions. We offer several terms for non-renewing subscriptions (1 month, 3 months, 6 months), and an auto-renewing subscription that lasts 1 month at a time. I've set up a system that will check overnight if an auto-renewing subscription is still valid and has not been refunded yet with Apple's receipt verification servers. For auto-renewing subscriptions, I can limit this to purchases made in the last month, since after that I should have either a new transaction for this user, or the subscription has expired.

My question is, however, if non-renewing subscriptions also need to be checked regularly, specifically for updates in the cancellation_date field. In the Receipt Validation Programming Guide, the cancellation_date field does not say that it is only specific to auto-renewing subscriptions. However, several other pieces of documentation and answers (excuse me for the lack of links here) have suggested that this is something you only need to check for updates in auto-renewing subscriptions.

I think that the only reason non-renewing subscriptions are always returned in the transaction receipt are so that apps that do not store this information on their server can restore a user's subscription. However, if the transaction is also updated if any changes occur in the payment, I would very much like to keep an eye on that information as well.

Since we have a large number of users, and having to check either only the payments for the last month or all payments made in the past 6 months makes quite a big difference, I would like to hear your opinion (and hopefully experience) in this regards.

1
iosin-app-purchase
Note that I'm looking for actual experience with this issue, or otherwise some compelling evidence. Simply 'I would guess...' does not help me much, since that's as far as I've gotten myself at this point ;) - Erik S
@Erick do you have any GitHub repos/sample code showing this system you have polling Apple's servers and verifying the users' who are subscribed to your system? I'm encountering the exact same issue right now. - GGCO
We do not, since our company's code is not open-sourced. There are a bunch of examples of parts of the system around the internet, however. Basically, your workflow will be 'purchase in app' -> 'send receipt to your server' -> 'verify receipt with Apple' -> 'store subscription status/error in your database' -> 'tell your app the most recent subscription information for your user'. A few of those parts are purely your own implementation for app and server, but parts like 'verify receipt with Apple' have a lot of examples on the internet. - Erik S
Doc says that once you finish the transaction, you can no more retrieve the information about non-renewing subscription purchase in receipt. Can you? - Stanislav Smida

1 Answers

2
votes

I think the amount of users that would try to cheat your system is likely to be a small percentage. If you're that paranoid, you should check all subscriptions anyway. You should probably get some statistics on the number of users who cheat in app purchases. Weigh up the cost of checking with the amount you stand to lose by not checking by how much the money matters to you. I personally find it greedy to meticulously check and make sure that your system is totally cheat-proof: especially when you're selling software – when stolen copies don't cost you anything.