Hello, I recently saw this error from StoreKit in the Console - 'Invalid value for purchase intake' - while debugging a SKPayment subscription issue (where a valid receipt should be verified and restored, but isn't for one user). I haven't been able to find any documentation about this message and wondered if it was related at all. There were two other logs from StoreKit right before saying: 'Found 3 products in receipt with ID' 'Processing ad attribution purchase intake' Does anyone know what 'invalid value for purchase intake' is referencing? We don't have the AdAttributionKit implemented. It sounds like it might be related to that instead? Thank you

If you are experiencing an unexpected or inconsistent behavior when using the App Store Server Library, review the following resources to ensure that your implementation workflow didn’t cause the issue: Simplifying your implementation by using the App Store Server Library Explore App Store server APIs for In-App Purchase Meet the App Store Server Library If you are unable to resolve your issue using the above resources, file a GitHub issue. Alternatively, if you wish to provide specific requests, transactions, or other private information for review, submit a Feedback Assistant report with the following information: The bundleId or appAppleId of your app The date and time your issue occurred The library language(s) The version of the library The environment (i.e., Production, Sandbox, or Xcode) The GitHub issue for this report if available The endpoint(s) reproducing your issue The HTTP body and headers of the endpoint raw request The HTTP body and headers of the endpoint response 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 Library” 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 and how to reproduce it. 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.

This question is about In-App Purchase. This is an inquiry from one of our customers. We have set up a free trial. This is your first time using the service, but you have stated that you have been charged. Document. https://developer.apple.com/documentation/appstorereceipts/is_trial_period 「You can use this value to determine whether the specific record is in a subscription trial period. If a previous subscription period in the receipt has the value "true" for either the is_trial_period or is_in_intro_offer_period keys, the user is not eligible for a free trial or introductory price within that subscription group.」 Our expectation is that is_trial_period is true. Receipt is not contain is_trial_period : true or is_in_intro_offer_period : true. Only one case has occurred. Other customers are no problem.

Hi everyone, I’m facing a recurring issue with my macOS app being rejected during App Store review, and I’d really appreciate any guidance. The subscription flow in my app is implemented using StoreKit, and everything works perfectly in our development environment using a StoreKit configuration file. It also behaves as expected in Sandbox testing and TestFlight — I even had few beta testers confirm that the subscription information is displayed correctly and the purchase flow completes without issues. All required subscription details are configured in App Store Connect: • Subscription duration and the description of the services offered • Price and price per unit where applicable • Paid apps agreement and related forms are correctly filled However, when the app is submitted for review, the subscription screen fails to display the expected information. From what I can tell, the product information fails to load from the App Store in the review environment — even though everything is working fine on our side. We’ve already submitted a video to Apple showing the subscription UI working in the Sandbox environment, but the app continues to be rejected under guideline 3.1.2 due to missing subscription info in the binary. Is anyone else experiencing similar behavior during review? Could there be a caching issue or delay in StoreKit syncing for newly configured products? Any help or suggestions are very welcome. Thanks in advance!

Hello, Our app supports family sharing skus, we successfully ran tests on family sharing features in sandbox, we noticed the feature does not work on live builds. The family member (child account) do see the subscription as "Shared with you". We attempted to restore multiple time and there is nothing to restore.

Hello, I'm encountering an issue when trying to use the subscriptionGroupLookups endpoint in the App Store Connect API. Despite having the correct setup, I continue to receive a 404 NOT FOUND error when making requests to: GET https://api.appstoreconnect.apple.com/v1/subscriptionGroupLookups Here is the current state of my environment: I am the Account Holder of the App Store Connect account The App Store Connect API key has been successfully created I have the correct Key ID, Issuer ID, and .p8 private key I can authenticate and access the apps and subscriptionGroups endpoints However, the subscriptionGroupLookups endpoint always returns: { "errors": [ { "status": "404", "code": "NOT_FOUND", "title": "The specified resource does not exist" } ] } I suspect that LookUp Keys (UUIDs) have not been assigned to our subscription groups, even though they were created and are active in App Store Connect. There is no “Request Access” button visible under the Integrations tab (as mentioned in Apple support instructions), and my keys appear under “App Store Connect API” > “Keys” as active. Questions: How can I ensure that LookUp Keys are assigned to my subscription groups? Is there a way to trigger this manually or via support? Has anyone successfully resolved this? Any advice or experience would be greatly appreciated. Thank you!

We are using consumable in-app purchases. Starting from May 27th, we began receiving refund callbacks with the notificationType set to ONE_TIME_CHARGE immediately after users successfully completed a payment. { "notificationType": "ONE_TIME_CHARGE", "signedPayload": "..." } During this period, we did not make any changes to our App release or server-side purchase handling logic. Could this issue result in actual refunds being processed? What steps should we take to resolve this issue? We also noticed in your changelog that a new notification type ONE_TIME_CHARGE has been introduced. Can we safely ignore callbacks with the ONE_TIME_CHARGE notification type without affecting refund processing or user experience?

I'm considering developing an app where users can create their own subscription plans by freely setting their prices, similar to YouTube's membership feature. I understand that in-app purchases must be used to unlock features within the app. With that in mind, I searched for APIs to enable this functionality but couldn't find relevant information. When I contacted Apple directly, they mentioned that they couldn't provide specific answers unless the app is under review. If anyone has knowledge about the following points, I would greatly appreciate your response: Is it possible to implement a feature similar to YouTube's membership using in-app purchase APIs? If it's not feasible with in-app purchases, is it allowed to use external payment services like Stripe?

Is there an API Endpoint that I can call to check if user still have valid subscription? I want to be sure that his subscription renewal was succesful (ie: I dont want to give him another month/year/.. if his latest renewal wasnt successful) Would GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId} be the correct API endpoint to call? But I wonder, after subscription auto-renews, do we still use the same transactionId to check whether his subs is still valid?

