I am setting up server-to-server notifications for auto-renewable subscriptions in my application.
I recieve many of the various type of notifications: INITIAL_BUY, DID_CHANGE_RENEWAL_STATUS, RENEWAL, DID_RECOVER, etc..
When I receive the notifications from apple I verify the receipt, do some business logic and return a 200 if everything goes well and a 500 if not.
I've found that I often don't receive the expiration notifications for subscriptions, therefore I would have users who are not paying who will retain access to content.
It also appears that the server to server notifications that I receive are not consistent.
For example, if 3 users opt-in and become subscribers, the server to server notification I receive from apple from start to (a potential, but possibly never received) expiration vary in what seems to be a random way.
User 1: INITIAL_BUY, RENEWAL, DID_RECOVER, DID_CHANGE_RENEWAL_STATUS, INTERACTIVE_RENEWAL (this was the cancel)
User 2: INITIAL_BUY, DID_CHANGE_RENEWAL_STATUS
User 3: INITIAL_BUY, DID_RECOVER, RENEWAL
There seems to be no consistency in testing subscriptions and what to expect from server to server notifications.
It's also to my understanding that apple doesn't send a server to server notification if a currently active subscription succesfully renews for another month (or whatever interval). Therefore if you want to always have the most up to date expiration date, you'd have to poll their /verifyReceipt route.
It seems to me that polling apple every so often after the INITIAL_BUY is the way to go and that the server to server notifications aren't actually providing that value that one would assume.
Two questions that arise out of all of this are:
1. Can I expect the same weirdness in the non-sandbox environment
2. How have some of you solved this issue if it's actually as inconsistent and un-informative as I've experienced? Do you just rely on polling or have some of you implemented full subscription handling solutions that work just through the server to server notifications?