To receive server notifications from the App Store, follow the instructions in Enabling App Store Server Notifications. If your server doesn’t receive any notifications, check your server logs for any incoming web request issues, and confirm that your server supports the Transport Layer Security (TLS) 1.2 protocol or later. If you implement version 2 of App Store Server Notifications, call the Get Notification History endpoint. If there is an issue sending a notification, the endpoint returns the error the App Store received from your server. If your issue persists, submit a Feedback Assistant report with the following information: The bundleId or appAppleId of your app The date and time your issue occurred The raw HTTP body of your notification The affected transactionId(s) if applicable The version of App Store Server Notifications (i.e., Version 1 or Version 2) The environment (i.e., Production or Sandbox) To submit the report, perform these steps: Log into Feedback Assistant. Click on the Compose icon to create a new report. Select the Developer Tools & Resources topic. In the sheet that appears: Enter a title for your report. Select “App Store Server Notifications” from the “Which area are you seeing an issue with?” pop-up menu. Select “Incorrect/Unexpected Behavior” from the “What type of feedback are you reporting?” pop-up menu. Enter a description of your issue. Add the information gathered above to the sheet. Submit your report. After filing your report, please respond in your existing Developer Forums post with the Feedback Assistant ID. Use your Feedback Assistant ID to check for updates or resolutions. For more information, see Understanding feedback status.

Hello, We have completed the Age Rating confirmation form and submitted it successfully. Additionally, we increased the app version, rebuilt, and uploaded a new build as recommended. However, we still received the email stating that “Your app requires additional information”. Could you please confirm whether any further action is required on our side, or if this is a known issue on App Store Connect? Thank you.

Dear App Store Engineering Team, I am writing to request official confirmation regarding the behavior of App Store Server Notifications when migrating a live application from V1 to V2. Context: Our application has been live since 2008 and currently utilizes App Store Server Notifications V1. We have a large database of existing legacy subscribers. We are preparing to switch our Production environment setting in App Store Connect from "Version 1" to "Version 2". Our Questions: When we change the setting in App Store Connect to Version 2: Global Format Switch: Does this setting apply immediately to ALL notifications, including those triggered by subscriptions that originated years ago (legacy users)? Payload Consistency: Will renewals for existing legacy subscriptions continue to arrive in the JSON V1 format, or will they immediately start arriving in the V2 JWS (signedPayload) format? Our expectation is that the switch is global and all future notifications (regardless of subscription age) will be sent as V2 JWS payloads, but we require official confirmation to ensure our backend handles the migration without service interruption. Thank you for your assistance.

We are in the process of preparing our app to support the new Texas law (SB2420) that takes effect 1/1/2026. After reviewing Apple's recent announcements​/docs concerning this subject, one thing isn't clear to me: how to associate an app install with a​n App Store Server RESCIND_CONSENT notification​ that could be delivered to our server. Our app is totally free so there isn't an originalTransactionId​ or other similar transaction IDs that would be generated as part of an in-app purchase (and then subsequently sent as part of the payload in the notification to our server during an in-app purchase scenario). So my question is: How do I associate an app (free app) install with an App Store Server RESCIND_CONSENT notification​ that is sent to our server​?

Hello — quick question about App Store Server Notifications migration. We have a live app using Production V1 notifications for recurring in-app subscriptions. We plan to switch the Production webhook to V2. After the switch: Will notifications for existing subscriptions be delivered in V1 format, V2 format, or will it depend (e.g., queued V1 retries vs new V2 deliveries)? If V1 retries are queued, how long should we expect overlap/retries to continue? Any recommended cutover best practices (support both formats, revert process, etc.)? Happy to share additional details. Thanks.