We're experiencing an unusual issue with SKProductsRequest in our app's in-app purchases. Despite confirming that all our product IDs are correct, the invalidProductIdentifiers property of SKProductsResponse sometimes contains all the requested product IDs. Here are the specifics: The issue occurs randomly and is not persistent. For instance, around 2024-12-26 -8.0 01:06:04, this problem occurred 3 times in quick succession. The didFailWithError method of SKRequestDelegate is not triggered, reporting no errors. Some users report that after encountering this issue, it resolves itself after about an hour. However, other users have reported this problem persisting for several days. We have repeatedly verified the correctness of our product IDs. Given the intermittent nature of the problem, we suspect this might be an issue on the App Store server side. We're looking for suggestions to resolve or mitigate this issue to improve the reliability of in-app purchases in our application. Has anyone encountered a similar issue? Or does anyone have suggestions that could help us further diagnose and resolve this problem?

Hi everyone, We operate an online game where all in-app assets are stored server-side and require a logged-in account (no device binding). I’d like guidance on four areas: Do we really need deviceVerification / deviceVerificationNonce? – Because every purchase is tied to an account and we enforce a global transactionId UNIQUE constraint, replay or cross-account reuse appears infeasible. Under these conditions, is omitting device verification acceptable, or are there situations where Apple still recommends it? Permanent rate-limit increase for the App Store Server API – During anniversary events we saw bursts of ~18 000 requests per hour, breaching the current hourly cap on the App Store Server API (verifyTransaction, getNotificationHistory, etc.). Is there a formal process to request a long-term rate-limit expansion (or an alternative tier) from Apple? When is an App Store Server API call required for a StoreKit 2 jwsRepresentation? Docs say “call the API if you’re unsure,” but there’s no clear cut-off. Because we fully validate the JWS signature plus the entire certificate chain (including CRL/OCSP checks) on our server, local cryptographic validation seems sufficient for consumables. For subscriptions we still plan to hit the API to fetch the latest status. Does this separation match Apple’s best practice? If Apple does recommend hitting the API for consumables as well, we’d like a concrete rule of thumb—e.g. “if the item price is USD 50 or higher, always use the API.” Is establishing such thresholds consistent with Apple’s intent? Refund-risk reduction from Send Consumption Info – Adapty reports a 40–60 % refund-rate drop for subscriptions when using Send Consumption Info (blog reference). Can we expect similar reduction for consumable IAP in social/online games? Any real-world results would be helpful. Thanks in advance for any guidance!

I have been struggling to test the IAP response but it is returning empty. I am now in the very beginning of one app, and I don't want to submit the contacts and banking and tax stuff that early. are these necessary for even testing IAP results locally? I think it does not make sense if I have to.

在沙盒环境下或者TestFlight 测试消费型项目会提示此项目将免费恢复

Is there an App Store Server API available that allows cancellation of specific subscriptions by specifying transaction_id or similar identifiers? Background of these questions: We occasionally suspend user accounts due to violations of our service terms and conditions. In such cases, we would like to forcibly cancel their subscriptions if possible. However, we could not find relevant information in the documentation, which is why we are reaching out with these questions. Please let us know.

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

The application is developed with Xamarin Framework and it is live now. The customer installed the app and purchased the annual subscription. And for some reason, they uninstall and reinstall the application on the same device. Now user wants to restore the subscription. In the application, there is an option to Restore the subscription. But restore API not return purchase details. But when clicking the subscription button instead of restoring the subscription, it says you subscribed to this plan". is there any possibility of not getting VerifyRecipt even after a successful purchase?

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

I am unable to sign in to a Sandbox Apple Account, where this issue occurs only via Simulator. Under Settings > Developer, I tap "Sign In" under Sandbox Apple Account. I enter my account credentials, and after bringing me back to the Developer page, the Sign In button briefly appears as disabled, before being re-enabled, without signing in to the account. (The account credentials are also recognized as correct, as I will receive an alert popup if incorrect.) See screenshots below: After signing in, Sign In button appears disabled... ... then is re-enabled without actually signing in to the account. I have now tried setting up multiple sandbox accounts via App Store Connect with various permutations (no confirmation of Apple Account email, confirming Apple Account email, logging in to iCloud and accepting terms of service), running different device simulators, running simulators on different Mac computers... none of which yield a different result. By contrast, I can sign in to the Sandbox Apple Account without issue on a physical device. The problem occurs only via Simulator.

I'm encountering an issue with In-App Purchases on Apple TV (tvOS): When a user initiates an IAP for the first time, the system prompts them to sign in with their Apple ID, and the purchase proceeds normally. However, on subsequent purchase attempts, if the Apple ID session has expired or additional verification is required, the system redirects the user to the Settings app to sign in again. After the user signs in via Settings, the app does not automatically return to the foreground. The user must manually press the Menu button to come back. Is this is the normal behaviour of apple tv for InApp purchase? or did I need any code improvement to solve this? What I'm trying to achieve: I'd like the app to automatically return to the foreground once the user has completed the Apple ID login in Settings. Is this behavior supported on tvOS? If not, is there any known workaround or best practice to guide the user back to the app smoothly? Any advice or guidance from Apple or other developers would be greatly appreciated!

I am finding that the verifyReceipt endpoint used to verify a receipt is failing on occassion starting around October 27, 2015. I realize this API is deprecated. I am using cURL to call verifyReceipt. The specific errors are 52 - Empty reply from server and 56 - Connection closed abruptly. This indicates an issue with Apple's server as I understand it. Is anyone else experiencing this as well?