As Apple doc said in this doc: https://developer.apple.com/documentation/appstoreservernotifications/notification_type?changes=_2
Subscription event | Notification types triggered
-----------------------------------------------------------------------------
.
.
.
Auto-renewal disabled (canceled) from
the App Store account's Subscriptions settings | DID_CHANGE_RENEWAL_STATUS
AppleCare refund | CANCEL, DID_CHANGE_RENEWAL_STATUS
When AppleCare refund happend, there are two notification types triggered, one of them is DID_CHANGE_RENEWAL_STATUS. And when cancel subscription happened, its notification type is DID_CHANGE_RENEWAL_STATUS too. So, when i got a notification with notification_type DID_CHANGE_RENEWAL_STATUS, how could i know whether the user has refunded or canceled?
I don't know why Apple triggers CANCEL as well as DID_CHANGE_RENEWAL_STATUS, but technical it is correct. The user cancels his subscription (you get the CANCEL notification) and this also changes the renewal status (you get the DID_CHANGE_RENEWAL_STATUS notification—obviously the subscription won't renew in the future).
To your question: you know a refund happend when you receive the CANCEL notification and when the server response body with the DID_CHANGE_RENEWAL_STATUS notification contains the cancellation_date_ms in Latest_receipt_info.
cancellation_date_ms
The time and date that Apple customer support canceled a transaction or the time and date the user upgraded an auto-renewable subscription.
see here for more details.
Don't worry in the case that a user upgrades his subscription, your server will receive additionally to CANCEL and DID_CHANGE_RENEWAL_STATUS the INTERACTIVE_RENEWAL notification.
In the case the user canceled (deactivated auto-renew) the field auto_renew_status (documentation) in the response body is set to 0.
Related
I generally understand receipt validation on In App Purchases. Most libraries make this as simple as calling a method.
I'm not so clear on how subscriptions work though -- specifically, how can I detect if the subscription is cancelled?
Subscriptions are cancelled on Apple's iTunes interface only. How is my server supposed to know that a subscription was cancelled?
From the Apple docs:
The user can also cancel their subscription by disabling auto-renew and intentionally letting their subscription lapse. This action triggers the App Store to send your server a status update notification of type DID_CHANGE_RENEWAL_STATUS. Your server can parse the auto_renew_status and the auto_renew_status_change_date to determine the current renewal status of the subscription.
https://developer.apple.com/documentation/storekit/in-app_purchase/subscriptions_and_offers/handling_subscriptions_billing#3221914
The answer from Jacob is correct for the case that the user disables the auto-renewal of his subscription. If the user requested a refund from Apple and they cancel the subscription for him. Your server will receive a CANCEL notification and the receipt will contain a cancellation_date field.
You need to handle both of those cases, because when the user cancels (deactives the auto-renewal) his subscription, it is still valid (till it expires). When Apple customer support cancels the subscription, then it is from this point on invalid.
Note: the CANCEL notification is also triggered when a user up- or downgrades to a different subscription of the same subscription group. See this answer for more details on that.
We have a problem with Apple subscription callback on Sandbox environment. When I purchase an auto-renewable subscription on Sandbox env, apple sends first callback only after 1-2 min. It's ok. But when the first expiration period ends apple not always notify us about extending a subscription. But we should receive notification_type = RENEWAL always at the end of the expiration period. Sometimes we receive notifications sometimes we don't. Do you know how can we check where is the problem? Maybe Apple has some troubles because we couldn't find any problems on our side.
RENEWAL events are sent when a subscription has expired, then later, the user starts the subscription again.
See: Apple Subscription Notifications are Almost Useless
We have setup Apple’s Server notifications for auto-renewable subscriptions. Last month we still able to get all notification type(INITIAL_BUY, RENEWAL, INTERACTIVE_RENEWAL).
Recently when we tested with sandbox (1 year subscription), we receive only 'INITIAL_BUY' server notifications, we were expect to receive 'RENEWAL' server notifications after 1 hour, but we are not getting those notifications.
Question:
I just want to confirm that is it a new notifications service that only send us 'INITIAL_BUY' notifications? And there are no server-to server notification if the renewal is successful?
Note:**
We did validate receipt with verifyReceipt server to check latest_receipt_info.
Correct. According to this technical note (https://developer.apple.com/library/archive/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-SUBSCRIPTIONS-MY_SERVER_PROCESS_RARELY_RECEIVES_RENEWAL_NOTICES_WHEN_THE_AUTO_RENEWING_SUBSCRIPTION_RENEWS_)
The App Store attempts to charge the user account 24 hours before an auto-renewing subscription expires. If the renewal is successful, there is no server-to server notification because the auto-renewing subscription did not enter into the expired state.
You have to actively call Apple's receipt validation endpoint on or around the expiration date of each receipt (and possible for a few days after that) to fetch the renewal receipts. Apple will not notify your servers.
I created an API to be called by Apple webhook to work with subscription. I've set the API url in Itunes to be called by the webhook.
According to Apple help site https://help.apple.com/app-store-connect/#/dev7e89e149d in regards to the Testing Auto-Renewable Subscription, when testing auto renewable subscriptions in the test environment, the Apple webhook will make a call to the API after 5 minutes if I select 1 month subscription duration.
But the thing is, after making first purchase, apple webhook doesn't follow up call to the API that I created to renew the subs. Even after I waited for more than 5 minutes. So I can't do any processing from the API to renew user subs in the database.
Is there some configuration that I had to make in order to test the auto renew and make apple webhook call the API to renew the sub?
We've found that Apple's subscription update webook calls are rather unreliable.
Based on experience:
Don't count on Apple to notify you of renewals. The notification may arrive arbitrarily late (often leaving a "gap" in time), or not at all. We've resorted to retaining and retrying the original iTunes-provided receipt to revalidate renewals at the end of subscription periods --the expiration dates will change to account for the renewal.
Don't count on Apple to notify you of cancellations, either. Same as above, calculate subscription duration, and retry receipts at the end of a period (the expiration date will NOT be updated if the subscription is cancelled).
Generally, this involves mapping the additional transactions/in_apps that are returned with the retried receipt to the original_transaction_id --and updating the expires_at accordingly on your end.
Hope this helps!
Update: In WWDC2020 Apple announced that they add a new notification type called DID_RENEW which will be sent after any successful auto-renew. More info on that in this video, starting at around 16:00.
Original answer:
I can't find the page you linked to, however this page may shed light on the subject (emphasis by me):
The App Store attempts to charge the user account 24 hours before an auto-renewing subscription expires. If the renewal is successful, there is no server-to server notification because the auto-renewing subscription did not enter into the 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. iTunes may continue to attempt to renew the subscription. If iTunes is successful, then the RENEWAL event is sent.
Meaning, you're not supposed to receive notifications for renewals, but only for cases where the subscription became expired and only then renewed. This might be the case for sandbox renewals as well.
How can we cancel an auto Renewable subscription from itunes and get a call back in our server?After getting cancelled from itunes I should get notified in my server or in phone so that I can call cancel subscription in my server.
I read something like this somewhere
" When you hit apple server with the last receipt you have saved, it
will return you the code for cancellation of subscription"
My doubt is:
Is there any specific error code returned in case if the subscription is cancelled?
I have a cancel button inside my app to cancel subscription.What I think of doing is to redirect to the setting ->manage subscriptions page for now.After cancellation How can I get notified about this?
OR,shall I set a cron in the backend to check for cancellation?