When does Apple send the "INTERACTIVE_RENEWAL" Subscription Notification?

Brennan,

The following is a clarification of the RENEWAL and the INTERACTIVE_RENEWAL server update notification types

RENEWAL - Automatic renewal was successful for an expired subscription. Check Subscription Expiration Date to determine the next renewal date and time.

Clarification - in general, iTunes will attempt to charge the user account a day before an auto-renewing subscription is scheduled to expire. If the renewal is successful, there is no server-to server notification because the auto-renewing subscription did not enter into an expired state. However, in the few cases that iTunes is unable to renew the subscription (generally there was a connection problem with the credit card server) and the auto-renewing subscription is not renewed before the expiration_date passes, the auto-renewing subscription is technically considered “expired”. However, iTunes will still continue to attempt to renew the subscription. It iTunes is successful, then the “RENEWAL” event is sent. for this reason, the advice is presented - “Check Subscription Expiration Date to determine the next renewal date and time.”

For a normal renewal which is successful before the subscription actually expires, validate the appStoreReceipt and check the contents of the latest_receipt_info to verify that there is an auto-renewing subscription in-app purchase item where the expires-date is later than the current date.

INTERACTIVE_RENEWAL - Customer renewed a subscription interactively after it lapsed, either by using your app’s interface or on the App Store in account settings. Service is made available immediately.

Clarification - If a customer purchases an auto-renewing subscription then after some period of time, allows the subscription to expire, that is their choice. However later on, iTunes provides the user the option to restart the auto-renewing subscription in their account -> Subscription page. Alternatively, the user could purchase the AUTO-RENEWING SUBSCRIPTION in the app. When either event occurs, iTunes sends this notification.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

"For a normal renewal which is successful before the subscription actually expires, validate the appStoreReceipt and check the contents of the latest_receipt_info to verify that there is an auto-renewing subscription in-app purchase item where the expires-date is later than the current date."

How would we get the updated receipt? You mentioned above "If the renewal is successful, there is no server-to server notification", so we would not get a server notification to update the receipt.
How would we be able to check the latest_receipt_info in that case?
Are you implying that by storing the original receipt, we will be able to automatically get new expires-date if the renewal was successful?

The receipt validation server validates appStoreReceipts which have an auto-renewable subscription item in the in_app array, in a special manner. If your server process saves the original appStoreReceipt for an auto-renewable subscription purchase, then the verifyReceipt server will provide a listing of all renewal transactions which have occurred for In-App Purchases occurring within that subscription group. All of the renewals will be listed in the latest_receipt_info section if the "exclude-old-transactions" key is not included (or set to false).

For example, if your server has the appStoreReceipt for customer A where they made the first purchase of your monthly auto-renewable subscription, then if your server validates that receipt on month later, when the renewal has been made successfully, the validated in_app array would still show a single entry for the original purchase, but the latest_receipt_info would include the renewal.

In the user's copy of the app, assuming that the app installs the transactionObserver at app launch time, the transactionObserver would detect the renewal transaction the first time the user launches the app after the renewal has occurred. However, in the case that the user doesn't launch the app, the mechanism described above makes it possible for your server to know that the renewal has occurred successfully.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

This is very confusing. We have to use an old receipt to determine if a new event occurred? Why do we have to query a receipt validation server to see if the renewal happened? I must be missing something. Apple should simply send a server notification if and when the renewal occurred, and send an expiration notification when the subscription expires.

Google handles server-to-server subscription notifications significantly better than Apple. With Google, if there's an event that impacts the state of the subscription, you get a notification. When the user purchases, you get a notification. When the users renews each month, you get a notification. When the user cancels, you get a notification. When the subscription expires, you get a notification. That's very simple and covers the majority of use cases developers care about.

Am I completely misunderstanding something here?

I'm just the messenger here. You make some great points. I would suggest that you and every developer that feels similary, use the Apple Feedback Assistant URL to submit an enhancement request that the App Store Server team implement RENEWAL notifications for all renewal transactions. The Apple Feedback Assistant URL is <https://feedbackassistant.apple.com>

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

Sorry Rich. I didn't mean to hit you over the head with this. It's just a very frustrating development experience.

I agree with peter.y.

It's being a very frustating development experience... Notifications that you can't test in Sandbox, fields that don't exist in Sandbox, notifications that don't arrive on time,...

Rich, is it possible that INTERACTIVE_RENEWAL is sent when the change in the subscription is to be applied instantly, and that DID_CHANGE_RENEWAL_PREF is sent when the change is to be made at the end of the current subscription?

Perhaps these article in RevenueCat.com can be relevant (you'll have to reconstruct the URLs from fragments, that I can't post it in the right way):

• https://

www.
revenuecat.com/blog/ios-subscription-groups-explained

• https://

www.
revenuecat.com/blog/apple-subscription-notifications-are-almost-useless