Hello, I’m integrating promotional offers for auto-renewable subscriptions using StoreKit 2. The offer is displayed correctly, the Apple purchase sheet appears, and I can start the payment flow. The sheet shows the correct discounted price and the end date of the offer. However, after confirming the purchase, an alert appears saying “Unable to Purchase - Contact the developer for more information” When dismissing the alert, Xcode logs the following: Purchase did not return a transaction: Error Domain=ASDServerErrorDomain Code=3902 "No se ha podido realizar la compra" UserInfo={ NSLocalizedFailureReason=No se ha podido realizar la compra, client-environment-type=Sandbox, AMSServerErrorCode=3902, storefront-country-code=ESP } Test environment: App installed from Xcode on a real iPhone Logged in with a Sandbox Apple ID Using StoreKit 2 Promotional offer applied using: Product.PurchaseOption.promotionalOffer(_:compactJWS:) On the server side, I generate the promotional offer signature exactly as described in Apple’s documentation: https://developer.apple.com/documentation/storekit/generating-a-signature-for-promotional-offers The signature is generated using a Subscription Key Signed with ECDSA + SHA256 Uses the correct invisible separator (U+2063) The signature is validated locally using the derived public key and verifies correctly The sandbox user has had previous subscriptions, which is why this promotional offer is eligible and shown. Given that: The offer is displayed correctly The purchase sheet shows the discounted price and duration The signature validates locally The error occurs only after confirming the purchase My question is: Is this a known limitation or issue with promotional offers in the Sandbox environment? Should promotional offers be tested exclusively via TestFlight instead of Sandbox? Any clarification would be greatly appreciated. Thank you!

