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 scheduled for a price rise for July 3rd. We have >90% of subscribers on a standard monthly subscription (without trials or offers), and we gave more than the requisite notice (we scheduled these on May 20). We also chose in the price increase flow to apply the new price to existing subscribers. On July 3rd, the price for new subscribers went up as expected. However, we are still seeing all our renewals at the old price. My own subscription to the app renewed today (July 15th) - but at the old price. In my Settings app, I can see that the next renewal (August 15th) will be at the new price. I also haven't had any notifications/email from Apple about the rise (which should happen 27 days before the rise, so will likely happen for me on July 19th....but that should've been June 19th). So it appears that while the new price will be applied to existing subscribers, it is happening a month after the scheduled price rise. Some of our customers are being contacted by Apple about the price rise...for August, when it should have already taken place. Given that we scheduled this way more than 27 days ahead, why would the price rise for existing subscribers not take place at the planned date? Are there other reasons that are not documented? The only two reasons we can see are a) insufficient planning notice and b) trial periods being respected - neither of which apply here. We can see significant cancellations from July 3rd in countries where customers have to opt-in for a price rise, primarily Germany. So it seems that the price rise definitely came into effect for our existing subscribers, causing opt-in cancellations, but the customers aren't actually paying the higher price for another cycle. Any ideas?

I tried with VSUserAccountManager.shared.requestAutoSignInAuthorization(). It did prompt a popup but with errors. I do have 'com.apple.smoot.subscriptionservice' configured in the entitlement. I don't know what's happened? Could you help me out.

My app published 6 hours ago this is first version and IAP is still in review. My app is hard paywall app so people cannot continue in app and this is all happening during initial boost. I contacted with apple but they say they send message to review time and hours passed nothing changed. People downloading the app and I'm watching it without able to do anything :( Are there anyone experienced same thing ? Do you have any advice ?

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?

Issue Description When using the App Store Server API endpoint GET v2/history/{transactionId} to retrieve transaction history for a specific transaction, I'm observing unexpected changes in the appTransactionId field across related transactions in the same subscription group. Important Context: This is a "clean" auto-renewable subscription with no user intervention - the user has had continuous auto-renewals without any upgrades, downgrades, cancellations, or resubscriptions. The subscription has been renewing automatically and successfully throughout the entire period. API Call GET v2/history/1000000000000001 Response Data The API returns the following transaction history, where I notice the appTransactionId values are inconsistent across what should be a straightforward auto-renewal sequence: Note: The data below has been sanitized for privacy protection (IDs, bundle identifiers, etc. have been replaced with example values), but the logical relationships, date sequences, and the core issue remain identical to the original data. Array ( [0] => Array ( [transactionId] => 1000000000000001 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000001 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1743784032000 [originalPurchaseDate] => 1743784034000 [expiresDate] => 1746376032000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => PURCHASE // Original purchase [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000001 // Different value ) [1] => Array ( [transactionId] => 1000000000000002 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000002 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1746376032000 [originalPurchaseDate] => 1746347349000 [expiresDate] => 1749054432000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // First auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same for renewals ) [2] => Array ( [transactionId] => 1000000000000003 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000003 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1749054432000 [originalPurchaseDate] => 1749025657000 [expiresDate] => 1751646432000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // Second auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same as previous renewal ) [3] => Array ( [transactionId] => 1000000000000004 [originalTransactionId] => 1000000000000001 [webOrderLineItemId] => 1000000000000004 [bundleId] => com.example.myapp [productId] => MonthlySubscription [subscriptionGroupIdentifier] => 20000000 [purchaseDate] => 1751646432000 [originalPurchaseDate] => 1751617840000 [expiresDate] => 1754324832000 [quantity] => 1 [type] => Auto-Renewable Subscription [inAppOwnershipType] => PURCHASED [signedDate] => 1751868174651 [environment] => Production [transactionReason] => RENEWAL // Third auto-renewal [storefront] => USA [storefrontId] => 143441 [price] => 100000 [currency] => USD [appTransactionId] => 700000000000000002 // Same as previous renewals ) ) Questions Is this behavior expected? Should the appTransactionId change between the original purchase and subsequent renewals within the same subscription group, especially when there are no user actions (upgrades/downgrades/cancellations/resubscriptions)? What determines the appTransactionId value? The documentation doesn't clearly explain when this identifier might change or what triggers a new value. This is particularly puzzling since this is a straightforward auto-renewal scenario. How should we handle this in our backend logic? Should we treat transactions with different appTransactionId values as separate entities, or should we rely on originalTransactionId for grouping related subscription transactions? Is this a known issue? We've seen similar concerns in the community regarding transaction ID inconsistencies, but this specific case involves a clean auto-renewal flow without any complicating factors.

