In my app’s IAP products, before enabling free trials, the App Store Server Notifications V2 callbacks all returned the correct notificationType. For auto-renewable subscriptions, when they were about to expire, the notificationType was either DID_RENEW or EXPIRED. A small number of cases(DID_FAIL_TO_RENEW) failed to renew due to billing issues, which was expected. However, after I enabled a 7-day free trial for the auto-renewable products, I noticed that in the App Store Server Notifications V2 callbacks, almost all users (except those who manually turned off auto-renewal) received notificationType = DID_FAIL_TO_RENEW. According to the documentation, DID_FAIL_TO_RENEW indicates a billing issue renewal failure, but in this case it seems like all renewals are being marked as failed. I’ve observed that for users who cancel during the free trial, the callbacks look normal: first a DID_CHANGE_RENEWAL_STATUS notification, then an EXPIRED notification when the trial ends. That flow seems
Search results for
DID_FAIL_TO_RENEW
33 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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:
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:
Subscriptions
In-App Purchase
App Store Server Notifications
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:
Hello, I'm currently experiencing issues with IAP subscription setup. The following error appears: Billing Problem, There was a problem with your subscription renewal. To resolve, turn on Allow Purchases & Renewals, or leave off to test failed in-app purchase attempts and subscription renewals. I'm testing with a sandbox account, and automatic subscription renewal is turned on in the sandbox settings. A notification screen appears at the OS level, and consequently, a DID_FAIL_TO_RENEW error occurs on our payment server. I cannot determine the cause at all, so I would appreciate your assistance in checking this issue.
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?
Same problem. Receive notification DID_FAIL_TO_RENEW
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
I'm working in Apple's Sandbox environment to implement in-app purchase of an auto-renewable subscription. I followed the instructions at this link in order to Enable Billing Grace Period: https://developer.apple.com/help/app-store-connect/manage-subscriptions/enable-billing-grace-period-for-auto-renewable-subscriptions. However, when I receive an App Store Server Notification for when the user's billing method fails (DID_FAIL_TO_RENEW), it includes no information about the gracePeriodExpiresDate and we never get a GRACE_PERIOD_EXPIRED notification. Logs showing App Store Server Notification not reflecting Grace Period Enabled. I enabled grace period in App Store Connect like three weeks ago, so it's not a delay there. What can I do to test out Billing Grace Period? Is this just an Apple bug?
Hi. We have recently switched to server notification V2. Based on this documentation (notificationType): If the subtype is GRACE_PERIOD, continue to provide service through the grace period. If the subtype is empty, the subscription isn’t in a grace period and you can stop providing the subscription service. Also, base on another documentation (StoreKit): Throughout the billing grace period, the value of isInBillingRetry is true, which indicates that Apple is attempting to automatically renew the subscription. Now, I'm receiving DID_FAIL_TO_RENEW server notification with GRACE_PERIOD subtype where gracePeriodExpiresDate is in the future, but isInBillingRetryPeriod is false (additional note: user has been in trial period and now must be charged as trial has ended). The question is: Is this situation a valid Grace Period even if user is not in billing retry period? And if yes, please elaborate why this is the case. Thank you!
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
Subscriptions
In-App Purchase
App Store Server Notifications
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:
Hello, I am currently implementing server-side handling for in-app subscription payments and using App Store Server Notifications V2 to receive notifications with a TestFlight account. However, I am not receiving EXPIRED notifications, although I am successfully receiving other notifications such as SUBSCRIBED, DID_RENEW, and DID_CHANGE_RENEWAL_PREF. Here are some details of my observations: Until a certain point, I was receiving EXPIRED notifications without any issues, but they stopped coming in after that point. Each subscription renews every 3 minutes in TestFlight account, and I receive DID_RENEW notifications 7 to 12 times. According to the official documentation, the subscriptions should renew up to 12 times, but I am not receiving exactly 12 DID_RENEW notifications. This inconsistency might be related to the issue. Other notifications (SUBSCRIBED, DID_RENEW, DID_CHANGE_RENEWAL_PREF) are received without any issues. Could anyone provide insight into why this might be happening and suggest any alternati
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
Subscriptions
App Store
App Store Server Notifications
App Store Server Library
Hi, some day ago I got these webhook events for a subscription: 2024-01-06 10:40:47 SUBSCRIBED subtype INITIAL_BUY 2024-01-20 03:02:29 DID_RENEW subtype BILLING_RECOVERY 2024-01-20 03:52:08 DID_CHANGE_RENEWAL_STATUS subtype AUTO_RENEW_DISABLED 2024-01-20 10:41:03 DID_FAIL_TO_RENEW (no subtype was received) When I get the subscription status form appstore server API, status is 1 (active). We don't have grace period enabled in our app. I'm not sure how to interpret this result; from our perspective we should remove access to the user.
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
Subscriptions
App Store Server Notifications
App Store Server API
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:
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:
I received the following notifications (in this order) for the subscription: date, type, subtype 2023-10-09 10:49:17,SUBSCRIBED,INITIAL_BUY 2023-10-16 03:46:44,DID_CHANGE_RENEWAL_STATUS,AUTO_RENEW_DISABLED 2023-10-16 10:49:19,DID_FAIL_TO_RENEW,GRACE_PERIOD 2023-10-16 13:14:36,EXPIRED,BILLING_RETRY What do these mean? Why is there a DID_FAIL_TO_RENEW GRACE_PERIOD notification when the user already disabled auto-renew? Why did it expire in 2.5 hours? Why isn't there a GRACE_PERIOD_EXPIRED notification?
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
StoreKit
App Store Server Notifications
App Store Server API