Search results for

“DID_FAIL_TO_RENEW”

33 results found

Post

Replies

Boosts

Views

Activity

DID_FAIL_TO_RENEW Notification with a null gracePeriodExpiresDate
We are seeking clarification on the behavior of App Store Server Notifications V2. Summary In our production environment, we received a notification with notificationType: DID_FAIL_TO_RENEW and subtype: GRACE_PERIOD. However, the gracePeriodExpiresDate field in the payload was null. We understand this notification indicates that a user's subscription has entered a grace period. The null value for its expiration date is unexpected, and we are looking for an official explanation of this behavior and the correct way to handle it. The Scenario Here are the details of the notification we received: Notification Type: DID_FAIL_TO_RENEW Notification Subtype: GRACE_PERIOD Environment: Production Upon decoding the signedRenewalInfo JWS from the responseBodyV2, we found that the gracePeriodExpiresDate field inside the JWSRenewalInfoDecodedPayload was null. The notificationUUID for this event was in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Our Implementation and its Impact Our backend is designe
Topic: App & System Services SubTopic: StoreKit Tags:
2
0
208
Jul ’25
Reply to Unexpected notificationType in App Store Server Notifications V2 when free trial ends
Additional details: I did not enable a grace period in ASC. For the callbacks where notificationType = DID_FAIL_TO_RENEW, the subtype is empty, and the renewalInfo.expirationIntent is 2. According to the documentation (https://developer.apple.com/documentation/appstoreservernotifications/expirationintent), value 2 indicates a billing error. After 7 days free trial, about 45% of my auto-renewable users remained, but almost all of them are showing DID_FAIL_TO_RENEW. I’m very confused — why would all the remaining users who still have auto-renew turned on be flagged as billing issues? Is this a bug or expected behavior?
Topic: App & System Services SubTopic: StoreKit Tags:
Sep ’25
Reply to Server notifications missing unified_receipt field
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.
Topic: App Store Distribution & Marketing SubTopic: General Tags:
Apr ’21
Reply to subscription do not renews in SandBox
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.
Topic: App & System Services SubTopic: StoreKit Tags:
Feb ’21
Reply to Notification History doesn't include "subtype" in signedPayload
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)
Topic: App Store Distribution & Marketing SubTopic: General Tags:
Aug ’22
Reply to Subscription status mismatch
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.
Topic: App & System Services SubTopic: StoreKit Tags:
Jan ’24
I always recieve DID_FAIL_TO_RENEW
I am testing sandbox subscribe but I always recieve DID_FAIL_TO_RENEW I try to create new sandbox account and clear purchase history but not work can anyone help?
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
1
Boosts
0
Views
137
Activity
Apr ’25
DID_FAIL_TO_RENEW Notification with a null gracePeriodExpiresDate
We are seeking clarification on the behavior of App Store Server Notifications V2. Summary In our production environment, we received a notification with notificationType: DID_FAIL_TO_RENEW and subtype: GRACE_PERIOD. However, the gracePeriodExpiresDate field in the payload was null. We understand this notification indicates that a user's subscription has entered a grace period. The null value for its expiration date is unexpected, and we are looking for an official explanation of this behavior and the correct way to handle it. The Scenario Here are the details of the notification we received: Notification Type: DID_FAIL_TO_RENEW Notification Subtype: GRACE_PERIOD Environment: Production Upon decoding the signedRenewalInfo JWS from the responseBodyV2, we found that the gracePeriodExpiresDate field inside the JWSRenewalInfoDecodedPayload was null. The notificationUUID for this event was in the format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Our Implementation and its Impact Our backend is designe
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
2
Boosts
0
Views
208
Activity
Jul ’25
Reply to Subscription status mismatch
Thank you for your answer. So to recap, when we receive a DID_FAIL_TO_RENEW event after a DID_RENEW: BILLING_RECOVERY, we must discard the DID_FAIL_TO_RENEW one, is that correct?
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Jan ’24
Reply to Billing Problem while subscription renewal.
Same problem. Receive notification DID_FAIL_TO_RENEW
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Apr ’25
Reply to Subscription user renew success but backend server received event renew fail
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.
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Jul ’23
Reply to In Auto-renewable subscriptions auto payment error
I can't check because I can't generate DID_FAIL_TO_RENEW in the sandbox environment. Can someone please help me?
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Jul ’22
Reply to Testing In App Purchase Server to Server Notifications Sandbox
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 ?
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Mar ’23
Reply to Unexpected notificationType in App Store Server Notifications V2 when free trial ends
Additional details: I did not enable a grace period in ASC. For the callbacks where notificationType = DID_FAIL_TO_RENEW, the subtype is empty, and the renewalInfo.expirationIntent is 2. According to the documentation (https://developer.apple.com/documentation/appstoreservernotifications/expirationintent), value 2 indicates a billing error. After 7 days free trial, about 45% of my auto-renewable users remained, but almost all of them are showing DID_FAIL_TO_RENEW. I’m very confused — why would all the remaining users who still have auto-renew turned on be flagged as billing issues? Is this a bug or expected behavior?
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Sep ’25
Reply to DID_FAIL_TO_RENEW Notification with a null gracePeriodExpiresDate
Hi, We are also facing similar issue in sandbox, We are unable to get GRACE_PERIOD subtype while DID_FAIL_TO_RENEW. subtype is coming as empty even after we have configured the grace period. Can you please confirm, if you are getting GRACE_PERIOD subtype in Sandbox environment?
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Jul ’25
Reply to App store server notification on end of free trial period
There could be a couple cases, but generally it would be DID_RENEW (so the sub renewed) or DID_FAIL_TO_RENEW if the sub entered grace period or billing retry. A free trial ending is a subscription renewal like a regular subscription renewal.
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Jul ’24
Reply to AppStore Server Notification sent a different type from the real one
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?
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Apr ’23
Reply to Server notifications missing unified_receipt field
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.
Topic: App Store Distribution & Marketing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Apr ’21
Reply to subscription do not renews in SandBox
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.
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Feb ’21
Reply to Notification History doesn't include "subtype" in signedPayload
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)
Topic: App Store Distribution & Marketing SubTopic: General Tags:
Replies
Boosts
Views
Activity
Aug ’22
Reply to Subscription status mismatch
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.
Topic: App & System Services SubTopic: StoreKit Tags:
Replies
Boosts
Views
Activity
Jan ’24