I’m implementing a subscription purchase flow using promo code redemption via an external App Store URL. Flow: User taps “Purchase” in the app (spinner shown) App opens the promo redemption URL (apps.apple.com/redeem) User completes redemption in the App Store User returns to the app The app must determine whether the subscription was purchased within a reasonable time window The app listens to Transaction.updates and also checks Transaction.currentEntitlements when the app returns to the foreground. Issue: After redeeming a subscription promo code via the App Store and returning to the app, the app cannot reliably determine whether the subscription was successfully purchased within a short, user-acceptable time window. In many cases, neither Transaction.updates nor Transaction.currentEntitlements reflects the newly redeemed subscription immediately after returning to the app. The entitlement may appear only after a significant delay, or not within a 60-second timeout at all, even though the promo code redemption succeeded. Expected: When the user returns to the app after completing promo code redemption, StoreKit 2 should report the updated subscription entitlement shortly thereafter (e.g. within a few seconds) via either Transaction.updates or Transaction.currentEntitlements. Below is the minimal interactor used in the sample project. The app considers the purchase successful if either a verified transaction for the product is received via Transaction.updates, or the product appears in Transaction.currentEntitlements when the app returns to the foreground. Otherwise, the flow fails after a 60-second timeout. Questions: Is this entitlement propagation delay expected when redeeming promo codes through the App Store? Is there a recommended API or flow for immediately determining whether a subscription has been successfully redeemed? Is there a more reliable way to detect entitlement changes after promo code redemption without triggering user authentication prompts (e.g., from AppStore.sync())? import UIKit import StoreKit final class PromoPurchaseInteractor { private let timeout: TimeInterval = 60 private struct PendingOfferRedemption { let productId: String let completion: (Result<Bool, Error>) -> Void } private var pendingRedemption: PendingOfferRedemption? private var updatesTask: Task<Void, Never>? private var timeoutTask: Task<Void, Never>? enum DefaultError: Error { case generic case timeout } init() { NotificationCenter.default.addObserver(self, selector: #selector(willEnterForeground), name: UIApplication.willEnterForegroundNotification, object: nil) } deinit { NotificationCenter.default.removeObserver(self) updatesTask?.cancel() timeoutTask?.cancel() } func purchaseProduct(using offerUrl: URL, productId: String, completion: @escaping (Result<Bool, Error>) -> Void) { guard pendingRedemption == nil else { completion(.failure(DefaultError.generic)) return } pendingRedemption = PendingOfferRedemption(productId: productId, completion: completion) startPurchase(using: offerUrl) } @objc private func willEnterForeground() { guard let pendingRedemption = pendingRedemption else { return } startTimeoutObserver() Task { if await hasEntitlement(for: pendingRedemption.productId) { await MainActor.run { self.completePurchase(result: .success(true)) } } } } private func startPurchase(using offerURL: URL) { startTransactionUpdatesObserver() UIApplication.shared.open(offerURL) { [weak self] success in guard let self = self else { return } if !success { self.completePurchase(result: .failure(DefaultError.generic)) } } } private func completePurchase(result: Result<Bool, Error>) { stopTransactionUpdatesObserver() stopTimeoutObserver() guard let _ = pendingRedemption else { return } pendingRedemption?.completion(result) pendingRedemption = nil } private func startTransactionUpdatesObserver() { updatesTask?.cancel() updatesTask = Task { for await update in Transaction.updates { guard case .verified(let transaction) = update else { continue } await MainActor.run { [weak self] in guard let self = self, let pending = self.pendingRedemption, transaction.productID == pending.productId else { return } self.completePurchase(result: .success(true)) } await transaction.finish() } } } private func stopTransactionUpdatesObserver() { updatesTask?.cancel() updatesTask = nil } private func startTimeoutObserver() { guard pendingRedemption != nil else { return } timeoutTask?.cancel() timeoutTask = Task { try? await Task.sleep(nanoseconds: UInt64(timeout * 1_000_000_000)) await MainActor.run { [weak self] in self?.completePurchase(result: .failure(DefaultError.timeout)) } } } private func stopTimeoutObserver() { timeoutTask?.cancel() timeoutTask = nil } private func hasEntitlement(for productId: String) async -> Bool { for await result in Transaction.currentEntitlements { guard case .verified(let transaction) = result else { continue } if transaction.productID == productId { return true } } return false } }

is there a way to make a test subscription in-app purchase expire immediately, for faster testing? it seems exceedingly complicated to test subscriptions if we have to a) wait until the next day for expiry, or b) keep on creating new apple ids to get into a fully unsubscribed state? it is still kind of madness testing this stuff, after all the years it has been available.

There is a project that has been running online for years. A few months ago, a player reported that after making their first successful IAP at a specific purchase point, any subsequent attempts to purchase the same item do not trigger the payment window. Instead, they get the error:"This in-app purchase has already been bought".​After contacting Apple Support once, the player was able to make a payment, but the issue reappeared on the next attempt. So far, this is the only user reporting the problem, other people can purchase normally. Question1:​ Here’s what I’ve tried: I reviewed the code and ensured that TransactionObserveris correctly called. I’ve also added **[[SKPaymentQueue defaultQueue] finishTransaction:transaction]**in all possible places, but the issue persists. According to the logs, after the user’s first purchase, every subsequent IAP attempt returns the same receipt from the initial successful transaction, even though I’m certain finishTransactionis being called. It seems like this method isn’t having the intended effect. Question2:​ I asked the player to manually trigger the Restore Purchases​ button by calling [[SKPaymentQueue defaultQueue] restoreCompletedTransactions]. the restoreCompletedTransactionsFailedWithErrorcallback returned the following error: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." The player has already checked their device time and tried switching between Wi-Fi and 4G, but the error remains. Is this SSL error related to the "already bought" error?​ Note that this SSL issue occurred during a separate restore process, not during a purchase attempt. Question: 3:​ I noticed that I’m not calling finishTransaction​ inside the restoreCompletedTransactionsFailedWithErrorcallback. Should I add it there?​ Purchase Logs: ​The player clicked "Restore Purchases" and then attempted another purchase. The purchase flow appears normal, but the IAP returns an old, already-used receipt. [2025-12-10 17:41:38:995] Restore transaction failed: Error > Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a > secure connection to the server cannot be made." [2025-12-10 17:41:40:010] Restore transaction failed: Error > Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a > secure connection to the server cannot be made." [2025-12-10 17:41:42:011] buy method called... productID: > huoxiancj_648 orderID: 22674511 [2025-12-10 17:41:42:107] ----Log Observers ID---- [2025-12-10 17:41:42:108] ObserverID: 0x109968890 [2025-12-10 17:41:42:108] Processing unfinished transactions... [2025-12-10 17:41:42:108] Finished processing unfinished > transactions. [2025-12-10 17:41:42:108] Allowing in-app purchase... [2025-12-10 17:41:42:215] Requesting product info... [2025-12-10 17:41:42:989] productsRequest didReceiveResponse: [2025-12-10 17:41:43:066] Invalid Product ID: ( [2025-12-10 17:41:43:066] Purchase quantity: 1 [2025-12-10 17:41:43:066] Product info: [2025-12-10 17:41:43:067] Price: 648 [2025-12-10 17:41:43:067] Product ID: huoxiancj_648 [2025-12-10 17:41:43:067] Validating product info... [2025-12-10 17:41:43:067] Sending payment request... [2025-12-10 17:41:43:067] requestDidFinish [2025-12-10 17:41:43:132] paymentQueue updatedTransactions. [2025-12-10 17:41:43:133] updatedTransactions case > SKPaymentTransactionStatePurchasing [2025-12-10 17:41:43:208] [payment.applicationUsername] > userid=50306496 appid=1045 instid=12844 reserve=xxxx > productID=22674511 [2025-12-10 17:43:16:008] paymentQueue updatedTransactions. [2025-12-10 17:43:16:008] updatedTransactions case > SKPaymentTransactionStatePurchased [2025-12-10 17:43:16:008] productIdentifier= huoxiancj_648 [2025-12-10 17:43:16:113] Sending receipt to server for validation. [2025-12-10 17:43:16:113] Transaction completed. Any help or suggestions would be greatly appreciated! Thanks in advance.

Honestly, don't know how to test it in sandbox. I'm confused on if I need a sandbox to actually test out my in app purchase. Do I need to download something? Someone please help.

Hi, I am experiencing an issue where my in-app purchase products cannot be fetched from App Store Connect during sandbox testing, despite all products being properly configured. ERROR MESSAGE: When testing on a physical iOS device, I receive the following error: "Error fetching offerings - The operation couldn't be completed. (RevenueCat.OfferingsManager.Error error 1.) There's a problem with your configuration. None of the products registered in the RevenueCat dashboard could be fetched from App Store Connect (or the StoreKit Configuration file if one is being used)." All products show status "READY_TO_SUBMIT" with the warning: "This product's status (READY_TO_SUBMIT) requires you to take action in App Store Connect before using it in production purchases." I have 2 subscriptions and 4 Consumable in-app purchases set up in App Store Connect. VERIFICATION COMPLETED: Bundle ID matches exactly in App Store Connect, Xcode project, and RevenueCat dashboard Product IDs match exactly between App Store Connect, RevenueCat, and application code Paid Applications Agreement is signed and active (Signed on 12/9 morning, everything shows as active) All products are in "Ready to Submit" status with complete metadata All products are properly linked to the app in App Store Connect Testing on physical iOS device (not simulator) with sandbox account signed in via Settings > Developer section Products have been in "Ready to Submit" status for 8 hours I have researched this error and verified the common causes (Paid Agreements, Product ID mismatches, Bundle ID mismatches) are all correctly configured on my end. QUESTION: Is this an issue on Apple's end, or are there additional requirements for products in "Ready to Submit" status to be available in sandbox testing? I have been unable to test my in-app purchases despite all configuration appearing correct. Thank you for your assistance.

Hello, I have a problem with a subscription: it is not recognised by my application (under TestFlight); it is as if it did not exist. I have two subscriptions in the same group, a premium subscription that works perfectly and a basic subscription that is not recognised. I have checked everything at least twenty times. Its status is ‘Ready to submit’. I asked GPT 5.1 and Claude AI, but clearly both of their AIs are out of date and are giving me an obsolete procedure with App Store Connect options that don't exist.

Hi there, I have a plan of creating another app in the same niche, but I would like the actual subscribers to have access to the new app. So the subscribers of App 1 don't need to subscribe to App 2. Is that possible? Thanks Pedro M.R. Gregorio

会员等级进行升级？需要按天计算费用，像爱奇艺这样是怎么做的？

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.

As a developer I have a question I would like cleared up. We offer two tiers of annual subscriptions in our apps. These subscriptions are under the same subscription group in App Store connect. My question is, if a user purchases tier 1 of the annual subscription for $10.00, and uses it for 6 months; then chooses to upgrade to tier 2 which costs $20.00 per year. Would the user be pro-rated the difference in price i.e. charge only another $10.00 at the time of the upgrade., or are they charged $20.00 and then refunded the difference in their remaining lower tier subscription? I keep finding inconsistent answers across the Apple community forums on this.

I have an iOS and iPadOS app that also runs on macOS Catalyst. The user is able to view their subscription using the SubscriptionStoreView with two SubscriptionOptionGroups. The documentation does not mention these are supported on macOS Catalyst and the app crashes when attempting to show the SubscriptionStoreView on macOS Catalyst. If not supported, how can the user manage their subscription on macOS?

Dear Apple Developer Support Team, I hope you are doing well. We are reaching out to request clarification and guidance regarding the In-App Purchase (IAP) requirements for our upcoming iOS application. Our app offers paid access to digital video content. Each video has a dynamic price determined by our backend based on multiple factors (such as duration, category, and promotions). Additionally, users are allowed to select and purchase multiple videos at the same time, which results in a combined total price that varies per transaction. Challenges we face with IAP on iOS Dynamic pricing: Apple requires IAP products to have static pricing defined in App Store Connect. Our video prices change frequently and cannot be represented by fixed IAP product SKUs. Multiple-item purchases: iOS does not support a single purchase that includes multiple different IAP products. Processing many separate IAP transactions in sequence results in a poor user experience and is likely to cause failures. Product creation limitations: Since our catalog contains many videos with frequently changing prices, it is not feasible to create individual IAP products per video. Given these restrictions, we are unclear how to remain compliant while still providing a functional purchase flow for our users. Question In this scenario, where: video prices are dynamic, users may purchase multiple videos together, and IAP does not support multi-item purchases or dynamic pricing, are we allowed to use Stripe or another external payment provider to handle these purchases? If not, we would appreciate Apple’s guidance on what the recommended and compliant approach would be for apps that must price digital content dynamically and allow bulk purchasing. We want to ensure full compliance with App Store Review Guidelines and would like confirmation on the correct implementation strategy before proceeding. Thank you for your time, and we look forward to your clarification. Kind regards, Muhammad Adnan Koderlabs

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.

Some users cannot repurchase a subscription SKU after it has expired. Flow: User previously subscribed. User canceled and the subscription fully expired. After weeks, user reinstalls the app and taps the same SKU. StoreKit does not create a new purchase transaction. Instead, StoreKit always returns the old expired transaction in updatedTransactions. Therefore, the user is permanently unable to purchase the SKU again. We have already tried: Adding payment observer at app launch Calling finishTransaction for all transactions Clearing queue at startup SKReceiptRefreshRequest Server-side verifyReceipt Ensuring subscription is truly expired (not in grace/retry) Not calling restoreCompletedTransactions None of these resolved the issue. StoreKit still only sends the old transaction and never generates a new one. Expected behavior: A new purchase transaction should be created when user taps the expired subscription SKU. Actual behavior: StoreKit repeatedly pushes the old expired transaction, blocking new purchases. We can provide: Some users cannot repurchase a subscription SKU after it has expired. Flow: User previously subscribed. User canceled and the subscription fully expired. After weeks, user reinstalls the app and taps the same SKU. StoreKit does not create a new purchase transaction. Instead, StoreKit always returns the old expired transaction in updatedTransactions. Therefore, the user is permanently unable to purchase the SKU again. We have already tried: Adding payment observer at app launch Calling finishTransaction for all transactions Clearing queue at startup SKReceiptRefreshRequest Server-side verifyReceipt Ensuring subscription is truly expired (not in grace/retry) Not calling restoreCompletedTransactions None of these resolved the issue. StoreKit still only sends the old transaction and never generates a new one. Expected behavior: A new purchase transaction should be created when user taps the expired subscription SKU. Actual behavior: StoreKit repeatedly pushes the old expired transaction, blocking new purchases. We can provide: Affected user’s base64 receipt verifyReceipt full response Transaction logs (transactionIdentifier, original_transaction_id, productIdentifier, state) Please help investigate why StoreKit is not allowing a new subscription purchase. Affected user’s base64 receipt verifyReceipt full response Transaction logs (transactionIdentifier, original_transaction_id, productIdentifier, state) Please help investigate why StoreKit is not allowing a new subscription purchase.

Hello, We are having an issue with the RequestReview API and were hoping to get some help. We know that there is no guarantee that the in-app review modal will show and we know that there are 3 circumstances in which it will definitely not appear: if the user has turned off in-app review/ratings in their settings if the user has submitted a review for that app on that device within the last 365 days if the user has been asked for a review >3 times in the last 365 days When testing our implementation, every single one of our testers did not receive the rating modal despite the fact that we had all our testers turn on the app rating setting and that we have never asked for reviews from our app before. So that seems suspicious. While it is possible that something is up with our code (and I have provided some snippets below) we are also concerned that apple maybe is suppressing it for another reason. We really want to go live with our app review code but unfortunately we are not able to get confidence that it will ever appear for the user. Can you please help us understand why this isn't working. The code: We are using the SwiftUI approach to requesting review. Here are some relevant code snippets Important to note, we have a modal that appears when the user is in our list of active, targeted users. If they tap yes on this modal, it should show the in app rate the app system modal. If they tap no, we present them with an airship survey so that they can give feedback. Here is the code for the Yes button action: @Environment(\.requestReview) private var requestReview private var yesButton: some View { Button( action: { dismiss() requestReview() }, label: { Text(Lingua.General.appRateFirstButton) .regularParagraph() .frame(width: 180, height: 35) } ) .customButtonStyle( foregroundColor: .black, backgroundColor: Color(.powderBlue), radius: 36 ) } and this is the logic we use to determine whether we want to show them the modal in the first place. Obviously, a lot of this code leads to deeper areas in our logic and code but to give an idea... private func showAppRateModalIfNeeded() { if preferencesManager.appRateReviewShown == nil, accountManager.userAccount?.permissions.rateTheApp == true { let appReviewModalVC = UIHostingController(rootView: AppReviewModal()) appReviewModalVC.view.backgroundColor = .init(white: 0, alpha: 0.6) appReviewModalVC.modalPresentationStyle = .overFullScreen appReviewModalVC.modalTransitionStyle = .crossDissolve parentVC?.navigationController?.present(appReviewModalVC, animated: true) preferencesManager.appRateReviewShown = true } } When testing in debug, we do find that the modal appears and works as expected. However, on release builds nobody is able to trigger it. Why? Are we doing something wrong here or is Apple just suppressing it. We are thinking about implementing the button taking the user directly into the app store review but we'd prefer to do the lower-friction dialog in-app if we can get it work so the user doesn't get sent out of the app.

StoreKit ask to buy should have more data in pending state. When user try to purchase ask to buy, we should get at least transactionID, product itself, and time that user start the request. So we can keep track of the whole transaction flow jwsRepresentation should always available for every state, actually even failing state. And should attach state inside of it. Instead of only available after verified purchase. So we can use transactionID and everything relate to transaction for both waiting for purchase and clearing up the cancel or invalid purchase Currently we only have jwsRepresentation after complete purchase, which is very limited its usage

We feel like we're at the end of the long and treacherous process of migrating to StoreKit2. But we've hit a small snag. When testing in the sandbox environment, we've found that if we don't finish a transactions, no subsequent purchase (invoked via call to purchase or the other purchase) will produce the confirmation sheet. Is this the expected behavior? The behavior is observed on iOS26 and 18. Our app will only attempt to finish the transaction if it successfully uploads the receipt to our API. If it fails to do so for whatever reason, the transaction is left unfinished. Whilst the user is informed about this, users will commonly try again. Our concern is that since the confirmation sheet will not be shown again, users will not know they are actually paying again - most certainly not the UX we want to have. We'd much rather have our users be fully aware when they're paying us money. The reason we're choosing not to finish the transaction until our backend has received it and confirmed the receipt to be valid is that the only way the user can get their product is if the server side is aware of this and add more time to the users account. When finishing the transaction via finish immediately after the purchase() call, the confirmation sheet is shown every time after subsequent calls to purchase(). Again, is this the expected behavior both in the sandbox and the production environments? Are we doing something wrong or misusing the product API? We are somewhat stumped because technically, we could get the first confirmation for a product purchase, and then finish it only after an arbitrary amount of calls to purchase() have been made - the user will believe they will have paid only once, but we will receive however much money we can drain from their account - most certainly not the kind of app we want to develop. Please advise and best regards, Emīls

最近我们有个应用要对接App 内购买项目，有什么好的资料或者demo提供一下吗？

I would like to inquire about the originalTransactionId of StoreKit2. Users who purchase auto-renewal subscription products To re-purchase the same subscription item after cancellation and prior to refund If you receive a refund after cancellation and re-purchase the same subscription item If you do not renew immediately after expiration and re-purchase the same subscription after a long period of time I would like to ask if 1, 2, and 3 all use the same value as the original Transaction Id at the initial subscription. In the case of 3, if you re-purchase more than a few days after the last subscription purchase, please let me know if there are any detailed conditions such as the original Transaction Id not maintained.