StoreKit

RSS for tag

Support in-app purchases and interactions with the App Store using StoreKit.

StoreKit Documentation

Posts under StoreKit subtopic

Post

Replies

Boosts

Views

Activity

Advanced commerce API - dynamic subscriptions
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://developer.apple.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
2
0
250
May ’25
All transaction in my current entitlement returns as .unverified
Im building a small iphone app with StoreKit and currently testing it in testflight right on my mac, not on iphone. StoreKit part almost exactly copied from SKDemo from one of the Apple's WWDC. For some users and for myself Transaction.currentEntitlements always returns .unverified results. I double-checked Apple Connect settings, i checked my internet connection and everything is fine. Is there some pitfalls for testflight on mac? How can I find out what is causing this problem?
1
0
554
May ’25
When subscribing to the change notification in the App Store, it was found that the type of notification received by the server did not match the expected problem.
Description of the Issue We are encountering issues with App Store Server Notifications, where the notification type received does not align with our expectations for subscription changes. Specifically, we receive DID_RENEW notifications in scenarios involving downgrades or intra-tier upgrades, which disrupts our backend subscription management logic and may lead to incorrect user subscription states and billing errors. Below are two reproducible scenarios with associated transaction data. Scenario 1: Downgrade from Premium Yearly (with 7-Day Trial) to Standard Yearly Steps to Reproduce: A user purchases the Premium Yearly subscription with a 7-day free trial (initial transaction ID: 700002116066502). On the day before the trial ends, the user downgrades to the Standard Yearly subscription via the App Store’s subscription management interface. Expected Behavior: We expect to receive a DID_CHANGE_RENEWAL_STATUS or a similar downgrade notification (e.g., DID_CHANGE_RENEWAL_PREF) to indicate the subscription plan has been downgraded, enabling immediate updates to the user’s subscription status. Actual Behavior: Upon downgrade, our server receives a DID_RENEW notification instead of a downgrade-specific notification. This causes our system to incorrectly interpret the action as a renewal of the Premium subscription rather than a downgrade to Standard, with no subsequent downgrade confirmation received. Relevant Transaction Data: New Transaction ID: 700002122810952 Notification Type: DID_RENEW Notification UUID: 26de9b0e-5d61-4893-b679-0bd18ae3d208 Original Transaction ID (Trial): 700002116066502 Scenario 2: Intra-Tier Upgrade from Standard Monthly to Standard Yearly Steps to Reproduce: A user purchases the Standard Monthly subscription. On the day before the monthly subscription expires, the user switches to the Standard Yearly subscription via the App Store’s subscription management interface. Expected Behavior: The original Monthly subscription expires normally, with a DID_EXPIRE notification received. Upon expiration, we expect a DID_RENEW or SUBSCRIBED notification for the new Yearly subscription to confirm its activation, allowing seamless transition of the user’s subscription plan. Actual Behavior: Immediately after the upgrade, our server receives a DID_RENEW notification for the new Yearly plan. No further notifications are received, including no DID_EXPIRE for the original Monthly subscription. This leaves our system unable to confirm the expiration of the Monthly plan, potentially resulting in duplicate active subscriptions in our records. Relevant Transaction Data: Transaction ID: 70002902074491 Notification Type: DID_RENEW Notification UUID: 3d35bc2f-e769-4549-bf50-d84d41b10342 Impact These notification discrepancies disrupt our subscription lifecycle management, potentially causing incorrect user entitlements, over-billing, and a degraded user experience. Requested Assistance Please confirm the correct notification types for these scenarios as per Apple’s documentation (e.g., App Store Server Notifications V2). Provide guidance on handling these edge cases, including any recent changes to notification logic. If this is a backend issue, please investigate the provided transaction IDs and Notification UUIDs. Thank you for your prompt assistance. We look forward to your response to help resolve this issue for our users. 问题描述: 我们在处理 App Store 订阅变更通知时发现,服务器接收到的通知类型与预期不符,具体表现为降级或同级升级场景下错误接收到 DID_RENEW 通知。这影响了我们后端订阅管理的逻辑,可能导致用户订阅状态和计费出现偏差。以下是两个可重现的场景及相关交易数据。 场景 1:高级年费(含 7 天试用)降级至标准年费 重现步骤: 用户购买高级年费订阅并开启 7 天免费试用(初始交易 ID:700002116066502)。 在试用期结束前一天,用户通过 App Store 的订阅管理界面降级至标准年费订阅。 预期行为: 我们预期会收到 DID_CHANGE_RENEWAL_STATUS 或类似的降级通知(如 DID_CHANGE_RENEWAL_PREF),以表明订阅计划已降级,从而允许我们立即更新用户订阅状态。 实际行为: 降级后,服务器立即收到 DID_RENEW 通知,而非降级相关通知。这导致系统误认为高级订阅仍在续订,而非降级为标准订阅,且后续未收到任何降级确认通知。 相关交易数据: 新交易 ID:700002122810952 通知类型:DID_RENEW 通知 UUID:26de9b0e-5d61-4893-b679-0bd18ae3d208 原始交易 ID(试用):700002116066502 场景 2:标准月费订阅升级为标准年费订阅 重现步骤: 用户购买标准月费订阅。 在月费订阅到期前一天,用户通过 App Store 的订阅管理界面切换至标准年费订阅。 预期行为: 原月费订阅正常到期,预期收到 DID_EXPIRE 通知。 月费到期后,预期收到新年费订阅的 DID_RENEW 或 SUBSCRIBED 通知,以确认年费订阅开始,方便我们无缝切换用户订阅计划。 实际行为: 升级后,服务器立即收到新年费订阅的 DID_RENEW 通知。 后续未收到任何通知,包括原月费订阅的 DID_EXPIRE 通知。这导致我们无法确认月费订阅的到期状态,可能在记录中出现重复的活跃订阅。 相关交易数据: 交易 ID:70002902074491 通知类型:DID_RENEW 通知 UUID:3d35bc2f-e769-4549-bf50-d84d41b10342 影响: 这些通知异常干扰了我们的订阅生命周期管理,可能导致用户权益错误、潜在的重复计费以及用户体验下降。 请求协助: 请确认根据 Apple 文档(例如 App Store Server Notifications V2)在上述场景中应返回的正确通知类型。 请提供处理此类边缘场景的指导,包括通知逻辑的任何最新变更。 如果这是后端问题,请调查提供的交易 ID 和通知 UUID。 感谢您的及时协助,期待您的回复以帮助我们为用户解决问题。
1
0
99
Sep ’25
iOS in-app purchasing in Unity app
Hi everyone, I am working on a Unity iOS app. I am adding in-app purchasing in my app. I have added Unity IAP to the Unity project, as well as the code for initialising and purchasing a subscription with the product ID. I have also added my certificates and provisioning profile in Xcode with in-app purchasing capabilities. Also, I have set up an App Store Connect page with a non-renewing subscription with a unique product ID and all required information. The subscription status is ready to submit. I have added a sandbox tester account in it. In unity editor, it is working fine with fake purchase receipt. While testing in an iOS device, apple ID is logged out. But there is an error occurs everytime : IAP not initialized. Also I have uploaded a newer version of app on app store connect, it is in waiting for review status. Is there any step or something I am missing that it is not working in iOS device? Please help
4
0
208
Mar ’25
App store payment screen not showing
Hello I am trying to add payments on my app. I have added all products I need in subscriptions. I also tried by using storekit but from my understanding testing with storekit is nothing to rely on. My app works on Android (with the same product IDs same unction call) iOS is not why is that?
1
0
54
Sep ’25
Sandbox Testing Issue: 'Submit for Review' Button Missing for Subscription IAPSubmit
Hello Developers! I am trying to run a test In-App Purchase (IAP) for a renewable subscription product in the sandbox environment. I have set up everything required for sandbox testing, but it’s unclear whether the subscription product needs to be pre-approved by Apple for testing. If approval is required, I have already added the necessary metadata, but the status still shows "Ready for Submit." Additionally, when I save the page, a "Submit for Review" button briefly appears for a fraction of a second on the subscription page before disappearing. Is this button missing, or is there a known issue with this process? This is my first time running this test, and I would appreciate any pointers or suggestions. Thanks!
1
0
102
Mar ’25
Urgent: Reports of Duplicate Charges via AlipayHK on Apple Pay
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.
1
0
91
May ’25
Cannot use proper sandbox account for internal tester on TestFlight
I cannot test IAP using sandbox account that I logged on from settings, it keeps show my regular Apple ID when I try to test IAP from TestFlight This issue frustrate me and bunch of my colleagues, we cannot manage our subscription when sandbox account is default choosing Apple ID I've seen people complaining about this issue a lot Any help on resolving this issue would be really appreaciated
0
0
70
Mar ’25
不正利用された場合、Apple ID不正利用時とクレジットカード不正利用時で、アプリ側が行う標準的な対応プロセスは変わるのか
アプリに課金を実装しようと思うのですが、もし不正利用された場合、アプリ側は基本的にApp Storeを通じて対応するよう案内するのが一般的と思いますが、Apple ID不正利用時とクレジットカード不正利用時で、アプリ側が行う標準的な対応プロセスは変わるのか教えていただきたいです。 また下記内容は標準的な対応プロセスとして問題ないでしょうか?
 ■Apple ID不正利用時 → ユーザー自身がAppleサポートに連絡し、パスワード変更・二段階認証の設定・不正購入の返金申請などを行うよう案内する。 ■クレジットカード不正利用時 → まずカード会社への連絡を促すが、アプリ内決済に関してはAppleのカスタマーサポート経由で返金や調査手続きを案内する 不正利用されたユーザーへの対応に備えて、アプリ側が考慮すべきことがあれば教えてください。
