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 We're handling App Store subscriptions on the server side using App Store Server Notification v2. Our pipeline currently identifies each event by transactionId and originalTransactionId. A few notes about our client: Our app is built with Flutter and uses the standard in_app_purchase plugin layer to drive App Store purchases (StoreKit 1 under the hood). We have not migrated to StoreKit 2 on the client yet. We have not been setting SKPayment.applicationUsername on outgoing purchases, so every transaction we've ever produced has appAccountToken: null in its v2 notification. This question is purely about what the server-side notification can tell us, given the current client state above. What we're trying to figure out A user can resubscribe to an expired subscription in two different places: In-app — the user opens our app and re-purchases through our normal in-app purchase flow. App Store — the user goes to Settings → Apple ID → Subscriptions and resubscribes from the system UI, without ever returning to the app. Both paths trigger a SUBSCRIBED notification (subtype RESUBSCRIBE) with structurally identical payloads as far as we can tell — same shape for data.transactionInfo, data.renewalInfo, etc. From the notification alone we can't decide which path produced it. The reason this matters: in our system, the two paths require different business handling: In-app path: the user may have signed in to a different business account in our app. The new subscription should be attributed to whoever paid in the app just now, not to the previous owner of originalTransactionId. App Store path: there is no in-app signal, so the business owner can only be inferred from the previous originalTransactionId mapping. If we get it wrong, the subscription's entitlement ends up on the wrong business account. What we do today Because we can't tell the paths apart from the notification, we defer processing for a few minutes and check whether an in-app order for the same transaction has arrived in the meantime: If an in-app order shows up → it's the in-app path; attribute to the in-app account. If nothing shows up after the delay → assume App Store path; fall back to the previous owner mapping. This works but adds latency to entitlement activation and forces us to build a deferred-retry queue with idempotency against the in-app callback path. Possible direction: appAccountToken / applicationUsername We noticed that v2 notifications carry transactionInfo.appAccountToken, and the docs suggest that StoreKit 1's SKPayment.applicationUsername (when it's a valid UUID) is mirrored into this field. In theory, if we start setting it on every in-app purchase from the Flutter client, the field could double as a path discriminator on the server: appAccountToken != null → in-app path (only the app can set it), and we even get the business user id for free appAccountToken == null → App Store path (no UI to populate it) But we have some open questions before committing to this direction: Questions Is there an existing signal in ResponseBodyV2 / JWSTransactionDecodedPayload / JWSRenewalInfoDecodedPayload that distinguishes these two paths, that I might be missing? Can the same distinction be obtained via getAllSubscriptionStatuses / getTransactionHistory / any other Server API endpoint? Is applicationUsername (StoreKit 1) still a reliable way to populate appAccountToken on v2 notifications today? Specifically: Are there format constraints beyond "valid UUID" that cause Apple to drop the value? Any known differences between sandbox and production in how it's mirrored? Does the App Store path ever strip or overwrite a previously-set value when the same originalTransactionId is reused? For existing subscriptions where applicationUsername was never set (which is all of ours today, since we've never polient), is there any way to retroactively distinguish the in-app vs App Store path? Or is timing-based deferred matching theonly option for that cohort, even after we start setting the value on new purchases? If neither (1) nor (2) is currently possible, is the timing-based heuristic we use today the pattern Apple expects developers to follow, or is there a recommended approach we're missing? A small suggestion, if it turns out there's no existing way If the information genuinely isn't exposed today, it might be worth surfacing a salesChannel-style field on the transaction, similar to what Google Play Developer API exposes on Order.salesChannel (IN_APP, PLAY_STORE, etc.). That would let server-side handlers route each event to the correct business owner immediately, regardless of whether appAccountToken was set, and would also cover legacynt never had a chance to populate it. Thanks — happy to share sample payloads or more detail if helpful.

Hello, We are planning to shut down our mobile app service and need to discontinue our auto-renewable subscription product. Our service termination date is July 31, and we are currently preparing the backend implementation for this. We have reviewed the official documentation and Apple Developer Forums, but there are several behaviors we cannot confirm through sandbox testing, as the "Remove from Sale" setting does not appear to affect the sandbox environment. We would greatly appreciate clarification on the following: Server notification at the moment of "Cleared for Sale" being unchecked When we uncheck "Cleared for Sale" in App Store Connect, is any App Store Server Notification (V2) sent to our server immediately at that moment? If yes, what is the exact notificationType and subtype value sent? If no, when is the first notification triggered for existing active subscribers after this action? 2. Notification sequence from product removal through final expiration For existing active subscribers, what is the exact sequence of notificationType and subtype values our server should expect — from the moment we remove the product from sale through the subscriber's final expiration? Based on our research, we believe the sequence may be: (1) Cleared for Sale unchecked → (2) No immediate notification → (3) At next renewal attempt → EXPIRED with subtype PRODUCT_NOT_FOR_SALE Could you confirm whether this is correct, or provide the accurate sequence? 3. Whether DID_CHANGE_RENEWAL_STATUS is sent before EXPIRED Is a DID_CHANGE_RENEWAL_STATUS notification sent to our server at the moment of removal from sale, before the EXPIRED notification at the renewal date? If yes, what is the subtype of this notification? 4. Recommended server-side handling per notification For each notification in the sequence above, what is the recommended server-side action? For example: On EXPIRED with subtype PRODUCT_NOT_FOR_SALE → revoke entitlement immediately? On DID_CHANGE_RENEWAL_STATUS (if sent) → update status only, do not revoke entitlement yet? Sandbox testing limitations We have confirmed that the "Remove from Sale" setting does not affect the sandbox environment. Is there any recommended way to test this scenario before applying it in production? If sandbox testing is not possible for this case, is there any official confirmation of this limitation? We have a fixed service termination schedule and need to ensure our backend handles this correctly. Any clarification or pointers to official documentation would be greatly appreciated. Thank you.

Hey We have noticed a change in the retry behavior of Apple Server Notifications webhooks V2 starting around March 12–13, 2026. Previously, when our webhook endpoint returned an HTTP 400 response, Apple would retry the notification delivery multiple times according to the documented retry policy. However, beginning around March 12–13, it appears that Apple no longer retries the webhook when a 400 response is returned. The notification is sent only once and no further retry attempts are made. From our understanding of the documentation, retries should occur when delivery fails, and historically we observed retries even for some 4xx responses. We would like to confirm: Has Apple recently changed the retry behavior for Server Notifications? Are HTTP 4xx responses (specifically 400) now considered terminal failures that will not trigger retries? Is this change intentional or related to a rollout in the webhook delivery system? We have called the "Notification History" endpoint for some users who purchased a sub and we are only getting one attempt with the following data in it: { attemptDate: 1773469202552, (2026-03-14T06:20:02.552Z) sendAttemptResult: 'UNSUCCESSFUL_HTTP_RESPONSE_CODE', } This was 2 days ago, based on the docs, the user should have a few attempts at least. This behavior change affects systems that rely on retries to handle temporary validation issues or transient failures. Thanks!

Hi, I’ve been invited to an Apple Developer account with the Developer role. I’ve already created a subscription in App Store Connect, but when I try to fetch available subscriptions in Xcode for in-app purchase, nothing appears to be available for purchase.

Hi all, I'm encountering an issue with auto-renewable subscription upgrades in the App Store. Here's my setup: Context: Plan A: Base Plan (yearly auto-renewable subscription) Plan B: Pro Plan (monthly auto-renewable subscription) B is configured as an upgrade from A. Issue: When a user with an active Plan A subscription upgrades to Plan B, I correctly receive an App Store Server Notification v2 with DID_CHANGE_RENEWAL_PREF and UPGRADE subtype. According to Apple's documentation, a prorated refund is issued automatically in this scenario, and no separate REFUND event is sent, the refund information should be retrievable through the upgrade event itself. Testing in Sandbox: In my sandbox tests, Plan A has a 1-hour duration and Plan B has a 5-minute duration. After the user upgrades to Plan B, I immediately cancel the subscription to prevent auto-renewal. Expected vs. Actual Behavior: After the 5 minutes expire, Plan A still appears as the active current entitlement. I initially thought this might be because the prorated refund hadn't been processed yet. However, even after waiting the full hour (the original duration of Plan A), it continues to show as an active entitlement—which shouldn't be the case. As a result, when I attempt to restore purchases, Plan A is still identified as valid and the subscription gets reactivated. Question: Is this behavior expected in the sandbox environment, or am I missing something in how the prorated refund and entitlement expiration should be handled?

Based on https://developer.apple.com/help/app-store-connect/configure-in-app-purchase-settings/enter-server-urls-for-app-store-server-notifications It seems like we can choose between version 1 or version 2 notification Choose either Version 1 (deprecated) or Version 2 notifications. Learn about versions of App Store Server Notifications. However, I do not find a way to make such a choice. Does anyone know, how I can choose between v1 or v2 notification? We currently provide a self-hosted server endpoint built on the v1 specification. While the existing server is perfectly stable, we are evaluating a migration to v2. Thanks.

We are developing a platform (Ferve) where users subscribe to individual artists to access exclusive content. We use a user-centric remuneration model: each artist has an independent income pool, and funds from a specific subscription must be attributed solely to that artist. We have two critical challenges regarding our integration: Granular Financial Reporting for User-Centric Payouts As the Merchant of Record, Apple provides aggregate Financial Reports. However, these reports do not provide a breakdown of taxes, commissions, or exact exchange rates used for individual transactionId records. Though we can keep records of each transaction in our database, thus linking them with which artist they belong to, we are unable to collect fees/taxes applied to each individual transaction. Because our payouts are artist-specific, we need to deduct the exact regional taxes and Apple commissions from each transaction to calculate the artist's due balance. Currently, we can only see the final consolidated balance in BRL (Brazilian Reals) at the end of the month. Is there an API or report that provides the net proceeds and tax breakdown per transaction ID? How can we retrieve the exact exchange rate applied to foreign currency sales (e.g., EUR to BRL) before the final consolidation? Supporting Multiple Concurrent Subscriptions Our current App Store Connect configuration uses a single 'Subscription Group' for all artist 'Clubs' since they share the same price points. However, we have found that users cannot subscribe to more than one product within the same group simultaneously (the App Store treats this as an upgrade/downgrade). On our platform, a user must be able to subscribe to Artist A and Artist B at the same time. What is the recommended architecture for this? Should we dynamically create a unique Subscription Group for every artist onboarded to our platform? If we use unique groups, is there a limit to the number of Subscription Groups one app can have? We appreciate the help, Ferve

I am contacting you to clarify a technical issue regarding the behavior of App Store Server Notifications (V2), as we have observed differences depending on the subscription plan. Currently, we have noticed the following behavior when a refund occurs for an auto-renewable subscription: Observed Behavior: Monthly Plan:When a refund occurs, we receive a REFUND notification, followed by an EXPIRED notification indicating the subscription has ended. Annual Plan:When a refund occurs, we receive the REFUND notification, but the expected EXPIRED notification does not arrive. Questions: Are there any differences in the conditions for sending EXPIRED notifications after a REFUND, depending on the subscription plan (monthly vs. annual)? Is the absence of the EXPIRED notification for annual plans an intended behavior by Apple, or could it be a possible issue? I would appreciate your guidance on this matter.

Hello, We are experiencing an issue related to Sign in with Apple Server-to-Server (S2S) notifications, specifically involving repeated delivery of the account-deleted event, and would like to ask whether this behavior is expected or known. Background We have configured an S2S notification endpoint for Sign in with Apple in accordance with Apple’s requirements for account status change notifications. Our endpoint: Is reachable over HTTPS Consistently returns HTTP 200 OK Successfully receives other S2S events, including: email-enabled email-disabled consent-revoked Issue: Repeated 'account-deleted' events for the same Apple ID For most users, the account-deleted event is delivered only once, as expected. However, for a specific Apple ID used with Sign in with Apple, we are observing repeated deliveries of the same account-deleted event, arriving at regular intervals (approximately every 5 minutes). The payload contents are identical between deliveries and include the same user identifier (sub) and event timestamp. Notably: The Apple ID deletion itself completed successfully The payload does not change between deliveries Our endpoint continues to return HTTP 200 OK for every request Questions We would appreciate clarification on the following points: Is repeated delivery of the same account-deleted event expected behavior in any scenario? Is there a retry or redelivery mechanism for this event type, even when HTTP 200 is returned? Could repeated deliveries indicate that the deletion process is still considered “in progress” on Apple’s side? Are developers expected to treat account-deleted events as at-least-once delivery and handle them idempotently? Additional context While researching this issue, we found a forum thread describing a very similar case: https://developer.apple.com/forums/thread/735674 In that discussion, Apple staff advised submitting the issue via Feedback Assistant, which suggests that this behavior may already be understood internally. We have also submitted a Feedback Assistant report with detailed logs and timestamps. Any clarification on the expected behavior or recommended handling for this scenario would be greatly appreciated. Thank you for your time and support.

Our app is supposed to be removed from sale on May 31st. Subscriptions our app is offering will also be removed on May 1st one month before our app removal. I would like to know if AppStoreServerNotificationV2 EXPIRED event will be sent to a specified endpoint after the removal of these subscriptions. I think each subscription will be canceled automatically from May 1st to May 31st and it will send EXPIRED event to our server, but is it true? Thank you in advance.

I’m updating a legacy application that used Apple Pay v1 token format, and in my new revamped version I’m now receiving the newer Apple Pay v2 format. The old (v1) payload looked like this: php { "version": "EC_v1", "data": "...", "signature": "...", "header": { "ephemeralPublicKey": "...", "publicKeyHash": "...", "transactionId": "..." } } In the new revamp (v2), Apple Pay returns this instead: php { "signedTransactionInfo": "eyJhbGciOiJFUzI1NiIsIng1YyI6WyJNSUlF..." } From what I understand: v1 tokens were elliptic-curve encrypted JSON objects containing a header and signature. v2 tokens seem to be JWS (JSON Web Signature) strings using the ES256 algorithm, possibly containing transaction and subscription details inside. Questions Is there any official Apple documentation or migration note explaining the move from EC_v1 → signedTransactionInfo? How should I verify or decode the new signedTransactionInfo payload? Should the verification now use Apple’s public keys instead of the legacy Merchant ID certificate? Are there any example implementations or SDKs that can handle both v1 and v2 formats during migration? Is there a recommended way to maintain backward compatibility while transitioning existing users? Goal Ensure that my revamped app can handle Apple Pay v2 tokens securely while keeping the legacy v1 integration functional until all users are migrated.

"In iTunes IAP space" Give a monthly subscription with 7 days freeTrail, what would be sequence of iTunes V2 notification for the following behaviour? When an end user purchases a subscription that includes a free trial. When the user transitions from the free‑trial period to the paid subscription period.

Scenario: User is actively subscribed to Monthly Package From the Device App (Manage Subscriptions), user upgrades to Yearly Package Purchase completes successfully on device Issue: Do not receive any server notification for this action Month Package Purchase Date: 2025-11-11 19:06:45.537 +0600 Month to Yearly Upgradation Date: 2025-12-11 paymentReferenceId: 510002270528780

Scenario User is actively subscribed to Monthly Package From the Device App (Manage Subscriptions), user upgrades to Yearly Package Purchase completes successfully on device Issue Do not receive any server notification for this action Month Package Purchase Date: 2025-11-11 19:06:45.537 +0600 Month to Yearly Upgradation Date: 2025-12-11 paymentReferenceId: 510002270528780

I am currently testing the Declared Age Range / Parental Consent flow in the Sandbox environment, and I am experiencing an issue where the RESCIND_CONSENT App Store Server Notification is not being delivered to my server. 🔍 Test Environment iOS version: iOS 26.2 (Sandbox environment) App Store Server Notifications: Sandbox environment 🔄 Test Scenario App Settings > Developer > Sign in with a Sandbox account Launch the app In App Settings > Developer > Sandbox Account > Management > Revoke App Consent, enter the app’s Bundle ID, tap the Revoke Consent button, and confirm that the revocation completion popup message is displayed Check whether App Store Server Notifications are received by the server Confirm that the RESCIND_CONSENT notification is not received by the server ✅ Expected Result The App Store Server sends a RESCIND_CONSENT notification to the Sandbox endpoint The notification payload includes appTransactionId The server can block app access based on the corresponding appTransactionId ❌ Actual Result No RESCIND_CONSENT notification is received in the Sandbox environment ❓ Questions Is this behavior an intended limitation of the Sandbox environment, or is it a known issue or bug? Is it possible that RESCIND_CONSENT notifications will only be delivered starting January 1, 2026? Additionally, when a RESCIND_CONSENT server notification is received, I currently update my database with the appTransactionId and the registration date. When a minor attempts to access the app, I check the latest appTransactionId status, and if the most recent state indicates consent has been revoked, I block app access and prompt the user to request parental consent again using PermissionKit.

Hi everyone. I'm trying to use https://developer.apple.com/documentation/appstoreserverapi/get-transaction-info to retrieve order information. How can I get the refund status of an order through this API? Also, Apple's webhook notification for refunds includes fields like revocationReason and revocationType. Can these be retrieved through the API? I've noticed that some refund orders have these fields when retrieved using get-transaction-info api, but others don't. I don't know the reason for these differences. Could you please explain? Thank you very much.

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.