We experienced an issue with delayed App Store Server notifications for an Auto-Renewable Subscription purchase in our app. On September 27, 2024, at 22:28:28 GMT+0900, a user successfully purchased a Premium membership subscription (transaction ID: 190002223966278, webOrderLineItemId: 190001007274949). However, our server did not receive the corresponding App Store notification for this transaction after purchase. The App Store Server Notification was only received 66 minutes later, at 23:35:16 (transaction ID: 190002224000004, webOrderLineItemId: 190001007274949). The delayed notification contained a different transaction ID than the initial purchase. We would like to inquire about the cause of this delay and request assistance in understanding why the notification took 66 minutes to be delivered to our server, instead of arriving immediately after the transaction was completed. Additionally, we would appreciate your guidance on how to prevent or mitigate such delays in the future, ensuring a seamless experience for our users. Are there any best practices or recommended approaches we should implement to handle potential notification delays more effectively? We have provided detailed information about the received notification and the related transactions in the Feedback Assistant (FB15330451). Thank you for your assistance in resolving this matter. Key Details Purchase time: 2024-09-27T22:28:28 GMT+0900 (1727443708000) Notification received: 2024-09-27T23:35:16 GMT+0900 (1727447716463) Delay: 66 minutes and 48 seconds Initial Purchase Transaction ID: 190002223966278 Initial Purchase Web Order Line Item ID: 190001007274949 Transaction ID in Delayed Notification: 190002224000004 Web Order Line Item ID in Delayed Notification: 190001007274949 Additional info Bundle ID: com.reppley.ReppleyApp SKU: com.reppley.ReppleyApp Feedback Assistant Number: FB15330451

My App uses an auto-renewal subscription, and I've been using the CONSUMPTION_REQUEST event to track user refund requests. However, since yesterday morning, I haven't been receiving any CONSUMPTION_REQUEST notifications. All other notifications are functioning normally and I haven't changed anything. What could be the issue?

I have set up server notification in my app. I have set up only production server URL and through that URL I can check "CONSUMPTION_REQUEST", "REFUND" notificationType. However, I want to check all notifications for in-app purchases. For example, "ONE_TIME_CHARGE" which is consumable in-app purchase type. If I want to check more notificationTypes on my server, Do I need to add another setting? Test notifications are also checked in my server. https://api.storekit.itunes.apple.com/inApps/v1/notifications/test

We haven't received App Store server notifications in 2 days. When we know we should be. I know the v1 notifications have been deprecated and we need to migrate. But have they now been totally disabled? I can't seem to find any documentation that says they were/will be?

I would like to clarify, do I understand correctly that Cancel and Refund events essentially have the same meaning, except that Cancel cancels the subscription, only the Cancel event applies to auto-renewable subscriptions, and refund applies to one-time purchases and non-renewable purchases?

I am developing and implementing App Store Server Notification V2 for IAP for renewable subscription and consumables for an app My current flow is on receiving notification from apple, I will process the notification (e.g activate subscription, cancel subscription, etc.). But the ONE_TIME_PURCHASE notificationType only received in sandbox environment, the docs also said the same The ONE_TIME_CHARGE notification is currently available only in the sandbox environment. What is the best way for me to process user ONE_TIME_CHARGE transaction of consumables using App Store Server Notification V2 on production build app? Thank you

Dear Apple Development Team, I would like to draw attention to certain aspects of working with Server Notifications for In-App Purchases that could be improved to enhance development convenience and API efficiency. 1. Lack of Information on Non-Consumable Purchases in Server Notifications Currently, Server Notifications do not provide information about non-consumable purchases. This creates certain inconveniences when validating such purchases on the server. It would be extremely useful to have the ability to verify non-consumable purchases in the same way as subscriptions. Moreover, there is currently no way to obtain information about the amounts paid for non-consumable purchases, even with additional API requests. This limitation significantly complicates financial reporting and analytics for apps that utilize non-consumable purchases. While we can obtain information about the amount paid by the user for a subscription, we have no equivalent capability for non-consumable purchases. Adding this information to Server Notifications or providing an API endpoint to retrieve it would greatly improve our ability to track and analyze non-consumable purchase data without relying on client-side reporting. 2. Inconsistency in Token and Signature Handling There is some inconsistency in the approaches to authentication and verification between various Apple APIs. For example: When using Sign In with Apple, the approach with keyid is applied for JWT verification. In Server Notifications for In-App Purchases, certificate information is repeatedly duplicated in each notification. This leads to the need to implement different methods of JWT verification depending on the API being used. Additionally, the current approach with Server Notifications results in data redundancy: the useful payload is about 1.5 KB, while repetitive certificate information takes up about 17 KB in each notification. Unifying authentication and verification approaches across different APIs could significantly simplify development and improve data processing efficiency. We would appreciate consideration of these suggestions for API improvement. This could substantially simplify developers' work and increase the efficiency of integrating Apple services into applications. Thank you for your attention to this matter.