I'm an app developer, and I recently launched a monthly subscription product in my app on the App Store. However, I'm having trouble understanding the App Store's renewal date calculation policy. According to the official documentation, if a subscription is purchased on December 1st, the next renewal date should be January 1st. But the expiresDate is set to December 31st instead. At first, I thought this might be a timezone issue, but even after it became December 1st in UTC, the renewal date was still set to December 31st. Is the timezone used to calculate renewal dates not UTC+0? Or is there documentation on the renewal cycle policy that I might have missed? Any clarification would be greatly appreciated. Thanks in advance!

Hi Team, We are building oru subscrption app and want to rely on server side purchase / subscription related notifications. We went through https://developer.apple.com/documentation/appstoreservernotifications/enabling-app-store-server-notifications We wanted to understand the reliability and latency for server side notifciations provided by Appstore.

I’m implementing App Store subscriptions using StoreKit 2 and testing in the Sandbox environment. Until about a week ago everything worked fine, but recently the Settings > Subscriptions screen shows this message for my test account: “Your current payment method is not available.” The behavior: • Using a Sandbox tester account (not a production Apple ID) • Purchase flow works successfully — the transaction completes, and I receive server notifications • However, the system Settings app still displays that message under the subscription entry • No code changes were made since it last worked Questions: 1. What exactly does this message mean in the Sandbox environment? 2. Could this be related to any Apple system issue or recent backend update? 3. Has anyone else seen the same behavior in recent days? Environment: • Xcode 15.4 • iOS 17.5 (physical device) • StoreKit 2 / Swift 5.10 • Sandbox tester (Japan region) Thanks in advance for any insights or confirmations from others who are testing subscriptions in Sandbox!

Hey! We're implementing In-App Purchase Subscriptions and we were able to receive "App Store Server Notifications" on our "Sandbox Server URL". But the last event we received 22 hours ago. We are able to verify transactions and finish them, but receive no webhooks. We changed nothing on our server or its configurations but the notifications stoped to come. We consulted the API (https://api.storekit-sandbox.itunes.apple.com/inApps/v1/notifications/history) and it says the same as we see - the last event was 22hrs ago. I checked all the advices from here as well (https://developer.apple.com/forums/thread/805806?answerId=864483022#864483022). Is there any Status page for the Store Kit Sandbox services? Was there any outage? Sincerely, Konstantin

I’m reaching out regarding our existing in-app subscription implementation that currently uses App Store Server Notifications version 1 (v1). Our live application has a significant number of active recurring subscriptions that are being managed through the v1 webhook integration. We have now developed a revamped version of our application, which uses the same Apple Developer Account and App Store Connect setup, but in this new app version, we’ve implemented App Store Server Notifications version 2 (v2). Before moving forward with the migration, I would like to clarify the following points to ensure a smooth transition and avoid any disruptions to ongoing subscriptions: Backward Compatibility: Will existing active subscriptions (originally created and managed via v1 notifications) continue to work seamlessly once we switch to v2, or do we need to maintain both v1 and v2 endpoints during the transition? Notification Delivery: If both webhook versions are configured simultaneously, will Apple send notifications to both endpoints, or only the one currently configured in App Store Connect? Migration Strategy: What is Apple’s recommended best practice for migrating from v1 to v2 in a scenario where the live app still has active subscriptions tied to the v1 webhook? Potential Risks or Considerations: Are there any known limitations, delays, or issues that we should prepare for during this migration (for example, differences in payload structure or event types between v1 and v2 that could affect subscription lifecycle management)? I would greatly appreciate your guidance or documentation links that outline the correct migration steps and recommended approach for ensuring continuity of service for all existing subscribers.

As part of ConsumptionRequest fields there's a bit of unclarity. In my case I am only concerned with subscriptions, as they give some premium features in the app. The fields and the questions are the following: playTime: is this the time used in the app in total or just the time the app has been used while using the subscription? consumptionStatus: does this relate only to the user using the premium features he/she paid for? or the fact that the user had access to those features only? Thanks!

