Our Server always receive about DID_FAIL_TO_RENEW when first subscription
Search results for
DID_FAIL_TO_RENEW
33 results found
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I tried multi sandbox account and read this post: https://forums.developer.apple.com/thread/130456We have the same problem for some accounts: DID_FAIL_TO_RENEW and the expiration_intent = 4 (The product was not available for purchase at the time of renewal.)While if we tried a new account or simply buy the goods manually, it works and gives us a new transaction id.Because of the experience, I can't test the auto subscription. I read the document and it said the transaction id is unique for buying and renewal, but I never see new transaction-id except manually buy.Is it a regular performance?
When does Apple plan to support a server notification for when a subscription auto renews? Best I can tell from the documentation and online articles there doesn't appear to be a notification type for this scenario. There are notifications when a renewal fails because of billing issues (ie DID_FAIL_TO_RENEW), when a previously expired subscription gets renewed (ie DID_RECOVER), and when a user interactively triggers a renewal (ie INTERACTIVE_RENEWAL). But nothing for when a user transitions from say a trial to an automatic renewal. Seems like a pretty big gap for a subscription-based notification system.
I'll preface by saying I'm very new to working with Apple subscriptions and my question is probably quite silly, but I can't find any information on this topic. What I am currently stumped about is the handling of grace periods for service-level downgrades that have experienced billing failure. As an example, the user wants to downgrade from Product B to Product A. The products are in different service levels and have different durations, so the downgrade is scheduled for the next renewal. When that time comes, billing fails and our server receives a DID_FAIL_TO_RENEW notification. How should such a case be handled? If a grace period is in place, should that grace period apply to the original subscription (to Product B), the new subscription (to Product A) or both? Thanks in advance
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
App Store
Subscriptions
StoreKit
App Store Server Notifications
Greetings, New to iOS App Store connect - not new to engineering. We have a SaaS offering that we are building an iOS app version of. We are supporting IAP Auto-Renewing Subscription for users that find us through the app store. I am trying to understand the flow of the notifications so that we can effectively maintain subscription state across Web & iOS. Would be great if someone could validate or correct our understanding as follows: User subscribes to monthly auto-renewing subscription. Subscription information passed from app to server. Receipt is validated and transaction_id is stored with the users account. INITIAL_BUY s2s notification is received containing the corresponding transaction_id At this point the subscription is active and we won't receive any other s2s notifications unless the subscription is cancelled / not renewed. At some point in the future, we may receive one of which would indicate that the subscription is inactive and needs attention: CANCEL DID_FAIL_TO_RENEW In addition
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:
I don't know how Apple expects us to verify that the code that handles server-to-server notifications is working correctly. I can't think of how to test that the full cycle of operation is correct, because I don't want to test the code directly in production, and in the sandbox not all notifications are handled. For example, I don't know how to simulate that a user asks AppleCare to revoke a subscription. On the other hand, in the test purchases I have made I have received DID_RECOVER notifications, which are not supposed to be available (as indicated in https://developer.apple.com/documentation/appstoreservernotifications/notification_type#3694879 ), but also the DID_RECOVER is not preceded by a notification of failure to charge (DID_FAIL_TO_RENEW). Does anyone have any suggestions on how to test? Thank you very much, Oscar
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:
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
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
I have been testing server to server notifications but I am not sure of getting the following notifications on sandbox. I have enabled the grace period on my app store connect account but how to fall the billing to be failed to renew and test grace period concept. Can any one help me on the actions to be performed for getting following notifications on Sandbox? 1, DID_CHANGE_RENEWAL_STATUS -> AUTO_RENEW_ENABLED, AUTO_RENEW_DISABLED 2, EXPIRED -> BILLING_RETRY 3, GRACE_PERIOD_EXPIRED 4, DID_FAIL_TO_RENEW -> GRACE_PERIOD 5, DID_RECOVER 6, REVOKE
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:
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:
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:
Recently I got CS. The customer paid for a subscription renewal but he didn't get a benefit from the subscription. I looked up for server notification logs and saw the latest server notification type was did_fail_to_renew. Also, i requested a transaction history from AppStore Server API(GET https://api.storekit.itunes.apple.com/inApps/v1/history/{originalTransactionId}). The auto_renewable_subscription_purchase was successfully purchased. I don't know why AppStore sent the wrong notification type. Can you answer the question? Thanks
Topic:
App & System Services
SubTopic:
StoreKit
Tags:
In-App Purchase
Subscriptions
App Store Server Notifications
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: