I’m testing auto-renewable subscription purchases in the sandbox environment. When I buy a subscription package using a sandbox test user, I don’t receive any Apple Server Notifications from the sandbox. However, when I use the Request Test Notification option in App Store Connect, the notification is received successfully. My sandbox server notification URL is configured correctly and publicly accessible. I also call finishTransaction() after purchase. It looks like sandbox purchase notifications are not being sent, even though the test notification works fine.

Hi everyone, I'm an indie developer and recently noticed some odd behavior in my app's subscription metrics. There’s been a sudden spike in annual subscriptions, which is very unusual for my app — historically, users rarely choose that option. What’s more concerning is that these subscriptions are almost immediately canceled and refunded. Upon checking analytics (RevenueCat + App Store Connect), I also noticed inconsistencies in user location data: users appear to be from one region (like Singapore), but deeper tracking shows actual usage from Vietnam, a market I’ve never targeted and where I do no advertising. This behavior seems coordinated and is affecting my app’s refund rate, which I worry could raise red flags on the App Store side. Has anyone experienced anything similar? Is there a recommended way to report suspicious subscription/refund activity to Apple or prevent potential abuse like this? Any advice would be really appreciated. Thanks!

Currently, we are using the Apple V2 interface to develop the payment function. We generate a transaction ID on the mobile client and obtain the receipt. Now, when we call the Apple sandbox environment interface to verify the receipt, we always get a 404 error. The above is the request and response. The token used in it is also the original data after decoding, and there is no problem. Could you help me figure out what other possible reasons there might be?

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.

Hello! We are implementing consumable IAP for iOS using StoreKit 2 together with our own server backend. Our happy path looks like this: 1. Call /prepare on our server • We only allow one purchase at a time, so this fails if a pending transaction already exists. 2. Call /purchase via StoreKit 3. If successful, call /complete on our server 4. Call .finish() on the Transaction ⸻ The Problem Some users report being charged by Apple but not receiving coins. I suspect this happens in rare cases where the purchase flow throws an exception: • Every time we throw, we immediately cancel the transaction on our server. • However, some errors may actually be temporary. StoreKit seems to recover by later sending an update through Transactions.updates. • When that happens, since the transaction was already canceled on our server, we cannot match it. As a result, we just call .finish() without granting consumables. ⸻ Additional Observations From user logs, the issue tends to appear when the following errors are reported: • リクエストを完了できません。 • Triggered by: StoreKit.notEntitled • Triggered by: StoreKit.unknown • ヘルパーアプリケーションと通信できませんでした。 I was not able to reproduce the last one, even when testing all possible StoreKit configuration errors. Some sources suggest this may be a rare case where the app cannot communicate with the App Store itself. Additionally, affected users often seem to be using non-standard payment methods (PayPay, gift cards, carrier billing, etc.) rather than credit cards. ⸻ My Question What is the best practice for handling StoreKitError and PurchaseError? Specifically: • Should some of these errors be treated as temporary instead of final? • How should we ensure users always receive their consumables in such cases? ⸻ Code do { let result = try await wrapper.product.purchase() switch result { case .success(let result): let transaction = try StoreKitVerifier.checkVerified(result) let iOSPurchase = IOSPurchase(transaction: transaction, jws: result.jwsRepresentation) return .Success(purchase: iOSPurchase) case .userCancelled: return .Canceled() case .pending: return .Pending() @unknown default: return .Error( message: "Purchase result doesn't match with anything. This must not be executed") } } catch { return .Error(message: error.localizedDescription) }

I implemented consumable in-app purchases in an iPhone app using ProductView(). When I tap the payment button in ProductView(), I am taken to the payment screen and once the payment is completed the next code seems to be executed, so there doesn't seem to be a problem, but if I tap the payment button in ProductView() again, the next code is executed without taking me to the payment screen. This means that a single payment can be made multiple times. Can someone help? ProductView(id: "geminiOneMatch") .productViewStyle(.compact) .padding() .onInAppPurchaseCompletion { product, result in if case .success(.success(_)) = result { // 課金が成功した場合の処理 gemini.addOneMatch(amount: 20) popUpVM.geminiOneMatchPopUp = false dataManageVM.generateRespons(locale: locale) } }