0
0
119
May ’25
original_transaction_id associated to web_order_line_item_id of auto-renewable subscription changed
Our app offers auto-renewable subscriptions using StoreKit Original API for In-App Purchase and App Store Server Notifications V1. Starting around 2025-03-15, we found some cases where original_transaction_id which was associated to web_order_line_item_id of already purchased subscription had changed in the receipt information of verifyReceipt response or App Store Server Notifications V1. The detailed steps are: Around February 2025, re-purchase from the app the same subscription product which was canceled and expired some time ago, using StoreKit Original API for In-App Purchase Receive the following 2 notifications from App Store Server Notifications V1 almost at the same time INITIAL_BUY DID_CHANGE_RENEWAL_STATUS In both notifications, latest_receipt_info contains the receipt for the re-purchased subscription period with new original_transaction_id and web_order_line_item_id pending_renewal_info contains both new original_transaction_id and original one which was generated at first purchase, and original one has "is_in_billing_retry_period": "1" Starting around 2025-03-15, the following happens When we receive another "DID_CHANGE_RENEWAL_STATUS" notification from App Store Server Notifications V1, original_transaction_id which is associated to web_order_line_item_id of the re-purchased subscription period has changed back to the original one (the one which was generated at first purchase) in latest_receipt_info. When we call verifyReceipt with the receipt obtained from appStoreReceiptURL, the response does not seem to contain new original_transaction_id which was generated at re-purchase We have some questions regarding this original_transaction_id behavior. When a user re-purchase the same subscription product which was canceled and expired some time ago, it seems that new original_transaction_id is generated. Is this an expected behavior? If yes, it seems that, at some point, original_transaction_id which is associated to web_order_line_item_id of the re-purchased subscription changed back to the original original_transaction_id which had been generated at first purchase. Is this an expected behavior? What triggers the original_transaction_id change to the original one? Is it related to some user actions or subscription status change?
3
0
396
Mar ’25
appTransactionID behavior on logout
The appTransactionID was recently introduced and is documented here: https://developer.apple.com/documentation/storekit/apptransaction/apptransactionid From the documentation: "The App Store generates a single, globally unique appTransactionID for each Apple Account that downloads your app and for each family group member for apps that support Family Sharing." This seems like a really useful identifier, so I was wondering about some edge cases of when using it: What happens if a user logs out of his AppStore account and keeps using the app? Is it available when the app is installed from Xcode? is it possible to set it to some value using StoreKit testing? Thanks
0
0
91
May ’25
InApp purchase get stuck in paymentQueue purchasing status.
Some of my users reported they can not completed the purchase . According to the logs and screen captures . Their purchase progress's last status are "purchasing" func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) { .... .... case .purchasing: // 处理正在购买的情况 //print("购买中"); AppDelegate.log.debug("paymentQueue purchasing"); LoadingAlert.shared.setText(text: "购买中".localized()) .... After this ,It neither entered any error branch nor prompted the user to confirm the purchase or enter a password, but simply stopped here. There are no other purchase-related logs, and the program is still running normally. At the same time, other users are able to complete their purchases without any issues. However, there have been 4-5 users recently who reported problems with purchasing. What could be the possible reasons? In my local environment, I repeated the test many times, including using sandbox users from different regions and real Apple IDs, and everything worked fine. // // Payment.swift // RadialMenu // // Created by pat on 2023/6/26. // import Foundation import StoreKit class Payment:NSObject,SKProductsRequestDelegate,SKPaymentTransactionObserver{ func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction]) { for transaction in transactions { AppDelegate.log.debug("paymentQueue transaction product = \(transaction.payment.productIdentifier) state = \(transaction.transactionState)"); //let productID = transaction.payment.productIdentifier switch transaction.transactionState { case .purchased,.restored: if(transaction.transactionState == .purchased){ AppDelegate.log.debug("paymentQueue purchased"); LoadingAlert.shared.setText(text: "已购买".localized()) } if(transaction.transactionState == .restored){ LoadingAlert.shared.setText(text: "已恢复".localized()) AppDelegate.log.debug("paymentQueue restored"); } //} break; case .failed: AppDelegate.log.debug("paymentQueue failed "); if let error = transaction.error as? NSError { // 获取错误代码和描述 let errorCode = error.code let errorDescription = error.localizedDescription AppDelegate.log.debug("paymentQueue Transaction failed with error code: \(errorCode), description: \(errorDescription)") } queue.finishTransaction(transaction) LoadingAlert.shared.hideModal(); // 处理购买失败的情况 // 提供错误信息给用户 //print("购买失败"); alertRetry(); break; case .deferred: AppDelegate.log.debug("paymentQueue deferred"); LoadingAlert.shared.setText(text: "购买延迟".localized()) // 处理交易延迟的情况(仅限家庭共享) break; case .purchasing: // 处理正在购买的情况 //print("购买中"); AppDelegate.log.debug("paymentQueue purchasing"); LoadingAlert.shared.setText(text: "购买中".localized()) break; @unknown default: AppDelegate.log.debug("paymentQueue nknown default\(transaction.transactionState)"); break } } }
1
0
392
Mar ’25
Python App. Sandbox testing IAP Auto Renewal Subscription
I have created a Python app and built it with pyinstaller and codesigned everything. Now I want to Sandbox test it. In my appstore connect account i have created a subscriptions id. I read that if I am logged out from the AppStore and have codesigned my .app file with a Developer Certificate i should be able to run the app on my local mac and when i click on the "Buy" button it should connect to my app store connect setup. I have implemented StoreKit in my app and use a storekit_bridge to combine the .swift code with my python app. However when i run the app. I get this: "25-07-24 21:01:12,557 - FEC - WARNING - StoreKit: fetchProducts returned empty result 2025-07-24 21:01:12,557 - FEC - INFO - StoreKit fetch_products returned: {"products": []} 2025-07-24 21:01:12,557 - FEC - ERROR - StoreKit: Failed to parse product info: No products returned from JSON" And no login screen appears where I should be able to enter my Sandbox email adress and password. Anyone here who has experience with a Python app combined with In App Purchases? Hope someone can help me out with this.
0
0
148
Jul ’25
Payment screen not loading for app subscription
Hi All i have developed an app but when I go to download the paywall appears as it’s subscription only but it shows no prices for the subscription I get an endless swirl. I checked the product id etc and it’s correct but the subcription on my App Store Connect shows as approved. is there another status it needs to reach before it becomes like like ready for sale? https://apps.apple.com/gb/app/gameaware-pro/id6751592563
0
0
124
Sep ’25