I am handling the buy subscription with this function const handleBuySubscription = async (productId) => { 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

I’m reaching out regarding our existing in-app subscription implementation that currently uses App Store Server Notifications version 1 (v1). Our live application has a significant number of active recurring subscriptions that are being managed through the v1 webhook integration. We have now developed a revamped version of our application, which uses the same Apple Developer Account and App Store Connect setup, but in this new app version, we’ve implemented App Store Server Notifications version 2 (v2). Before moving forward with the migration, I would like to clarify the following points to ensure a smooth transition and avoid any disruptions to ongoing subscriptions: Backward Compatibility: Will existing active subscriptions (originally created and managed via v1 notifications) continue to work seamlessly once we switch to v2, or do we need to maintain both v1 and v2 endpoints during the transition? Notification Delivery: If both webhook versions are configured simultaneously, will Apple send notifications to both endpoints, or only the one currently configured in App Store Connect? Migration Strategy: What is Apple’s recommended best practice for migrating from v1 to v2 in a scenario where the live app still has active subscriptions tied to the v1 webhook? Potential Risks or Considerations: Are there any known limitations, delays, or issues that we should prepare for during this migration (for example, differences in payload structure or event types between v1 and v2 that could affect subscription lifecycle management)? I would greatly appreciate your guidance or documentation links that outline the correct migration steps and recommended approach for ensuring continuity of service for all existing subscribers.

Hello, We have been approved for the Advanced commerce API and we are trying to implement dynamically created subscriptions via the SubscriptionCreateRequest. We followed the Sending Advanced Commerce API requests from your app (https://aninterestingwebsite.com/documentation/storekit/sending-advanced-commerce-api-requests-from-your-app) documentation but we are not able to make it work correctly. We created a generic subscription in the Appstore connect, product ID: com.example.subscription Then in the app we load the subscription: try await Product.products(for: ["com.example.subscription"]) We do the JWS serialization on our backend and then we wrap the jwt and convert it to Data in the app as this: let request = """ { "signatureInfo": { "token": "\(result.signedPayload)" } } """ let advancedCommerceRequestData = Data(request.utf8) Lastly, we apply the purchase options on the generic product as this: try await product.purchase( options: [ Product.PurchaseOption.custom( key: "advancedCommerceData", value: advancedCommerceRequestData ) ] ) It doesn't show any error, but on the payment sheet it shows the data from the generic subscription and not the data that was in the SubscriptionCreateRequest. Here is an example of the generated jwt: eyJraWQiOiI4V0tNQjhLWTI0IiwidHlwIjoiSldUIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiI0MDZkYmEyOS04ZjIyLTQ3ZDUtYWI1Mi1kY2M2NTQ5OTE1Y2MiLCJiaWQiOiJjby5oZXJvaGVyby5IZXJvaGVybyIsImlhdCI6MTc0NjQzNTcxNCwiYXVkIjoiYWR2YW5jZWQtY29tbWVyY2UtYXBpIiwibm9uY2UiOiJhMzY2MGIwMS1kMDcyLTRlZDYtYmYyMS01MWU1Y2U5MDRmYTUiLCJyZXF1ZXN0IjoiZXlKdmNHVnlZWFJwYjI0aU9pSkRVa1ZCVkVWZlUxVkNVME5TU1ZCVVNVOU9JaXdpY21WeGRXVnpkRWx1Wm04aU9uc2ljbVZ4ZFdWemRGSmxabVZ5Wlc1alpVbGtJam9pTVdSaVlqZG1ZbVl0WWpFNE55MDBZMlJoTFRrNE16WXRNalUzTTJZeU1UaGpOekZpSW4wc0luTjBiM0psWm5KdmJuUWlPaUpEV2tVaUxDSjJaWEp6YVc5dUlqb2lNU0lzSW1OMWNuSmxibU41SWpvaVExcExJaXdpZEdGNFEyOWtaU0k2SWxNd01qRXRNRGd0TVNJc0ltUmxjMk55YVhCMGIzSnpJanA3SW1ScGMzQnNZWGxPWVcxbElqb2lVM1ZpYzJOeWFYQjBhVzl1SUZCbGRISWc0b0tzSURVaUxDSmtaWE5qY21sd2RHbHZiaUk2SWxOMVluTmpjbWx3ZEdsdmJpQlFaWFJ5SU9LQ3JDQTFJbjBzSW5CbGNtbHZaQ0k2SWxBeFRTSXNJbWwwWlcxeklqcGJleUprYVhOd2JHRjVUbUZ0WlNJNklsTjFZbk5qY21sd2RHbHZiaUJRWlhSeUlPS0NyQ0ExSWl3aVpHVnpZM0pwY0hScGIyNGlPaUpUZFdKelkzSnBjSFJwYjI0Z1VHVjBjaURpZ3F3Z05TSXNJbkJ5YVdObElqb3hOVEF3TUN3aWMydDFJam9pY1dkeGIzUnNlSEY1WVdGaFlsOTRiV3RvWlhWdGFHWjJhbXhtWDBWVlVqQTFJbjFkZlE9PSJ9.kJ0f_q2A11Mn9OBmvX6SRmtW5P--volFTVcq_Gohs3N51ECfZqS3WHOxOZc7aojq_qiUHGFp_evmHP51f3LzSw

SKProductsRequest always returns as USD not local currency for debug environment and even some time it fails. This is only happening for debug or TestFlight build.

Product.SubscriptionInfo.isEligibleForIntroOffer(for: "21340582") In the production environment, I have already used the intro offer for this group, but this method still returns true.

We got Advanced Commerce API and the generic product identifiers approved. When I was try to migrate a sandbox subscription to ACA enabled subscription I hit an error Request payload (Hid some info but the requestReferenceId is the real) { "descriptors": { "description": "Migrated", "displayName": "Migration" }, "items": [ { "sku": "product_1mo_999", "description": "description", "displayName": "Product" } ], "requestInfo": { "requestReferenceId": "3b0b8e67-d8a0-45f4-8f6d-06bffa9a2c08" }, "storefront": "USA", "targetProductId": "com.company.generic.subscription", "taxCode": "C003-00-1" } Response { "errorCode": 5000000, "errorMessage": "An unknown error occurred." }

We’ve recently observed an escalating number of complaints from AlipayHK users regarding duplicate charges when completing transactions via Apple Pay. While no similar issues have been reported by users of other credit card providers integrated with Apple Pay, the problem appears isolated to AlipayHK transactions. Key Details: Multiple users confirm being charged twice for single transactions. Complaints are increasing in frequency, indicating a potential systemic issue. No overlapping reports from non-AlipayHK payment methods at this time. To safeguard customer trust and ensure seamless payment experiences, we kindly request Apple’s support in: Investigating whether the root cause stems from Apple Pay’s transaction handling. Collaborating with AlipayHK (if necessary) to resolve the issue promptly. Providing guidance on interim measures to prevent further duplicate charges. Could Apple confirm if this is a known issue and share a timeline for resolution? We’re eager to assist in any way possible to mitigate impact on users. Thank you for your urgent attention to this matter.

For years I've been using Receigen for receipt verification for the Mac App Store build of my application. However, with the deprecation of exit code 173, I am moving to StoreKit-based verification and have a couple of questions. I have followed the instructions from https://aninterestingwebsite.com/documentation/storekit/apptransaction/shared and have something like this (simplified): Swift: @objc class ValidateReceipt: NSObject { @objc func validate() async -> Bool { do { let verificationResult = try await AppTransaction.shared switch verificationResult { case .verified(_ /*let appTransaction*/): // StoreKit verified that the user purchased this app and // the properties in the AppTransaction instance return true; default: // The app transaction didn't pass StoreKit's verification return false; } } catch { // Handle errors return false; } } } Objective-C: ValidateReceipt *validateReceipt = [[ValidateReceipt alloc] init]; [validateReceipt validateWithCompletionHandler:^(BOOL result) { if (result) { // Successful app purchase validation } else { // App purchase validation failure } }]; Thing is, I always get a valid result, i.e., in ValidReceipt.validate(), the case .verified block always runs. Even when exporting a new release build of my app and running it (without any _MASReceipt). When using exit code 173, an .app without a _MASReceipt would prompt for app store login. Nothing of the sort happens now. Am I misunderstanding the documentation / doing something wrong / missing something obvious?

アプリに課金を実装しようと思うのですが、もし不正利用された場合、アプリ側は基本的にApp Storeを通じて対応するよう案内するのが一般的と思いますが、Apple ID不正利用時とクレジットカード不正利用時で、アプリ側が行う標準的な対応プロセスは変わるのか教えていただきたいです。 また下記内容は標準的な対応プロセスとして問題ないでしょうか？
 ■Apple ID不正利用時 → ユーザー自身がAppleサポートに連絡し、パスワード変更・二段階認証の設定・不正購入の返金申請などを行うよう案内する。 ■クレジットカード不正利用時 → まずカード会社への連絡を促すが、アプリ内決済に関してはAppleのカスタマーサポート経由で返金や調査手続きを案内する 不正利用されたユーザーへの対応に備えて、アプリ側が考慮すべきことがあれば教えてください。

Hi everyone, I’ve been receiving App Store Server Notifications (webhooks) normally for a specific transaction. Everything was working fine — I could use the original_transaction_id to query transaction history, and transaction_id to look up specific transactions. However, starting recently, all API calls for that transaction (both Get Transaction Info and Get Transaction History) now return not found. • The webhooks used to arrive normally for this transaction. • I am sure I’m querying the correct environment (production vs sandbox). • The IDs I’m using are exactly the ones from the last webhook payload. • I haven’t changed my integration code. My questions: 1. Under what conditions does Apple’s API return “not found” for original_transaction_id that previously worked? 2. Can Apple actually purge transaction records (in production)? 3. Could this happen due to refunds, revocations, or other account actions? 4. Is this expected behavior, or should I file a DTS (Technical Support Incident)? Any insight would be appreciated. Thanks in advance!

My server's access to Apple's payment interface (buy. itunes. apple. com/verifiyReceipt) has been unresponsive since the end of March, and I have been searching for a long time without finding any issues. Normally, even if the data is incorrect, there is still a {"status": 21000} response. We are using Alibaba Cloud's virtual servers here. I don't know if Apple has made any adjustments to the interface. If anyone has encountered this problem, please kindly help to answer it. Thank you all.

Hello all, Posting here before I put in a support ticket to see if there are any ideas. The previous beta issues seem to have been resolved, but now we are having intermittent problems with sandbox purchases. We do not know if this will affect real purchases. This is happening on beta 9 in both public and dev channels for us, most often on iPad Pro 4th. gen (Though idk if that is relevant). Sometimes running TestFlight builds on iOS 26 beta 9 devices we will have attempts to make sandbox purchases just go into a black hole. We do not get a "Do you want to buy this" popup, or the credentials screen. It just pauses for a bit in the section of our code that would be akin to: let result = try await product.purchase( options: [.appAccountToken(accountUUID) ] ) Then wait a couple seconds, and then nothing. The game returns to normal flow as if it was a pending purchase, but nothing more ever happens. We have not been able to get a local debug build to do this, so it's hard for us to tell if it is going into the pending bucket, the userCancelled bucket, or the unverified bucket, etc. If we take a device in this state and remove the app and reinstall from TestFlight we will get a credentials popup on the first attempt after install to buy, and after putting in our info we will get the " "You've already purchased this In-App Purchase...", but nothing ever his our listener and we return to the broken state. Has anyone else seen issues like this? P.S. Our StoreKit logic code is currently widely distributed, so if it was reproducible in the live version on iOS 18 we would know about it. Thanks, Chris

We're planning on increasing the price of our ios in-app subscription. We will select the option "Keep the current price for existing subscribers" Reading this https://aninterestingwebsite.com/help/app-store-connect/manage-subscriptions/manage-pricing-for-auto-renewable-subscriptions/, it's not clear if existing subscribers will be notified of the change in pricing (even though that change won't impact them) or not?

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 using the SwiftUI view SubscriptionStoreView (https://aninterestingwebsite.com/documentation/storekit/subscriptionstoreview/) with a subscription group that has 2 subscriptions. I set up a free trial offer in App Store Connect (https://aninterestingwebsite.com/help/app-store-connect/manage-subscriptions/set-up-introductory-offers-for-auto-renewable-subscriptions/). The storekit file in Xcode is synced with the App Store. In debug build, this works and appears correctly, showing the free trial offer: But in release build, the free trial offer is not shown: The code is very simple: SubscriptionStoreView(productIDs: [ "[PRODUCT ID FOR ANNUAL SUBSCRIPTION]", "[PRODUCT ID FOR BIMONTHLY SUBSCRIPTION]" ]) Does anyone have a solution? Thank you. (Xcode 16.3, macOS 15.5, iOS 18.5)

Strange issue with currency display in subscription products Hi everyone, I'm facing a strange issue in my app where I use a subscription-based in-app purchase model. The products I created in App Store Connect are all in "Approved" status. I've tested with both RevenueCat and StoreKit, but the result is the same. Here are the products being loaded: Product loaded: weekly_product_id Display name: Weekly Pro Description: Weekly Pro Subscription Price: ₺229,99 Product loaded: annual_product_id Display name: Annual Pro Description: Annual Pro Subscription Price: ₺1.799,99 Even though I can see the correct prices and currency (Turkish Lira) in the Xcode debug console, on my real device the currency appears as Philippine Peso, as shown in the attached screenshot. Interestingly, in the iOS simulator, it's displayed in USD. I've double-checked and my device's region settings are set to Turkey. Any ideas on what could be causing this? And more importantly, how can I fix it? Thanks in advance!

Hi there, We have an app targeted for children and we want to use the SkAdNetwork to track installs for campaigns. We don't want to track further in-app events (purchase etc.), just the install event. We added the SDK to our Unity app, listed the network identifiers in the plist file, configured the external campaign according to their instructions, but struggle to see any events for several weeks now. We see the following logs in the app: Registering install attribution pingback. Failed to migrate Install Attribution database schema from 17001 => 17400. SkAdNetwork: No pingbacks found while attempting to register/update. Error setting install attribution pingback registered for app: 1509727806, error: Error Domain=ASDErrorDomain code=1208 How can we debug this further? What does the error mean? Thank you very much! (I hope I posted in the correct forum topic. Apologies if not)

Hi everyone, I've been going back and forth with Apple’s review team for over 10 days now, and I'm still unable to get my first In-App Purchase (IAP) working correctly. Here's what’s happening: ✅ The IAP works perfectly when I build and run directly from Xcode. ❌ However, when I test the app via TestFlight, tapping the purchase buttons does nothing—the IAP sheet doesn't appear. Key issue (I think): I believe the IAP hasn't been submitted properly for review. On App Store Connect, I cannot select the IAP under the “In-App Purchases” section of the version submission page. It's grayed out or not listed at all. As a result, Apple keeps rejecting my binary due to the IAP not being included in the review. What I’ve already done: Created the IAP (non-consumable) Set pricing and cleared all errors Checked Bundle ID, Product ID, and entitlements Added In-App Purchase capability to the app target Uploaded the binary via Xcode Waited multiple times for status updates My questions: What’s the correct process to link the IAP to a specific app version if it doesn't show up in the version page? Could this be an issue with App Store Connect metadata or approval timing, or am I missing something in Xcode/build settings? Is there any way to force re-sync the IAP so it appears when submitting the build? Has anyone resolved a similar issue recently? This process has been incredibly frustrating, and the feedback from the review team so far has been very vague. I would really appreciate any detailed insight or steps to ensure the IAP is submitted correctly and works on TestFlight. Thank you in advance!

What is the expected behavior for App Receipts and ASSN v2 notifications when a subscription is set to "Remove from Sale"? I tried to test this in Sandbox, but the "Remove from Sale" setting in App Store Connect doesn't seem to affect the Sandbox environment. For existing subscribers, what happens in the receipt? Does auto_renew_status change to 0 and is expiration_intent populated immediately? Also, which notificationType is sent via ASSN v2?

Hello, I have a question regarding the App Store Server API's getTransactionInfo endpoint. Previously, the official documentation for getTransactionInfo mentioned that: “This endpoint doesn’t support an app transaction. To get information about an app transaction, decode the signed app transaction received from the device.” However, as of June 2025, I can no longer find this sentence in the current documentation (link). Now, the docs state that all in-app purchase transaction IDs are supported (consumable, non-consumable, auto-renewable subscriptions, etc.). But in practice, when I call getTransactionInfo with an AppTransactionId (extracted from a signed App Transaction JWS), I receive this error: apiErrorCode: 4000048 “Invalid request. App transactions aren’t supported by this endpoint.” Is this endpoint supposed to support AppTransactionId now, or is the restriction still in place (but not mentioned in the docs)? Is there any official statement about when this restriction was added/removed? Can you clarify if only in-app purchase transaction IDs (and not AppTransactionIds) are supported for this endpoint, or has the policy changed recently? Any clarification or historical context would be greatly appreciated. Additionally, I would like to know about the behavior of an App Transaction in the event of a refund. If a user receives a refund for the app itself (not an in-app purchase), how can changes to the AppTransaction be detected? Does the App Store Server Notification v2 provide notifications for app-level refunds, or are such events only visible by decoding the latest App Transaction JWS on the device? Is there any way to receive app-level refund information server-side, or must we always rely on the device to provide the updated signed app transaction? Any clarification on this refund flow and notification coverage would also be appreciated. Thank you!