Hello, I'm using 'App Store Server Notifications V2'. I have a question about 'CONSUMPTION_REQUEST' notification in 'notificationType'. What problems can occur if the send consumption information API is called without user consent? For example, could there be penalties such as refusing to update the app or blocking the service?

I have triggered few notifications, and they were delivered to my iPhone with a delay of several hours. Could you please assist us in resolving this issue? Device: iPhone 15 OS Version: 17.5.1

Sever notifications v1 is already deprecated and we are supposed to use the new v2 server notifications and yet arguably the most important notification type is not available for production.

Is there an explicit service compensation somewhere if App Store Server Notifications goes down? This question is about wanting to know the SLA.

Hello we set 'App Store Server Notifications' production, Sandbox Server urls to be the same. in Sandbox mode we can receive 'ONE_TIME_CHARGE notification when buy items but in production we can't receive any notification when buy items, request refunds how do we solve this problem ?

Hi We want to migrate App Store Server Notifications from V1 to V2 in production, but I don't want to miss any notifications during the migration. We already have a V1 url to receive notifications. If we edit it to a new url and choose V2, will it be effective immediately? Will there be any notifications lost during the transitions? Thank you!

I have accessed the third-party payment Qonversion, which has been uploaded to testflight, and some phenomena such as purchase failure or purchase waiting time out occurred when the customer used it ​The Qonversion developer replied that there were too many requests for this account and needed to change the account, is that right ​Do you need to change your account? How do you return the account? I want to know how testflight can correct the sandbox account instead of its own account

https://developer.apple.com/documentation/appstoreservernotifications/app_store_server_notifications_version_1 It says that v1 is deprecated, but we have a lot of servers use v1, and we have to no time to update server code to move v1 to v2. So my question is, even v1 is deprecate, but if we don't need the new notification types in v2, can we still receive v1 notifications? cuz I can't find anywhere says when v1 will stop sending.

Hello, previously i have tested the purchase via test flight and the server notification was sent to my sandbox url. Now when I made the purchase from live app, my server did not receive any notification even though the production url was the same as the sandbox url. The purchase was for a consumable product. Please help, thanks.

Experiencing 403s (InvalidProviderToken) [https://api.push.apple.com/3/device/] due to invalid or unverifiable provider tokens. We have noticed that after retrying the request inline, the notification is delivered successfully without any changes to the request even with same authorization token. Someone please guide or suggest why it is happening as the JWT token which is generated is correct because we are caching the jwt token and using the same token to send out the subsequent request which is kind of successfull. Sending the notification for multiple team Ids under the same application.

Tried all these steps Force restart DIsabled focus mode Notifications are enabled in both device and in app settings Disabled summary notifications. Tried sending notification from pusher tool, that also is not showing up in the center. What could be the reason and a possible solution?

Greetings for App Store Server Notifications especially sandbox (I have not tried production) it seems that that is no way to associate two transactions to their orignal subscription instance the docs indicate webLineItemOrderId id but they are different from each subscription the originalTransactionId is the same among all subscription instances and customers, theres originalPurchaseDate but that is not reliable becuase 2 transactions can occur on the same date what can be done here. I even tried to use it but its like the sandbox is broken with the originalPurchaseDate of one instance being the same as another. is it a bug or will things get in line once I go to production?

platform: Please let me know which platform 'Non-Apple platform' is referring to. For example, Google or Amazon? And is it correct to mean the platform that consumed the products received due to in-app purchases? playTime: Does 'playTime' mean the time when the customer purchased the app and actually accessed the app? Or do you mean the time you accessed after the in-app purchase? lifetimeDollarsPurchased/lifetimeDollarsRefunded: If the app has multiple accounts for that customer, is the purchased/refunded amount for all accounts?