Hello everyone, I recently received an email from Apple titled "Notification of Apple Developer Program License Agreement (“DPLA”) violation:" stating that I may have violated Section 11.2 (Termination) of the agreement. The specific clause mentioned relates to engaging in or encouraging misleading, fraudulent, improper, or dishonest acts, such as manipulating App Store rankings or reviews. I’m unsure what triggered this notification as I have always adhered to Apple’s guidelines. Recently, I ran a promotional campaign for my app, where it was made temporarily free, leading to a significant spike in downloads. I suspect this may have raised a flag, but everything was done transparently and without intent to violate any rules. I’ve reached out to Apple Support for clarification, but I wanted to ask here if anyone has experienced something similar or could provide insights into resolving this. I value my membership in the Apple Developer Program and want to ensure everything is compliant. Any advice would be greatly appreciated!

We are currently using App Store Server Notifications V2 in a production environment, but occasionally encounter the error "Failed to parse signedTransactionInfo in the notification payload. status=VERIFICATION_FAILURE." What could be the cause of this error? Also, is there a way to resolve this error? After the notification from Apple was received on the server side, it was passed to the Apple library and an error occurred in the Apple library when decryption was performed.

Context: Back on March 4th, we scheduled a price increase for April 16th on one of our monthly subscription plans with several hundred active subscribers, to change the price from $18.99/mo to $19.99/mo and it has sat unedited in App Store Connect since. Expected: Based on this documentation (Increase the price of an auto-renewable subscription), I would expect that 27 days prior to the price increase (which would be 4 days ago, on March 20th), that users would start receiving notifications about the price increase in the form of emails to their Apple IDs and push notifications when they open up the app. We also have App Store Server Notifications V2 set up. Therefore, I expected to start receiving PRICE_INCREASE notifications as users either got emails and/or push notifications. Actual: We have yet to see any PRICE_INCREASE events come through. Additionally, we have one employee subscribed to this plan on production with a subscription that would renew on April 17th, which would mean that the 21st (3 days ago) was 27 days prior to his subscription renewing. He has checked his email and the app and has still not been notified in any way about the price increase and his subscription manager shows he will renew April 17th at the same price. Questions: Is there some other step that needs to happen for the price increase to take place? Are my expectations wrong about what we should see by this point, or else why might we not have had any indication of customer notifications of the price increase occuring yet?

I am developing a Flutter app for food delivery (a multivendor e-commerce restaurant app). In the vendor app (Android), I successfully implemented a background notification that stays active until the vendor responds with either Accept or Decline. This works fine on Android, but I cannot get the same functionality working on iOS. My requirements: Vendor should receive a background notification. The notification should include action buttons (Accept / Decline). It should remain active until the vendor takes action. My questions: Is this possible to implement in iOS with Flutter? If yes, what is the recommended way (e.g., firebase_messaging, flutter_local_notifications, flutter_foreground_task, or native iOS integration)? Are there any iOS restrictions I should consider compared to Android background services? I built this for Android using firebase_messaging + flutter_foreground_task + flutter_local_notifications. On iOS, I tried setting up firebase_messaging and flutter_local_notifications, but I’m unable to keep the notification persistent with Accept/Decline action buttons. I expected similar behavior to Android, but it seems iOS has more restrictions around background services and notification handling. Dependencies I am using (relevant ones): firebase_core: ^3.8.0 firebase_messaging: ^15.1.5 flutter_local_notifications: ^17.2.2 flutter_foreground_task: ^8.17.0 get: ^4.7.2 shared_preferences: ^2.3.2

