We uploaded to App Store Connect a new app version with new subscription groups & items. Everything was approved, and we received the emails from App Store connect, but if we visit our App Store Connect account App, some of these subscription items are still "Waiting for review" for more than 4 days. It has no sense as the email informed us that the new app version and all the items had been approved. The app is online, but some subscription items are not available. We even uploaded a new app version, it was updated, but the subscription items are still "Waiting for review". Has anyone faced this problem? How do you solved it? We have contacted App Store Connect but it is pretty difficult to get real assistance, most of the time they reply with template email answers.

We have implementend Storekit 2 in our app, for one time purchases and subscriptions, so it is iOS15 and higher only. Everything works fine, but now we want to add App Store promotions for our IAP's. That doesn't work because the App requires the app to implement SKPaymentTransactionObserver How to Promote Your In-App Purchases Make sure your app supports a delegate method in SKPaymentTransactionObserver. You can choose to customize which promoted in-app purchases a user sees on a specific device by implementing SKProductStorePromotionController. The problem is that this observer is part of the original Storekit API and not of the new one. What can we do to make this work with the new Storekit 2 API?

I have auto-renewable subscriptions, and in Xcode everything works fine. It shows a list of subscriptions where I can make a test purchase. But when I send it for review, the review team, as well as TestFlight, simply do not have subscriptions. If the problem was in the code, it would not work in the sandbox as I think. But I think that I configured everything correctly in the subscription settings. The only thing: it shows there for the subscription in appstoreconnect that it is preparing for review, but nothing can be done about it, because it will be solved with the first release of the application. But I do not know where else to look and what to do. The problem is probably not in the code, but I also redirected the subscription config in appstoreconnect a bunch of times. I asked help on review team, no way. Tried to google and chat GPT, no ideas where to find a solution.

Hello, I would like to draw your attention to the following imperfection. For validating purchases of my paid application Guru Maps Pro, I use the download id. This is a unique ID that can replace the Transaction ID for paid applications. However, with the release of the new AppTransaction API, this field is no longer present in the data. I tried parsing the receipt, but that field is absent there as well. The only way to obtain the download id is to send the receipt to the deprecated /verifyReceipt endpoint. This deprecated status concerns me, because at some point it might stop working. Let me explain a little about why I need this. My users have a guru-account, which they can use both in the web version and on Android. When a user purchases the paid version of the application, they can access the paid features on both web and Android. This works great for in-app purchases, where there is a transaction ID, but it may soon stop working for paid applications because there is no way to determine any ID associated with the purchase. Transaction ID or Download ID – I don't mind which.

I'm adding my first in-app purchase to an app, and I'm finding the process incredibly frustrating. Aside from the Apple Developer Documentation not being clear enough, and kind of glossing over the technical steps required (and their sample code being woefully inadequate), App Store Connect and the testing sandbox simply don't work as they say they do. For example, in my app I've purchased the IAP and now I want to request a refund. I select the purchase, I choose a refund reason, and this page says, "To set up a test for approved refunds, select any refund reason on the refund request sheet, and submit the sheet. The App Store automatically approves the refund request in the testing environment." Well, when I re-launch the app the purchase is still there. I can't request a refund again because it says this is a duplicate refund request, so it knows that the purchase has had a request, and it's supposed to have automatically refunded it, but it clearly hasn't. So, I try clearing the purchase history via the Settings app > Developer > Sandbox Apple Account. Same thing. Purchase remains. Try clearing purchase history in App Store Connect. Same thing. How on Earth does anyone get an in-app purchase to work when the entire testing environment is so badly executed? How do I get past this? The IAP is the last part of the app that needs to be implemented, and I've lost a week on this already.

Hi, all! I am wondering about something about App Receipts. I'm using App Receipt hash to key some information server-side. I'm curious however, if that doesn't actually have a possible flaw. Is it possible to get a new receipt that would yield a different hash for the same transaction? Reinstalling the app, perhaps? Installing the app on a new phone? Basically, I want to make sure this hash is something I can rely on. If the user can get a new hash for the same purchase, that's obviously problematic. Thanks!

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.

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.

