“DID_FAIL_TO_RENEW”

In this case, the DID_FAIL_TO_RENEW notification was sent after the subscription was successfully recovered. When you received the DID_RENEW subtype: BILLING_RECOVERY, that was when the subscription recovered. Shortly after that, auto renew was disabled. The subscription status API is still returning status=1 because the subscription is still active until it expires, and that is also why you see a new transaction in the response from the transaction history endpoint. Based on the information you have shared, refund history should not return anything as nothing was cancelled.

I received the event name DID_FAIL_TO_RENEW. However, when I decoded the transaction from the notification, the transaction renewal was successful, with the expiresDate extension.

Thank you for answering this question. I saw the history of that subscription using 'GET https://api.storekit.itunes.apple.com/inApps/v1/notifications/history' endpoint. But i didn't find out any type of DID_RENEW and subtype BILLING_RECOVERY. Should i have to check for purchase history when i got a DID_FAIL_TO_RENEW notification?

Same here. After disabling Allow purchses & Renewals to simulate a billing issue, we only get the DID_FAIL_TO_RENEW with null subtype. Were you able to find a solution to this ?

Hi, thank you for quick response, basically for non of the notificationType which can have notificationSubType DID_CHANGE_RENEWAL_STATUS => subtypes [AUTO_RENEW_ENABLED, AUTO_RENEW_DISABLED] EXPIRED => subtypes [VOLUNTARY, BILLING_RETRY] SUBSCRIBED => subtypes [INITIAL_BUY, RESUBSCRIBE] DID_FAIL_TO_RENEW => subtype [GRACE_PERIOD], DID_RENEW => subtype [BILLING_RECOVERY], We receive all subtypes correctly using App Store Server Notifications V2 but not from App Store Server Api (https://developer.apple.com/documentation/appstoreserverapi/get_notification_history)

I can't check because I can't generate DID_FAIL_TO_RENEW in the sandbox environment. Can someone please help me?

Here are more examples of the complete notification body received affected by this bug, I only filtered some data with [Filtered] keyword: { auto_renew_product_id: [Filtered], auto_renew_status: true, bid: [Filtered], bvrs: [Filtered], environment: PROD, notification_type: INITIAL_BUY, password: [Filtered] } { auto_renew_product_id: [Filtered], auto_renew_status: false, auto_renew_status_change_date: 2021-07-15 14:10:14 Etc/GMT, auto_renew_status_change_date_ms: 1626358214000, auto_renew_status_change_date_pst: 2021-07-15 07:10:14 America/Los_Angeles, bid: [Filtered], bvrs: [Filtered], environment: PROD, notification_type: DID_CHANGE_RENEWAL_STATUS, password: [Filtered] } { auto_renew_product_id: [Filtered], auto_renew_status: false, auto_renew_status_change_date: 2021-07-15 10:48:29 Etc/GMT, auto_renew_status_change_date_ms: 1626346109000, auto_renew_status_change_date_pst: 2021-07-15 03:48:29 America/Los_Angeles, bid: [Filtered], bvrs: [Filtered], environment: PROD, notification_type: DID_CHANGE_RENEWAL_STA

We also experience this for the last few weeks for some statusUpdateNotifications in production environment. We receive following request body which is unusable for matching with our database: #Header: (…Content-Length, 263)] #Body {notification_type:REVOKE,password:xxxxxxxxx,environment:PROD,auto_renew_product_id:com.xxx.xxxx.macos.subscription.yearly,auto_renew_status:false,bid:com.xxx.xxx.macos,bvrs:2021.1.3} We experienced those reduced bodies for REVOKE, DID_RECOVER, DID_FAIL_TO_RENEW, DID_RECOVER types.

I am seeing the same behavior with sandbox purchases on macOS: first purchase with a new sandbox user succeeds then fails to renew with DID_FAIL_TO_RENEW subsequent purchases with the same user succeed then are canceled at renewal time with 'expiration_intent': '1' Is the issue still under investigation? What were the results of the previous investigation @rkubota ? As it stands now we have no way to test subscription renewal other than to deploy to production and pray.