Hey everyone, I'm dealing with a really frustrating issue with auto-renewable subscriptions in my app and hoping someone can help or at least tell me what's going on. Here's what happened: When I first submitted my app I had already set up the monthly and yearly subscriptions in App Store Connect After a few rejections the app finally got approved, but when it went live I noticed the subscriptions were completely gone. Users could only see the lifetime purchase. I never removed anything or changed any major configurations, so I have no idea why they just disappeared I tried removing the app from sale and then also temporarily removed the subscriptions. After re-enabling them they now show as "Approved" when I look at them individually But in the Subscription Group it still says "Updates Pending Review" and I can't do anything - can't edit anything, can't resubmit I thought about submitting a new build hoping I could reselect the subscriptions, but they still don't show up as selectable in the in-app purchase section At this point I'm completely stuck. I've put a warning message in the app to let users know, but this is seriously hurting my business since subscriptions are basically my main revenue. Has anyone else run into this? Is there any official way to fix or reset a subscription group that's stuck like this? Thanks for any help!

Hi, I would like to sell the app through an annual subscription with automatic renewal, giving the potential customer the opportunity to try it for a week and, if they like it, buy it. I would need you to explain to me how I have to set everything up, I asked the Verification Team how to set it up a couple of times but I could not get any concrete help, they advised me to follow the guidelines. The Team gave me this response: We are unable to complete the review of the app because one or more in-app purchase products were not submitted for review. Specifically, the app includes references to a subscription, but the associated in-app purchase products were not submitted for review. The problem is perhaps that I can't send the subscription for review because I can't access the menu under "Monetization" which is the one I'm attaching the image of. Can anyone help me solve this problem? [Thanks]

Hi, I am trying to obtain the subscription expiry date or purchase date from server using Storekit2 for my project. I have an account which is already having an active subscription but it still says no purchase found. Thanks

Some paid users are unable to use the paid features unlocked by purchasing our subscription plan. It seems that this is due to StoreKit 2's Transaction.currentEntitlements not working the way we would expect it to work. Are you also encountering this issue? Do you have any idea to improve this situation? At launch, our app checks if the user is subscribed to the plan, using Transaction.currentEntitlements. As a result, the currentEntitlements array was empty. Our app then fetches the products from StoreKit 2 using Product.products(for:). As a result, the Product.SubscriptionInfo.RenewalState value of the corresponding Product (product.subscription.status.first.state) is subscribed, which confirms that the user has indeed purchased our plan, but seems to contradict the absence of the corresponding transaction in Transaction.currentEntitlements. Proactive in-app purchase restore and a restore purchase button calling the AppStore.sync() method are implemented, but using the button did not solve the issue.

I’m testing an auto-renewable subscription on TestFlight. Now the user can't re-purchase the same product – Apple just restores the old (expired) one, and no payment sheet appears. How can I let the same TestFlight user re-subscribe to an expired product? Do I have to create a new productId for every test cycle?

Hi there 👋🏻 We are facing an issue that started on 24 June 2025 where some users that have an active subscription with an offer are not being able to use/restore their subscription since Transaction.currentEntitlements is empty. We have tried to call the server with this endpoint https://developer.apple.com/documentation/appstoreserverapi/get-transaction-history and it's returning the correct transactions correctly. Any idea what is happening?

I Implement a 'SubscriptionStoreView' using 'groupID' into a project (iOS is targeting 17.2 and macOS is targeting 14.1).Build/run the application locally (both production and development environments will work fine), however once the application is live on the AppStore in AppStoreConnect, SubscriptionStoreView no longer shows products and only shows 'Subscription Unavailable' and 'The subscription is unavailable in the current storefront.' - this message is shown live in production for both iOS and macOS targets. There is no log messages shown in the Console that indicate anything going wrong with StoreKit 2, but I haven't made any changes to my code and noticed this first start appearing about 5 days ago. I expect the subscription store to be visible to all users and for my products to display. My application is live on both the iOS and macOS AppStores, it passed App Review and I have users who have previously been able to subscribe and use my application, I have not pushed any new changes, so something has changed in StoreKit2 which is causing unexpected behaviour and for this error message to display. As 'SubscriptionStoreView' is a view provided by Apple, I'm really not sure on the pathway forward other than going back to StoreKit1 which I really don't want to do. Is there any further error information that can be provided on what might be causing this and how I can fix it? (I have created a feedback ticket FB13658521)