Hi, all! I have an AppStore Server-side question. User sends up an AppReceipt that I am validating. What's the best way to tell the receipt belongs to said user? I want to make sure that the source of the AppReceipt was actually the original purchaser of the item. Is fetching Transaction + AppAccountToken the only way? AppAccountToken can only be utilized if the original purchase used it, and it is associated with the user's data. Is there another way?

Hi apple team, I'm using Apple Root Certificates from https://www.apple.com/certificateauthority/ for communicating with App Store Server Library for receipt validation API. Apple Computer, Inc Root certificate from the website is Not Valid After: Monday, 10 February 2025 at 01:18:14 Central European Standard Time. When we can expect update of this certificate. Thank you

Hello everyone, I’m hoping someone might help with auto-renewable subscription validation in Apple’s Sandbox environment. Here’s the situation: My Setup: I’ve configured three auto-renewable subscriptions in App Store Connect and generated an In-App Purchase key (with the correct Issuer ID and Key ID). (I also tried the App Store Connect API Keys) I’m using Apple’s App Store Server API v2 endpoints (GET /inApps/v2/subscriptions/{originalTransactionId}/latest) to fetch the latest subscription status. I’ve created several Sandbox test users (with fresh email addresses), signed out of old test accounts on my devices, and tested purchasing subscriptions anew. What Works: I am receiving valid Server Notifications from Apple (e.g. SUBSCRIBED, DID_RENEW) with the correct environment: "Sandbox" field. My JWT generation appears to be correct because I’m no longer receiving 401 errors—only 404. That suggests Apple accepts the key and credentials. My fallback logic attempts production first; if it sees a 404 or 410, it switches over to the Sandbox endpoint. This is exactly what Apple’s documentation recommends. The Problem: Whenever I query GET https://api.storekit-sandbox.itunes.apple.com/inApps/v2/subscriptions/{originalTransactionId}/latest using the originalTransactionId from Apple’s own Server Notification, Apple returns a 404 (indicating it can’t find that subscription). This happens even though the subscription is active in Sandbox (I see notifications arriving for it). I’ve tried adding a brief waiting period (2 seconds) before calling the Sandbox endpoint, but it consistently returns 404. I’ve also tried multiple retries over a longer timeframe without success. I tested multiple fresh Sandbox test users, ensuring each one was signed in to the device’s App Store. After each new purchase, I still get the same 404. Additional Checks: These are definitely auto-renewable subscriptions, not non-renewing or consumable products. I also tried calling GET /inApps/v2/subscriptions/{transactionId}/latest but I still see 404. I tried everything mentioned above in production as I said to no avail: GET https://api.storekit.itunes.apple.com/inApps/v2/subscriptions/{originalTransactionId}/latest

We are in the process of implementing promotional offers for auto-renewable subscriptions in our app using StoreKit 2. For testing, we use a sandbox user alongside a new user on our platform. I can successfully purchase an Introductory Offer through the app. Once the user is eligible for a Promotional Offer (based on a previous purchase), we retrieve the Promotional Offer identifier and signature from our backend and display the offer. After initiating the purchase and having the user enter their Sandbox password, the transaction is added to the Payment Queue. However, it fails with the following error: Purchase failed error: invalidOfferSignature Additionally, the error returned is: "Purchase did not return a transaction: Error Domain=ASDServerErrorDomain Code=3903 "Unable to Purchase" UserInfo={NSLocalizedFailureReason=Unable to Purchase, client-environment-type=Sandbox, AMSServerErrorCode=3903, storefront-country-code=IND}" We are using StoreKit 2 APIs for this process. Has anyone encountered this issue when working with StoreKit 2, or found a solution to resolve it?