Withouth authorization Bearer token: public static JWKSet getApplePublicKeys(String token) throws Exception { URL url = new URL("https://api.storekit.itunes.apple.com/inApps/v1/jwsPublicKeys"); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod("GET"); conn.setRequestProperty("Accept", "application/json"); int status = conn.getResponseCode(); InputStream stream = (status >= 200 && status < 300) ? conn.getInputStream() : conn.getErrorStream(); String body = new BufferedReader(new InputStreamReader(stream)) .lines() .reduce("", (acc, line) -> acc + line); System.out.println("HTTP " + status + ": " + body); // load JWKSet from JSON string try (InputStream in = new ByteArrayInputStream(body.getBytes(StandardCharsets.UTF_8))) { return JWKSet.load(in); } } With authorization Bearer token: public static JWKSet getApplePublicKeys(String token) throws Exception { URL url = new URL("https://api.storekit.itunes.apple.com/inApps/v1/jwsPublicKeys"); HttpURLConnection conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod("GET"); conn.setRequestProperty("Accept", "application/json"); conn.setRequestProperty("Authorization", "Bearer "); int status = conn.getResponseCode(); InputStream stream = (status >= 200 && status < 300) ? conn.getInputStream() : conn.getErrorStream(); String body = new BufferedReader(new InputStreamReader(stream)) .lines() .reduce("", (acc, line) -> acc + line); System.out.println("HTTP " + status + ": " + body); // load JWKSet from JSON string try (InputStream in = new ByteArrayInputStream(body.getBytes(StandardCharsets.UTF_8))) { return JWKSet.load(in); } } Below is the my production and sandbox URls: Sandbox: https://api.storekit-sandbox.itunes.apple.com/inApps/v1/jwsPublicKeys Production: https://api.storekit.itunes.apple.com/inApps/v1/jwsPublicKeys Kindly help me with this. If I am doing anything wrong, please let me know. I tried using the token in the URL, and it gives me a 404. If I hit the endpoint without the token, it returns a 401. Please assist me.

The documentation mentions the following: Verify your receipt first with the production URL; then verify with the sandbox URL if you receive a 21007 status code. This approach ensures you don’t have to switch between URLs while your app is in testing, in review by App Review, or live in the App Store. This way, you can use one server environment to handle both Sandbox and Production environments. It is necessary to pass App Review. However, I'm not manually hitting these URLs - I'm using Apple's libraries. Specifically, the environment is used in SignedDataVerifier and AppStoreServerAPIClient. (I can't link to these because, for some reason, the domain apple.github.io is not allowed. The documentation for these is only found there. You can find it quickly by searching these terms and the domain.) Here is how SignedDataVerifier is being used: const verifier = new SignedDataVerifier( appleRootCertificates, APPLE_ENABLE_ONLINE_CHECKS, APPLE_ENVIRONMENT, APPLE_BUNDLE_ID, APPLE_APP_ID ) const verifiedNotification: ResponseBodyV2DecodedPayload = await verifier.verifyAndDecodeNotification(signedPayload) if (!verifiedNotification) { // Failure return } Here is how AppStoreServerAPIClient is being used: const appStoreServerAPIClient = new AppStoreServerAPIClient( SIGNING_KEY, APPLE_IAP_KEY_ID, APPLE_IAP_ISSUER_ID, APPLE_BUNDLE_ID, APPLE_ENVIRONMENT ) const statusResponse: StatusResponse = await appStoreServerAPIClient.getAllSubscriptionStatuses(originalTransactionId, [Status.ACTIVE]) In the source code for SignedDataVerifier.verifyAndDecodeNotification, I can see that it throws a VerificationException(VerificationStatus.INVALID_ENVIRONMENT) error . So for SignedDataVerifier is it as simple as wrapping my code in a try/catch and checking that the error's status code is 21007? I'm unsure about this because if you scroll to the bottom of the linked source code file, you can see the enumeration VerificationStatus, but it's unclear if this member has a value of 21007. The source code for AppStoreServerAPIClient only says that it throws an APIException if a response could not be processed, so I'm not too sure about how to handle this one.

i'm integrating In-App Purchases in our Flutter app using the official in_app_purchase plugin. We are currently testing consumable purchases and facing issues with the way events are delivered from StoreKit to the app. Implementation details I initiate the purchase with: await InAppPurchase.instance.buyConsumable(purchaseParam: purchaseParam); I listen for purchase updates with: final Stream<List> purchaseUpdated = inAppPurchase.purchaseStream; _subscription = purchaseUpdated.listen((purchaseDetailsList) { _handlePurchaseUpdates(purchaseDetailsList); }, onError: (Object error) { updateApplePaymentStatus(isSuccess: false, response: jsonEncode(error.toString())); }, onDone: () { _subscription.cancel(); }); Issues Observed Control on purchase button event As soon as the user taps the purchase button, the App Store purchase sheet is shown. Question: Is there a way to intercept control at this point (before showing the sheet) to perform additional checks or logging? Cancelled payment after UPI intent In our testing with UPI payment flows (UPI intent triggered from Apple Pay/linked payment method), if the user cancels the payment from the external flow, we don’t see a clear event in purchaseStream. Question: How can we reliably capture this cancellation status on the app side? Event timing after successful purchase Currently, the purchaseStream event is only triggered after the StoreKit purchase confirmation popup has been dismissed by the user. Question: Is there a way to capture the event earlier (i.e., right after StoreKit confirms payment success), so we can update our backend and UI without waiting for popup dismissal? Request We would appreciate guidance on: Best practices for intercepting purchase initiation before the StoreKit sheet. Recommended way to detect and handle cancelled payments (especially in UPI flows) managed on frondend side. Whether it is possible to receive successful purchase events without waiting for the user to dismiss the confirmation dialog. Thank you for your support.

Unsure if this has been reported before, but I'm seeing a specific scenario where Apple is sending back faulty information in App Store Server Notifications. When users have payment failures that result in the membership expiring, and then reactivate later on with a different subscription, they are given a new originalTransactionId, yet we have three cases where we receive messages about the old originalTransactionId, indicating that after the user recovers their subscription, Apple is resurrecting the old subscription and treating it as if it is active BUT ultimately decides to deactivate it. Here is a sample screenshot of an impacted user. We only have three month and annual plans. Timeline: March 21st: This user signed up for a 3 Month Plan June 21st: This user fails to pay July 7th: After our 16 day grace period, this user loses access July 29th: This user sees they lost access and repurchase Augsut 19th: Their membership is deactivated (long before their 3 Month Subscription is up) For further verification I've also attached a record of all the payloads we've received from Apple for this user. Please let me know if you need any more details to fix this bug OR if it has already been fixed! Thank you. user_webhook_data_sanitized.csv

Hi all, We’re implementing in-app subscriptions in our iOS app using App Store Server Notifications V2 in the production environment. Everything is generally working well — we receive notifications such as DID_CHANGE_RENEWAL_STATUS, CANCELLATION, etc., and we log all incoming notifications into our own database. However, we've encountered a single case where the INITIAL_BUY notification was not received for a specific user. Interestingly, we did receive the later notifications (DID_CHANGE_RENEWAL_STATUS and CANCELLATION) for that same user. Here is our setup: App Store Server Notifications V2 Notification endpoint is stable and functioning normally (receives and logs other notifications) Notifications are reliably stored in our database The issue occurred only once for one user Environment: Production We've already contacted Apple Developer Support, but were informed that this issue is out of scope for direct support, and were directed to the Developer Forums. Our questions: Under what conditions might the INITIAL_BUY notification fail to be sent or delivered? Is there any known behavior or scenario where Apple may skip the INITIAL_BUY notification? Any recommendations on how to further investigate or verify whether it was sent from Apple’s side? We’ve confirmed that the notification never hit our server (no logs, no DB record), and our system was healthy at the time. Any insight would be greatly appreciated. Thank you!

What is the expected behavior for App Receipts and ASSN v2 notifications when a subscription is set to "Remove from Sale"? I tried to test this in Sandbox, but the "Remove from Sale" setting in App Store Connect doesn't seem to affect the Sandbox environment. For existing subscribers, what happens in the receipt? Does auto_renew_status change to 0 and is expiration_intent populated immediately? Also, which notificationType is sent via ASSN v2?