Hi everyone, I’m seeing a consistent one-day discrepancy between the expiresDate returned by the App Store Server API and the “Expires on” date shown in the iOS Settings / App Store subscription list. I’d like to confirm whether this behavior is expected or if I’m misunderstanding the way Apple rounds dates. Reproduction steps Step Action Result 1 Purchase a 1-month auto-renewable subscription on 23 June 2025 14:00 JST (UTC+9) Transaction succeeds 2 Immediately fetch the transaction with GET /inApps/v1/subscriptions/{transactionId} Response contains "expiresDate": "2025-07-23T05:00:00Z" (= 23 July 2025 14:00 JST) 3 On the same device open Settings › Apple ID › Subscriptions (or App Store › Account › Subscriptions) UI shows Expires on: 22 July 2025 The same happens for every monthly renewal and on multiple devices. Region is Japan, device time zone Asia/Tokyo. What I understand so far (and my hypothesis) Apple’s docs say a monthly subscription renews “on the same calendar date” of the next month, so renewal in this example is 23 July. If the renewal is scheduled for 23 July at 14:00 JST, the subscription is fully usable until the end of 22 July in calendar terms, because the new billing period starts the moment the 23rd begins in Apple’s canonical time zone. Therefore, it might be intentional for the UI to display 22 July—i.e., “you can keep using it through the 22nd; on the 23rd it renews.” This hypothesis makes sense internally, yet it still looks confusing to end users who read “Expires on 22 July” and assume access ends at 00:00 on the 22nd, a whole day earlier than in reality. Questions Is showing the day before the renewal date the official/expected behavior? If so, could Apple clarify that the “Expires on” label represents the last full calendar day rather than the exact expiry timestamp? Which value should we surface in-app when telling users “Your subscription is valid until …”? The server’s expiresDate (precise to the second, converted to user time zone), or A UI-style date that’s one day earlier, matching Settings / App Store? Does Apple have a public document describing this rounding/visual convention? Have other developers encountered user confusion about the apparent 1-day “shortening” and, if so, how did you word your in-app messaging? Any insight from Apple engineers or fellow developers would be greatly appreciated. Thank you!

How do I escalate for app review rejection, my app gets rejected, but there are apps with the same modal but for a disfferent company doing exactly what I was rejected for? This looks like double standards to me, and it feels completely unfair, and all the reviewer does is paste in a section of the policy that is no help whats so ever. The issue is, a community app and people join the community through the web site, and the app is a utility extension for the users, but my app is rejected saying I must offer in app purchase, but another couple of apps doing exactly the same thing are not offering in app purchasing capability, but do link to their web site where purchasing is available?

Went through several rounds of rejections this week and finally the app was approved. Unfortunately I just discovered that my Subscriptions and Localization are still "In Review" and "Waiting for Review". It's baffling to me that either the reviewer could overlook this or the system allows for this scenario. All issues flagged in the review process were addressed as requested too. I've already emailed and called about this but they have no eta on when it will be resolved. This seems entirely preventable and it's very frustrating as this has delayed my release. Is there anything else I can do to get this resolved?

I am a test engineer. When I subscribe with a sandbox account in a test project, I find that the prompt "Not allowed to create an iTunes account" appears, but my account was successfully added in the sandbox. I tried two different email suffixes @gmail.com and @tester.com, and both showed this prompt. The developers in the team were also unable to solve this problem. Does anyone know how to deal with this situation?

Hi. My company has a product that has been launched on a web app, a mobile app and an extension in Chrome browser. Currently we are building the extension for Safari, however, we have been rejected. According to Apple, the reason is that we offer Premium feature inside the extension; however, the extension doesn't offer any purchase option. Has anyone had experience with this? Do we need to develop the purchase function within the Safari extension? Our product has both Free plan and Premium plan that is subscription-based. We have offered a purchase feature on the website, on the web app, and mobile app

Hi everyone, We're working on a fitness and wellness app that offers subscription-based content like workout videos, nutrition plans, and personal coaching. We've read the updated documentation on the External Link Account Entitlement (ELAE), which allows certain apps to include a link to an external website for account management and payments. However, based on what Apple describes as eligible “reader apps” (video streaming, books, audio, etc.), it's unclear whether fitness apps can apply for and use this entitlement. Our questions: Can a fitness app use the External Link Account Entitlement to link out to a web-based subscription page? If not currently supported, is there any plan to expand this to other categories like health & fitness? We are fully compliant with App Store IAP rules today, but we're exploring all legitimate options as we aim to provide a smooth and transparent experience across platforms (iOS, Android, and web). Any insights from the community or Apple team would be appreciated! Thanks, Onur Hazar

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