Hi, I've been reported, and I've experienced myself, extremely slow responses from StoreKit 2 on boot. I can reproduce the issue quite consistently with the iPhone, sometimes Transaction.currentEntitlements hangs for minutes even after the device has attained full Internet access. My app is a VPN client, so there's certainly a chicken-and-egg situation, but I'm performing a basic test without the in-app validation in the packet tunnel provider. The tunnel starts fine on boot (on-demand), whereas the app takes ages to return from AppTransaction.shared and Transaction.currentEntitlements. I guess this is caused by some network call inside the framework (maybe spoiled by the on-demand VPN?), but with no timeout, exceptions, logging, or future-proof fallback (appStoreReceiptURL is deprecated), I'm poking in the dark. It goes without saying, keeping the users waiting minutes to be credited for their purchases is a no-go. I still can't find a reasonable workaround, but the frustrating part is that StoreKit 2 was supposed to make these things straightforward. At times, it doesn't feel "ready" and I spend on it a lot of time that I'd rather invest in the product. Does this sound familiar to anybody? Thanks in advance Davide

Hello. My newly released app includes a 1 day free trial. I've done this by creating a non-consumable in-app purchase priced at 0. I consider the free trial active if there's a transaction (from Transaction.currentEntitlements) for that product such that transaction.originalPurchaseDate is less than 24 hours ago. This works fine locally in the simulator and also in TestFlight, however it does not seem to work in the actual app from the App Store. The user can "purchase" it fine; they see the purchase sheet with the product name and the $0.00 price, and when they double press the side button it all seems to work. However, the app then behaves as if it didn't work. The free trial product is no longer available though. One thing is that I didn't follow the naming convention “XX-day Trial”. Could that be the problem? If so, is that meant to be for the product reference name?

Hi all, I am adding the following StoreKit 2 code to my app, and I don't see anything in Apple's documentation that explains the unverified case. When is that case exercised? Is it when someone has tampered with the app receipt? Or is it for more mundane things like poor network connectivity? // Apple's docstring on `shared` states: // If your app fails to get an AppTransaction by accessing the shared property, see refresh(). // Source: https://developer.apple.com/documentation/storekit/apptransaction/shared var appTransaction: VerificationResult<AppTransaction>? do { appTransaction = try await AppTransaction.shared } catch { appTransaction = try? await AppTransaction.refresh() } guard let appTransaction = appTransaction else { AppLogger.error("Couldn't get the app store transaction") return false } switch appTransaction { case .unverified(appTransaction, verificationError): // For what reasons should I expect this branch to be entered in production? return await inspectAppTransaction(appTransaction, verifiedByApple: false) case .verified(let appTransaction): return await inspectAppTransaction(appTransaction, verifiedByApple: true) } Thank you, Lou

