Hello, we recently switched to the V2 notifications and we are noticing some odd requests. In general all works as expected, except that we are receiving some empty notifications i.e. the body if blank. Has anyone experienced the same issue? Is this a normal behaviour and if so how should we handle it? Thank you in advance. Greetings, Ilian

I stopped receiving status notifications on my app. I have to contantly log to see if my app build went through review. I was getting them, and i do get them for other apps I am admin on. The one I create and manage, I’m not getting emails.

Hi, I am processing both REFUNDED and REVOKED transactions on the client-side and on the server using Apple's App Store Server Notifications (V2). For transactions with an inAppOwnershipType of FAMILY_SHARED, I receive REVOKE notifications that (sometimes) do not include a revocationDate. What does this imply, and what actions should I take? Additionally, when I query their transaction IDs using the App Store API, they also lack a revocationDate and do not appear in the results when I filter for revoked transactions. Is it appropriate to block these users? Why are server-to-server REVOKE notifications sent in the first place if the transaction does not appear as revoked in the API? Thanks

Hi I'm working on IAP for my app, with all products being consumables. If I use App Store Server Notifications, will I get updates on the payment status (successful, failed, pending, etc.) of my products? I've worked on Android IAP, which provides such updates via subscriptions on Google Cloud Console. Does App Store Server Notifications work the same? The reason I need this is for the cases where the payment is slow, interrupted or any other potential issues.

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!

**Question 1: ** Will ServerNotificationV2 be able to provide real-time notifications regarding Storekit1 contract renewals, and is receiving Storekit1 notifications in ServerNotificationV2 an expected use? (The documentation does not say that receiving Storekit1 notifications is not recommended, so we would like to confirm Apple's assumption.) **Question 2: ** If ServerNotificationV2 is not able to receive Storekit1 notifications in real time, what is the expected time lag?

There is the bundleVersion exist in this document, and for the notificationType CONSUMPTION_REQUEST, the payload what we always received contains the bundleVersion, but today we receive one CONSUMPTION_REQUEST request payload without the bundleVersion. So we wanna know what means of bundleVersion? Is that always exist? when does it not exist?(for both notification type) Thanks in advance

I have set the callback address in the background（ https://callback.dev.oneduapp.com/pay/apple/callback ）. When the client completes the purchase of a non automatic renewal subscription and is successful. The Apple Store has not had a callback

Hi, I'm working on in-app purchases, and I've created a webhook to receive data sent by the app store whenever there's user subscription activity (CANCEL, DID_RENEW, DID_CHANGE_RENEWAL_STATUS, EXPIRED). Below is the full path of the webhook URL: Webhook URL: https://api.envelopegenerator.live/api/subscription/subscriptionnotification I've set up the webhook to retrieve the status of user subscriptions, but it's not receiving any calls from the app store.

Hello, We are a mobile game company, We have encountered an issue concerning the refunds of consumable products purchased through our app. The issue arises when some Apple users request refunds after purchasing these products, and Apple approves these refund requests even if our users have already consumed it. This situation leads to financial losses and creates an unfair experience among users. We are using App Store Server Notifications V2. So how can we prevent Refunding if user used already our product

Hi, We are implementing App Store Server Notifications V2 and currently testing the implementation in Sandbox. For inAppOwnershipType PURCHASED subscriptions we are getting all server notifications for any subscription change up until eventual expiration/cancellation. For FAMILY_SHARED subscriptions we are expecting the notifications we get to mimic same behavior as for PURCHASED inAppOwnershipType subscriptions, while in reality the following behavior occurs: Account gets access to subscription through family sharing We get only 2 notifications for FAMILY_SHARED subscription - INITIAL_BUY and RENEWAL We do not get any more notifications for said subscription - even when it, for example, expires. Is this behavior expected in Sandbox? Will it work differently in Production environment? (We do have cronjobs that sync data on a specific interval with the app store APIs, but we've been relying on server notifications as a main source of information for subscription changes because it is near realtime, with this limitation our architecture might need to change) Thanks!

We received a notification DID_FAIL_TO_RENEW(subtype:(Empty)) from App Store when the subscription failed to renew because of a billing issue. After this case, we predict that we will receive the notifications based on the following two cases. If the user resolves a billing issue: Receives notification DID_RENEW(subtype:(BILLING_RECOVERY)) If the user does not resolve the billing issue and cancels the subscription: Receives notification EXPIRED(subtype:BILLING_RETRY) Based on the above， I would like to ask two questions Are the above two cases and the notification types we expected correct? If wrong, please tell me what is wrong. If there are other than the above two cases, please tell me the case and notification type.

Hi, I have a question about Apple subscriptions. It is my understanding that when a user upgrades, the subscription prior to the upgrade is already prorated and partially refunded. Is it possible to issue a refund for the upgraded subscription and then request a refund for the pre-upgrade subscription? The server notifications I received were as follows purchase A upgrade A -> B A would have already been prorated and partially refunded refund B Has a revocationReason / revocationDate expired B refund A - should have already been prorated and partially refunded, but if the user requests another refund, will it be given? no revocationReason / revocationDate My guess is no because it's already in revoke status. refund reversed A This may not be present

Hi colleagues! I've encountered a technical issue during the setup of my In-App Purchase (IAP) server for my app (com.forgetmenuts) on AppStore Connect. In the "Info" section of my app's page on AppStore Connect, I've configured the "App Store Server Notifications" endpoints to: https://sys-conf.com/hooks/subscription/ios/debug. Here's the challenge I'm facing: When I initiate a "Request a Test Notification," everything seems to function as expected. I successfully receive the "testNotificationToken." However, the issue arises when I attempt to request the status of this token. At this stage, I encounter an error with the firstSendAttemptResult indicating a TLS_ISSUE. the error is described here: app store docs. I have verified the TLS configurations of my domain (sys-conf.com). Both TLS 1.2 and 1.3 are active and functioning correctly (verified through this TLS Checker: site24x7.com/tools/tls-checker.html I am looking for guidance on how to resolve this TLS issue. Any insights or suggestions from the community would be greatly appreciated, especially from those who might have faced and resolved similar challenges.

We have noticed that the notification service extension stops working after app update for some users and it only starts working again after rebooting the device. Does anybody else have similar problem and what was the solution?

when I use java program to make a Notification Test Request, my server can receive that request correctly。 But when I use the app downloaded from testflight, and finish a purchase, my server cannot got that request。 Anything I have missed ?

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.

I received a refund notification for a consumable product, but the latest_receipt_info property does not exist in the unified_receipt property, or there are no transactions that match the original_transaction_id property value. Are the original_transaction_id property values really refunded? How can I check the cancelation_date_ms value and cancelation_reason value? V2 Notifications cannot be changed. I'm constantly struggling because of this phenomenon. Please reply. https://developer.apple.com/documentation/storekit/in-app_purchase/original_api_for_in-app_purchase/handling_refund_notifications

I received a refund notification for a consumable product, but the latest_receipt_info property does not exist in the unified_receipt property, or there are no transactions that match the original_transaction_id property value. Are the original_transaction_id property values really refunded? How can I check the cancelation_date_ms value and cancelation_reason value? https://developer.apple.com/documentation/storekit/in-app_purchase/original_api_for_in-app_purchase/handling_refund_notifications

I received a refund notification, but the latest_receipt_info property does not exist inside the unified_receipt property, or there is no transaction matching the original_transaction_id property value. How can I check the cancellation_date_ms property value?