Got a new iPhone on your birthday? OK, So you must be using so many cool apps with auto-renewable subscriptions right?
Many deep thinkers must have wondered that what happens when they cancel any subscription on their device? How would the app server know about any subscription changes?
There must be a way right? Of course there is! It is called Server to Server Notifications.
What are App Store Server Notifications?
These are the notifications which App Store sends to your app server when something changes in the subscription. For example- When user cancels the subscription.
“Imagine you are invited for an event and there is a change in plan at last moment as the venue is not available somehow. Now you will not know about the plan change until someone sends you the update through a text or call. Server notifications work exactly like that“
How to set up? You can enable your app server to receive the notifications by setting up a url in App Store Connect. Apple will send you a POST request on this url whenever there is any update in the subscription.
You must be thinking how would you know what kind of update has happened to the subscription. For that purpose you receive notification_type in the request from Apple. By checking this field, you will identify what data you need to update in the database accordingly.
Server Notification types
Although there are many notification types, but you will only use few of them in the real scenario. I will try to explain those few here and rest of them you can check here. At first, it all seems so simple but actually the interpretation will play with your mind. So, it is very important to build understanding for these as it would be much easier to handle the scenario in the code when you functionally understand the notifications.
- INITIAL_BUY : This notification will be received when the user buys a subscription for the very first time.
- CANCEL : You must be thinking that this notification would be received when user cancels the subscription. Wrong ! Actually this is received when user cancels the subscription using customer support.
- DID_CHANGE_RENEWAL_STATUS : This notification would be received when user turns on/off the auto renewal of the subscription through iOS settings, App Store app or Apple Support. auto_renew_status field will tell you whether the subscription has been turned on or off.
Suppose a user takes a monthly subscription on 1st Feb,2021. He does not like the app experience and decides to turn it off on 15th Feb,2021. The app server will receive this notification on 15th Feb.
- RENEWAL : Now, this one is also confusing! By name, it seems that this notification would be received when a subscription is renewed. But actually, this one would be received when the subscription is cancelled automatically due to some billing issue AND then later user started the subscription manually.
I know you are pissed off with all the first wrong interpretations! But bear with me, I will make it easy for you.
Moving on to next one.
- DID_RENEW : This notification would be received when a subscription renews successfully. I know you were looking for this one.
This one was recently added by Apple in 2020.
- INTERACTIVE_RENEWAL : This notification would be received when user cancels a subscription and later re-enables it manually.
- DID_FAIL_TO_RENEW : This notification would be received when the subscription is failed to renew due to some billing issue.
In the example for DID_CHANGE_RENEWAL_STATUS, if Apple is not able to charge the user for the first renewal on 1st March. In this scenario, you will receive DID_FAIL_TO_RENEW status notification on your app server.
A lot to understand right? But if you are able to understand the scenarios for all the notifications correctly, then it would be an easy journey.
OK So, that’s It?
I hope you are now capable to move on to the coding part. This article is in continuation of What does In-App Purchase Mean? Make sure you come back for my next article in which I will cover the handling of the server to server notifications in Python.