Inquire the types of notifications that can occur in a SANDBOX environment Hello, WWDC 2024 is trying to conduct a test to receive notifications related to ONE_TIME_CHARGE, CONNSUMPTION_REQUEST, CONMSUMPTION_INFO, REFUND, and REFUND_DECLINED as described in the example of purchasing consumables, but as a result of the continuous search, I found that it is difficult to occur except for ONE_TIME_CHARGE. So, in order to verify only the business logic as shown below, we are testing only the business logic without actually calling the API after purchasing the test and saving the signaled Payload that we received in response to ONE_TIME_CHARGE. Can we actually request a refund for the test purchase and receive the corresponding notification and actually send the response? public void handleSignedNotification(String signedNotification) throws Exception { ResponseBodyV2DecodedPayload payload = signedDataVerifier.verifyAndDecodeNotification(signedNotification); NotificationTypeV2 type = payload.getNotificationType(); //For Apple Server Notification, only ONE_TIME_CHARGE notifications are enabled in the test environment, so for testing, change them as below to test whether they are running business logic type = NotificationTypeV2.REFUND; log.info("Apple NotificationType : {}", type); switch (type) { case CONSUMPTION_REQUEST: handleConsumptionRequest(payload); break; case REFUND: handleRefund(payload); break; case REFUND_DECLINED: handleRefundDeclined(payload); break; // For other necessary notifications, just take a log default: log.info("Unhandled notification: {}", type); } } Regarding the call of 'CONSUMPTION_INFO', which is the response of 'CONSUMPTION_REQUEST' Is there a value that WWDC 2024 must include when sending CONMSUMPTION_INFO, which is the response to CONNSUMPTION_REQUEST described in the refund example? I'm going to call the API with only sample provision and consumption like the sample code you introduced in the video. I was told to submit my refund preference within 12 hours, but can I submit it as UNDECLARED at first and use the method to express my intention? When I receive the notification, I will save it in the DB and save it in the administrator page of the service so that the administrator can choose. 2-1. Some of the materials I looked for are told that Apple can proceed with the refund even 12 hours ago, and to express your opinion as soon as I receive the notification, but I wonder if this is correct. If you get a notification as below, you should write whether you used it or not by referring to the consumption information. I think the customer said to check whether the data was provided when applying for a refund. Should I take it out of decodedTransaction, check the value, and just call it NO_PREFERENCE? I'd appreciate it if you could give me some advice. Below is a part of the code I implemented. private void handleConsumptionRequest(ResponseBodyV2DecodedPayload notification) throws Exception { // 1. transaction ID get String signedTransactionInfo = notification.getData().getSignedTransactionInfo(); JWSTransactionDecodedPayload decodedTransaction = signedDataVerifier.verifyAndDecodeTransaction(signedTransactionInfo); String transactionId = decodedTransaction.getTransactionId(); // 2. Extract the relevant transaction (The following example is an in-app payment and will be accumulated in two types of DBs, stored in one of the two) Sample sample = sampleService.findByAppleTransactionId(transactionId); Example example = exampleService.findByAppleTransactionId(transactionId); Boolean canRefund = false; // 3. Check consumption information if (sample != null) { canRefund = checkSampleStatusForApplePurchaseRefund(sample); } else if (example != null) { canRefund = checkExampleStatusForApplePurchaseRefund(example); } // 4. Create Refund Preferences RefundPreference refundPreference = determineRefundPreference(canRefund); // 5. Creating a ConsumptionRequest Object ConsumptionRequest request = new ConsumptionRequest() .refundPreference(refundPreference) .sampleContentProvided(true); log.info("forTest~ canRefund: {}", canRefund); log.info("forTest~ sample: {}", sample.toString()); log.info("forTest~ example: {}", example.toString()); log.info("forTest~ refundPreference: {}", refundPreference); log.info("forTest~ request: {}", request); // 6. Transfer to App Store (annotated with dummy requests that only confirm current business requests are going right) // appStoreServerAPIClient.sendConsumptionData(transactionId, request); }

When simulating a Storekit error like an invalid device verification or others of that type, should we finish a failed transaction? When I test with a storekit configuration file, all failed transactions persist after every restart. The Apple-provided sample code for storekit 2 has transactions finished only when they are successful.

I am looking to move from paid app to fremium without upsetting my existing users. I see WWDC2022 session where new fields introduced in iOS 16 are used to extract original application version user used to purchase the app. While my app supports iOS 14 and above, I am willing to sacrifice iOS 14 and go iOS 15 and above as StoreKit2 requires iOS 15 at the minimum. The code below is however only valid for iOS 16. I need to know what is the best way out for iOS 15 devices if I am using StoreKit2? If it is not possible in StoreKit2, then how much is the work involved in original StoreKit API(because in that case I can handle for iOS 14 as well)?

Greetings! I was reviewing the documentation for the Apple Store Server Notification v1 APIs and saw the deprecation notice. We are currently unable to migrate to v2 in the near future. With that in mind, I want to know if there were any plans to shut off v1, and if so, was there any timeline we could expect? Thank you in advance. Reference: https://developer.apple.com/documentation/appstoreservernotifications/app-store-server-notifications-version-1

I encountered a scenario involving a subscription and need to determine if it's a problem or an expected outcome. Here are the details: My service received a notification from Apple of type DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. The status field received on the payload was equal to 1 - Active. (2024-12-19T15:34:53.801) My service again received a DID_CHANGE_RENEWAL_STATUS with subtype AUTO_RENEW_DISABLED. But the status field received was 2 - Expired. (2024-12-19T23:34:57.527) My service received an EXPIRED with subtype VOLUNTARY notification. (2024-12-19T23:35:01.669) Is the event 2 an inconsistent event? Since we are receiving a notification that means the auto renew was disabled when the subscription was already expired.