We have some users who have upgraded to iOS 26 beta3. Currently, we observe that when these users make in-app purchases, our code calls [[SKPaymentQueue defaultQueue] finishTransaction:transaction]; method, and we clearly receive the successful removal callback in the delegate method - (void)paymentQueue:(SKPaymentQueue *)queue removedTransactions:(NSArray<SKPaymentTransaction *> *)transactions. However, when users click on products with the same productId again, the method - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions still returns information about previously removed transactions, preventing users from making further in-app purchases.

Hi everyone, I’m encountering an issue with my in-app subscriptions setup. When I test using the StoreKit configuration file in Xcode, everything works correctly — the subscriptions are fetched and I can simulate purchases without any issues. However, when I switch to the Sandbox or Production environment, my app fails to fetch the available products from Apple’s servers. The call to fetchProducts (from the expo-iap library) returns an empty array. Here’s some context about my setup: Framework: React Native (Expo Bare Workflow) Library: expo-iap Products: Auto-renewable subscriptions StoreKit Configuration: Synced with App Store Connect Status: Subscription Plans are approved in App Store Connect I’ve verified the following: The product identifiers in code match exactly with those in App Store Connect. The app is signed with the correct bundle ID. I’m testing with a Sandbox account (logged in via Settings -> Developer -> Sandbox Tester Account). Despite this, the response from Apple’s servers still contains an empty array. Has anyone experienced something similar with expo-iap or in general when moving from StoreKit configuration to Sandbox/Production? Any suggestions on what else I could check or common pitfalls I might be missing? Thanks in advance!

I am handling the buy subscription with this function const handleBuySubscription = async (productId) =&gt; { try { await requestSubscription({ sku: productId, }); setLoading(false); } catch (error) { setLoading(false); if (error instanceof PurchaseError) { errorLog({ message: [${error.code}]: ${error.message}, error }); } else { errorLog({ message: "handleBuySubscription", error }); } } }; but the requestSubscription({ sku: productId, }) does not return anything, and it is stuck at await

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 Apple Support Team, We're a developer team that has created an app with subscription-based features, and we've been using App Store Server Notifications to receive updates about user subscription status changes. I'm reaching out to inquire about potential modifications to the App Store Server Notifications approach that might have improved notification delivery times for my app. So on our appstore app, when a user purchases a subscription, the apple server notifications reach our server and send us the complete detail of that user’s purchase for eg he upgraded or downgraded etc. And then based on the data we receive from app store server notifications, we save it in our database, along with updating the users subscription table in the database. Previously, we experienced delays in receiving the real time notifications from apple on our server, sometimes taking a few minutes, while other times they would arrive immediately. And because of this issue, the users faced delay in seeing their subscription updates, as our db was updated only after the app store server notification reached our server. However, recently, we've noticed a significant improvement, and notifications are now being delivered still in real-time, but without any noticeable delays. I'm wondering if Apple has made any changes to the App Store Server Notifications system that might have resolved the delay issue. Could you please confirm if any modifications were made in 2025, specifically from January onwards, that might have improved notification delivery times? Additionally, I'd like to know if these changes apply to both sandbox testing and production environments. If possible, could you please provide more information about the changes or direct me to a resource that might explain the updates? I'd appreciate your assistance in confirming this information, and I'm looking forward to hearing back from you.

