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.

"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.

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.

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.

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.

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

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!

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.

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.

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.

I’m experiencing an issue with Apple Developer Support communication. On the page Apple Developer Support Cases I can see updates and messages indicating that Apple Support specialists supposedly replied to my case. However, I never receive those emails in my inbox. The only emails that actually arrive to my Gmail account are automatic messages with the subject: “Thanks for submitting your support request” I checked: Spam folder Promotions/Social tabs Gmail filters Blocked addresses But there are still no replies from support specialists. Because of this, I cannot continue communication with support. Has anyone experienced the same issue? Is there a specific Apple domain/email address that should be whitelisted? Apple Support team, please contact me directly.