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
137
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:
3d
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