I encountered the following issues while developing in-app purchases; please help me: When attempting to purchase a product that has already been purchased, SKPaymentQueue reports an error instead of a success message: <SKPaymentQueue: 0x134665380>: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3532 "You’re currently subscribed to this." UserInfo={NSLocalizedFailureReason=You’re currently subscribed to this., client-environment-type=Sandbox, AMSServerErrorCode=3532, storefront-country-code=USA} After buying product A on one iPhone using a sandbox account, restoring purchases on another iPhone with the same sandbox account via paymentQueue.restoreCompletedTransactions(withApplicationUsername:) does not return the previously purchased product A data; it directly calls restoreCompletedTransactionsFinished.

I’m implementing StoreKit External Purchase Custom Links (EU) and so far it is really painful. I am running into a strange, device-specific issue. On 3/4 devices it works. On one device I never get a token at launch nor before a transaction. isEligible is true everywhere. All devices have versions 18.5 and are located in Germany. Info.plist: SKExternalPurchaseCustomLinkRegions is set to EU storefront codes and I have followed every step in the documentation: https://developer.apple.com/documentation/storekit/externalpurchasecustomlink Good device: At launch → ACQUISITION = nil, SERVICES = token present. Works consistently. Faulty device: At launch → ACQUISITION = nil, SERVICES = nil. Same before transaction. No token ever reaches my server from this device. isEligible is true on both devices. Any experts or help on the matter?

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.

I have three questions about verify receipt I use this api （https://buy.itunes.apple.com/verifyReceipt）to verify receipt is success or not. But since last month, this interface has started to return an error(21002). I see this document (https://developer.apple.com/documentation/appstorereceipts/verifyreceipt) say its Deprecated. My question is, is the error suddenly returned recently because the interface has been deprecated or for some other reason? (I haven't modified my code about this recently) I can not understand this document: （https://developer.apple.com/documentation/appstorereceipts/validating_receipts_on_the_device） Does this mean that in the new version, as long as the app returns a payment success (purchaseDetails.status == PurchaseStatus.purchased), the payment is guaranteed to be successful, and my server does not need to request payment result verification from Apple's server? I try to use this (https://github.com/apple/app-store-server-library-java) to get TransactionInfo, but I dont konw to get Transaction status to know is success or not. my java server code : AppStoreServerAPIClient client = new AppStoreServerAPIClient(encodedKey, keyId, issuerId, bundleId, environment); TransactionInfoResponse response = client.getTransactionInfo(transactionId); (bug i can note get transaction status, how do i konw this Transaction is success or not)

My app offers auto renewable subscriptions, I have couple of questions regarding how to model the subscriptions at server side, Is originalTransactionId will ever change for a subscription? Will it stay same in case of subscription upgrade/downgrade/crossgrade? If it changes on product change then how do i keep track that the subscription was a continuous subscription and not a new one? Is the webhook payload contains any identifier of which apple account purchase the subscription? I am having issues maintaining sync between the app account's current subscription and the local apple account's subscription, is there any doc regarding this? Will be really helpful

Hello! We are tryign to test refund notifications and we've implemented a debug button trigger the refund of a purchase done with a sandbox account. The problem is that the refund view displays a Cannot Connect message and nothing happens. No error messages appear in the console. Anything we are doing wrong?

Hi folks, How can I check the URL we have configured for SKAdNetwork install postback requests? Sadly we've lost any record of this via email on our end, and Apple developer support have asked that I reach out via the forums.

Could you tell me about the specifications of the winback offer? If a user is eligible for the winback offer, will the winback offer sheet be displayed every time the app is launched? Or will the OS adjust the display frequency in some way?

Cannot retrieve products for iap or subscription on simulator iPhone 16 and real device iPhone XR also. lutter: IAPError(code: storekit2_products_error, source: app_store, message: The operation couldn’t be completed. (NSURLErrorDomain error -1009.), details: The operation couldn’t be completed. (NSURLErrorDomain error -1009.)) flutter: Error fetching IAP products: IAPError(code: storekit2_products_error, source: app_store, message: The operation couldn’t be completed. (NSURLErrorDomain error -1009.), details: The operation couldn’t be completed. (NSURLErrorDomain error -1009.))