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

Help testing sandbox purchases in Xcode
I am attempting to test non-consumable sandbox purchases, however I am unable to select the "Approve Transaction" option after initiating a purchase. Leaving the transaction in a permanent pending state. I can view the transaction in the transaction manager by navigating to Debug -> Storekit -> Manage Transactions.. but the only available options to select are "Refund Transaction" or "Delete Transaction". What am I missing about Xcode or my environment that is preventing me from testing this purchase flow? Some more information about my set up. I have a .storekit file synced to AppStore Connect with my product Id. There's a StoreKitTestCertificate.cert saved in the project. I've tried running the build on my phone as Debug, Release and ReleaseForRunning all with the same behavior after making a purchase. My phone is logged into a sandbox test user apple account in the developer iOS settings
1
0
221
Sep ’25
Guideline 2.1 - Performance - App Completeness We found that your in-app purchase products exhibited one or more bugs which create a poor user experience. Specifically, we were unable to make purchase. The Start Free Trail button was unresponsive t
I've been stuck with this rejection. Trial button 'greyed out' or non responsive. What they are seeing is my subscriptions not loading into the pay wall. We think its because the subscriptions haven't been reviewed and approved in order for them to populate the pay wall (activating the pay wall so it isn't 'greyed out'. Has anyone had and solved this issue?
0
0
106
Jun ’25
[Bug/Doc Discrepancy] App Store Server API "price" field does not include quantity as documentation states
According to the App Store Server API documentation , https://developer.apple.com/documentation/appstoreserverapi/price the price field "shows the total amount of the transaction for the quantity the customer purchased." However, in actual transaction notifications and responses from App Store Server API, the price field appears to represent the unit price, not the total price. For consumable in-app purchases with quantity > 1, the price field equals the unit price of a single item. The total user payment is only correct after multiplying by the quantity. When quantity > 1, the actual amount paid by the user only matches price × quantity, which contradicts the documentation. Please confirm whether the price field is intended to be: The unit price of a single item (requiring multiplication by quantity), or The total price including all quantities (as currently documented). If the former is correct, please update the documentation to clarify that the value represents the unit price, not the total amount.
0
0
47
Oct ’25
Regarding the pattern of multiple original transaction IDs being linked
In the app we're distributing, we've identified a user where the Get All Subscription Statuses API returns two original transaction IDs in the data response. This user has gone through cancellations and re-subscriptions since their initial purchase. Meanwhile, despite maintaining a continuous subscription, a notification suddenly arrives on the renewal date with original_transaction_id2. +---------------------------+---------------------------+---------------------+ | original_transaction_id | notification_type | subtype | +---------------------------+---------------------------+---------------------+ | original_transaction_id1 | SUBSCRIBED | INITIAL_BUY | ~ Repeated cancellations and re-subscriptions ~ | original_transaction_id1 | SUBSCRIBED | RESUBSCRIBE | | original_transaction_id2 | SUBSCRIBED | INITIAL_BUY | +---------------------------+---------------------------+---------------------+ Although it can be inferred from the interface definition of the API itself that multiple original transaction IDs may be returned, what causes multiple original transaction IDs to be returned? Furthermore, is it possible to reproduce the case where multiple original transaction IDs are returned in the sandbox environment provided by Apple? As for this app, it: Uses subscriptions through in-app purchases. Does not offer upgrades, downgrades, or crossgrades, having only one product. Has never undergone price increases or decreases. Is distributed exclusively in Japan.
0
0
96
Jun ’25
RevenueCat Error: None of the products registered in the RevenueCat dashboard could be fetched from App Store Connect
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.
1
0
252
Dec ’25
Verification failed with status INVALID_CHAIN_LENGTH
我正在通过集成app-store-server-library-java来实现 iap服务端校验。我参照了官网提供的Verification Usage 的代码,运行的时候异常信息如下: at com.apple.itunes.storekit.verification.ChainVerifier.verifyChainWithoutCaching(ChainVerifier.java:98) at com.apple.itunes.storekit.verification.ChainVerifier.verifyChain(ChainVerifier.java:71) at com.apple.itunes.storekit.verification.SignedDataVerifier.decodeSignedObject(SignedDataVerifier.java:186) at com.apple.itunes.storekit.verification.SignedDataVerifier.verifyAndDecodeTransaction(SignedDataVerifier.java:72) 我的代码如下: import com.apple.itunes.storekit.model.ResponseBodyV2DecodedPayload; import com.apple.itunes.storekit.verification.SignedDataVerifier; import com.apple.itunes.storekit.verification.VerificationException; import com.auth0.jwt.JWT; import com.auth0.jwt.interfaces.DecodedJWT; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.InputStream; import java.util.Base64; import java.util.Set; public class ExampleVerification { public static void main(String[] args) throws FileNotFoundException { String bundleId = "com.example"; Environment environment = Environment.SANDBOX; Set<InputStream> rootCAs = Set.of( new FileInputStream("AppleRootCA-G3.cer"), new FileInputStream("AppleRootCA-G2.cer") ); Long appAppleId = null; // appAppleId must be provided for the Production environment SignedDataVerifier signedPayloadVerifier = new SignedDataVerifier(rootCAs, bundleId, appAppleId, environment, true); String appTransactionJWS = "eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkFwcGxlX1hjb2RlX0tleSIsIng1YyI6WyJNSUlCeXpDQ0FYR2dBd0lCQWdJQkFUQUtCZ2dxaGtqT1BRUURBakJJTVNJd0lBWURWUVFERXhsVGRHOXlaVXRwZENCVVpYTjBhVzVuSUdsdUlGaGpiMlJsTVNJd0lBWURWUVFLRXhsVGRHOXlaVXRwZENCVVpYTjBhVzVuSUdsdUlGaGpiMlJsTUI0WERUSTFNRFl3TXpFeE1UQXdNRm9YRFRJMk1EWXdNekV4TVRBd01Gb3dTREVpTUNBR0ExVUVBeE1aVTNSdmNtVkxhWFFnVkdWemRHbHVaeUJwYmlCWVkyOWtaVEVpTUNBR0ExVUVDaE1aVTNSdmNtVkxhWFFnVkdWemRHbHVaeUJwYmlCWVkyOWtaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCTnZZZ3o1MW1CbEMweE5McW9rMUJCcithRWJEb1ZEeVkyaVRsejZsK1JjYVR4QStVY2ptMjBESTNncFFlM280a2doRGxSbGowdEo1enBGUHgyQWR2VCtqVERCS01CSUdBMVVkRXdFQlwvd1FJTUFZQkFmOENBUUF3SkFZRFZSMFJCQjB3RzRFWlUzUnZjbVZMYVhRZ1ZHVnpkR2x1WnlCcGJpQllZMjlrWlRBT0JnTlZIUThCQWY4RUJBTUNCNEF3Q2dZSUtvWkl6ajBFQXdJRFNBQXdSUUloQU40bUJWTHBoZkpjYjdweHF2b09XcjkyK1czYU5LRG9pazV5Vk9BT0NEVmxBaUFYWVF0czJubWZGMStGYzlSODJHXC96QWhaVU00aDNTXC9VdFE4Q1lPS2p3ZlE9PSJdfQ.eyJhcHBsaWNhdGlvblZlcnNpb24iOiIxIiwib3JpZ2luYWxQdXJjaGFzZURhdGUiOjAsImJ1bmRsZUlkIjoiYnJpZ2h0LnVuaWhhbmQuY24iLCJhcHBUcmFuc2FjdGlvbklkIjoiMCIsImRldmljZVZlcmlmaWNhdGlvbiI6IlRYdGRvMWZtNDhQVDdXUUh5cHU4K2l3TW55YmNoTTNNeG5XUnhOR1JqSFhQQnVqMXdUaldcL05zN3JtUmJlQTd3IiwicmVjZWlwdFR5cGUiOiJYY29kZSIsIm9yaWdpbmFsQXBwbGljYXRpb25WZXJzaW9uIjoiMSIsInJlcXVlc3REYXRlIjoxNzYxMDM1OTMzNTE3LCJvcmlnaW5hbFBsYXRmb3JtIjoiaU9TIiwicmVjZWlwdENyZWF0aW9uRGF0ZSI6MTc2MTAzNTkzMzUxNywiZGV2aWNlVmVyaWZpY2F0aW9uTm9uY2UiOiI1ZDhmNzM5Mi01N2YwLTQyM2YtOTMzNy1hZDQ0YTk5MDM4Y2EifQ.2ZO5xsx-yywP4IyaDz4KQ3mq181ZGwlX2uANSm-kHq50KIdMMUDveMsCrcZmHdzLH2rpfPsXKaIMdM25Hdcuuw"; DecodedJWT unverifiedJWT = JWT.decode(appTransactionJWS); String header = unverifiedJWT.getHeader(); System.out.println(new String(Base64.getDecoder().decode(header))); try { signedPayloadVerifier.verifyAndDecodeTransaction(appTransactionJWS); } catch (VerificationException e) { e.printStackTrace(); } } } 查看了ChainVerifier.java 源代码,发现 private static final int EXPECTED_CHAIN_LENGTH = 3; // <--- 关键常量 // ... PublicKey verifyChainWithoutCaching(String[] certificates, boolean performRevocationChecking, Date effectiveDate) throws VerificationException { // ... 解析证书代码 ... if (parsedCertificates.size() != EXPECTED_CHAIN_LENGTH) { throw new VerificationException(VerificationStatus.INVALID_CHAIN_LENGTH); // <--- 抛出异常点 } // ... 后续验证代码 ... } appTransactionJWS是来自客户端的沙盒环境。 我发现沙盒环境的jws总是包含一个证书,而后端验证又必须要求三个证书,请问这个问题如何解决。
0
0
96
Oct ’25
Guideline 2.1 - Performance - App Completeness
Apple review says , my app displayed an error when we attempted to purchase subscriptions. Please review the details and resources below and complete the next steps. Device type: iPad Air (5th generation) OS version: iPadOS 26.0.1 Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code "Sandbox receipt used in production," you should validate against the test environment instead. Question: Is it due to Device being used by reviewer or is it really from my code. As my code relies on Apple infrastructure for purchases and all things. Initially i did had subscription reporting api for receipt handling and all.When i went through with ChatGPT it did say that issue is due to half baked subscription module on my server. So i decided not to send any Subscription related things to backend, now it's Apple only and on App side. Is it correct fix ? Or do i need to fix backend even though i have no use for it ? My team did test in sandbox env via internal testing that time we had no issues. And all was tested using Mobile devices, that's why i still have question just to be sure these errors are due to devices or not? Screenshot shared by Apple team did show they got a error popup saying Something went wrong : Unable to complete request. I am trying to reproduce in development but can't. Anyone had got same issue before and has information on how to resolve and test for it will be helpful. Thanks Shikhar Sahu
0
0
97
Oct ’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.
5
0
268
May ’25
How to switch in-app-purchases from sandbox to production?
Hello all, I am new to implementing payments in an app, and thus completely at sea here. I have created a small app that I have set a one-time (non-consumable) payment for a premium version. In the Xcode simulator (on all platforms) and on any physical test devices I have tried, the payment works as expected. I have a sandbox account and various test accounts, both dummy and actual real accounts (friends and family). Everywhere everything works perfectly fine. Yet, when I submit for review I get a rejection with this contents: We found that your in-app purchase products exhibited one or more bugs which create a poor user experience. Specifically, the app still failed to load the in-app purchase. Please review the details and resources below and complete the next steps. Review device details: Device type: iPad Air (5th generation) OS version: iPadOS 18.6 Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code "Sandbox receipt used in production," you should validate against the test environment instead. Additionally, note that the Account Holder must accept the Paid Apps Agreement in the Business section of App Store Connect before paid in-app purchases will function. Resources Learn how to set up and test in-app purchase products in >the sandbox environment. Learn more about validating receipts with the App Store. Steps I have done: I have signed all agreements and all bank account details are in order. Everything in the In-app-purchases section of the AppStoreConnect in an Active state. I have triple checked that the configuration of the in-app purchases is correct (product IDs, amounts, etc.) I have created test accounts and tested in sandbox What I don't understand from the reviewer's response is what receipts validation are they talking about? I have no payment servers (the whole concept of using Apple's in-app-purchases service is to not have to deal with my own payment implementation). The StoreKit documentation specifically reads: For each transaction that represents a current purchase, your app delivers the purchased products. To validate purchases, you can verify transactions on your server, or rely on StoreKit’s verification. So now I am confused. The reviewer's response is so vague, and so completely deprived of details that I have no idea what to do... Does the problem concern the product purchase trigger and the that in production environment it does not trigger? Is it that I haven't implemented a receipt validation? Do I need to? Although the documentation mentions that it can be done by StoreKit, I couldn't find anything concerning how to do it :( Can someone give me a hand please? Cheers, Alex
3
0
503
Oct ’25
Inconsistent appTransactionId in Transaction History
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.
1
0
189
Jul ’25
Auto-renewable subscriptions not loading in React Native app after App Store approval when testing via Xcode
Hello, I’m facing an issue with auto-renewable subscriptions in my React Native iOS app using react-native-iap. Before App Store approval, everything worked perfectly — I could test in-app purchases and subscriptions locally on my iPhone through Xcode using a development build and sandbox tester. After the app was approved and released on the App Store, I needed to make some updates. Now, when I build and run the same project again through Xcode (Debug, development-signed) on my iPhone, the subscriptions no longer load. The same product IDs are approved and live in App Store Connect. The live version on the App Store works fine (subscriptions load and process successfully). But on the local Xcode build, getSubscriptions() returns invalid product identifiers or an empty list. No changes were made to the bundle ID or product IDs The build is signed with an Apple Development certificate and uses the same team and bundle identifier as the published app. “In-App Purchase” capability is enabled. I’ve also tried deleting the app, rebooting the device, and re-logging into a sandbox tester account, but the issue persists. It looks like the sandbox environment no longer works for the app after its first App Store release. Has anyone experienced this issue where the same approved app’s IAPs work in production but fail to load in sandbox/dev builds through Xcode after release? Any guidance on re-enabling sandbox testing for updates would be greatly appreciated. Environment: Xcode 26.0.1 React Native with react-native-iap Auto-renewable subscriptions (3 SKUs) Thank you!
0
0
113
Oct ’25
StoreKit beginRefundRequest issue
I'm developing storekitV2, my app is providing the way to refund some product, and I use method below. func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus however when i call the method, the modal view presented but the view shows error with message 'cannot connect'. when I select retry button, something done with indicator and get same result. how can I solve this problem?
3
0
494
May ’25
Is the following subscription cancellation flow possible for an iOS in-app subscription?
Is the following subscription cancellation flow possible for an iOS in-app subscription? (Note: This is during the feature planning stage, not actual app deployment.) Planned user flow: User taps the “Cancel Subscription” button Display a “Wait a moment!” screen showing how much the user has enjoyed BFLIX content (to encourage retention) User taps “Proceed to Cancel” Collect cancellation reason from the user Redirect the user to the Apple subscription management page to complete cancellation Can this flow be implemented under Apple’s current in-app purchase and App Store Review guidelines?
0
0
35
Nov ’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
113
Sep ’25
unable to cancel test subscriptions
I tested a subscription with my developer account, it never charges but at the same time I can't cancel it anymore. It does not appear in the list of my official purchsed subscriptions. I tried to login to the sandbox with my developer account, but then when I click on "Manage" I just keep getting the error "Can't connect - retry". I have already tried to logout from all the services, App store, etc. and re-login, nothing worked. Is there anything I can do? Thanks in advance to anyone who can give any tips.
0
0
101
Sep ’25
Best practice to prevent users from switching between subscriptions in the same group?
Hello everyone, For example, our app currently has one subscription group in App Store Connect with 5 plans (2 annual, 2 monthly, and 1 quarterly). By default, users can go into Apple Subscriptions in Settings and freely switch between all of these plans. However, our business requirement is to only allow users to stay on one annual plan and one quarterly plan. We don’t want them to switch to the other plans. My questions are: Is there any best practice or recommended approach to restrict subscription switching within the same group? Would removing the unwanted products from sale be the correct approach, or are there any risks/downsides with this method? Has anyone faced a similar situation and found a practical solution? Any guidance or shared experience would be greatly appreciated. Thanks!
4
0
169
Sep ’25
Delete Offer Codes
Regarding the offer codes in https://developer.apple.com/help/app-store-connect/manage-subscriptions/set-up-offer-codes, I set up some incorrect offer codes by mistake. Currently, I can only deactivate it but I can't delete it. Is it possible to let me delete the incorrect offer codes due to the below reasons? Thank you. I can't recreate the offer code due to error message This reference name is or has been used by another offer in this subscription group. When I use the offer code redemption view in https://developer.apple.com/documentation/SwiftUI/View/offerCodeRedemption(isPresented:onCompletion:), it shows all the deactivated offer codes. I don't want them to be displayed in the page.
0
0
80
Sep ’25
In iOS 26 beta3 version, the finishTransaction method is unable to remove transactions from the SKPaymentQueue, causing transactions to remain in the queue even after being processed.
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.
4
0
357
Jul ’25
How to make StoreKit config & App Store Server notifications work together?
Hi, Using StoreKit 2 with App Store Server notifications like so: User selects a purchase App calls Product.purchase() If successful, App Store notifies our backend with the transaction details, importantly with a UUID for the transaction ID. This works fine, but when I try to test contingent pricing via the handy StoreKit config Transaction Manager in Xcode by creating a PurchaseIntent if I then complete the purchase in the app the Transaction ID is sequential, (0 for the first, 1 for the second etc), which doesn't work for us as the backend might already have that ID stored so the purchase never completes. If I disable the config file it works fine, but then I can't use the Transaction Manager debug tool. Is there a way to override the ID of a custom transaction that's created via the StoreKit configuration? Thanks
0
0
81
Jun ’25
How to check if user still have valid subscription?
Is there an API Endpoint that I can call to check if user still have valid subscription? I want to be sure that his subscription renewal was succesful (ie: I dont want to give him another month/year/.. if his latest renewal wasnt successful) Would GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId} be the correct API endpoint to call? But I wonder, after subscription auto-renews, do we still use the same transactionId to check whether his subs is still valid?
0
0
58
Jul ’25
Help testing sandbox purchases in Xcode
I am attempting to test non-consumable sandbox purchases, however I am unable to select the "Approve Transaction" option after initiating a purchase. Leaving the transaction in a permanent pending state. I can view the transaction in the transaction manager by navigating to Debug -> Storekit -> Manage Transactions.. but the only available options to select are "Refund Transaction" or "Delete Transaction". What am I missing about Xcode or my environment that is preventing me from testing this purchase flow? Some more information about my set up. I have a .storekit file synced to AppStore Connect with my product Id. There's a StoreKitTestCertificate.cert saved in the project. I've tried running the build on my phone as Debug, Release and ReleaseForRunning all with the same behavior after making a purchase. My phone is logged into a sandbox test user apple account in the developer iOS settings
Replies
1
Boosts
0
Views
221
Activity
Sep ’25
Guideline 2.1 - Performance - App Completeness We found that your in-app purchase products exhibited one or more bugs which create a poor user experience. Specifically, we were unable to make purchase. The Start Free Trail button was unresponsive t
I've been stuck with this rejection. Trial button 'greyed out' or non responsive. What they are seeing is my subscriptions not loading into the pay wall. We think its because the subscriptions haven't been reviewed and approved in order for them to populate the pay wall (activating the pay wall so it isn't 'greyed out'. Has anyone had and solved this issue?
Replies
0
Boosts
0
Views
106
Activity
Jun ’25
[Bug/Doc Discrepancy] App Store Server API "price" field does not include quantity as documentation states
According to the App Store Server API documentation , https://developer.apple.com/documentation/appstoreserverapi/price the price field "shows the total amount of the transaction for the quantity the customer purchased." However, in actual transaction notifications and responses from App Store Server API, the price field appears to represent the unit price, not the total price. For consumable in-app purchases with quantity > 1, the price field equals the unit price of a single item. The total user payment is only correct after multiplying by the quantity. When quantity > 1, the actual amount paid by the user only matches price × quantity, which contradicts the documentation. Please confirm whether the price field is intended to be: The unit price of a single item (requiring multiplication by quantity), or The total price including all quantities (as currently documented). If the former is correct, please update the documentation to clarify that the value represents the unit price, not the total amount.
Replies
0
Boosts
0
Views
47
Activity
Oct ’25
Regarding the pattern of multiple original transaction IDs being linked
In the app we're distributing, we've identified a user where the Get All Subscription Statuses API returns two original transaction IDs in the data response. This user has gone through cancellations and re-subscriptions since their initial purchase. Meanwhile, despite maintaining a continuous subscription, a notification suddenly arrives on the renewal date with original_transaction_id2. +---------------------------+---------------------------+---------------------+ | original_transaction_id | notification_type | subtype | +---------------------------+---------------------------+---------------------+ | original_transaction_id1 | SUBSCRIBED | INITIAL_BUY | ~ Repeated cancellations and re-subscriptions ~ | original_transaction_id1 | SUBSCRIBED | RESUBSCRIBE | | original_transaction_id2 | SUBSCRIBED | INITIAL_BUY | +---------------------------+---------------------------+---------------------+ Although it can be inferred from the interface definition of the API itself that multiple original transaction IDs may be returned, what causes multiple original transaction IDs to be returned? Furthermore, is it possible to reproduce the case where multiple original transaction IDs are returned in the sandbox environment provided by Apple? As for this app, it: Uses subscriptions through in-app purchases. Does not offer upgrades, downgrades, or crossgrades, having only one product. Has never undergone price increases or decreases. Is distributed exclusively in Japan.
Replies
0
Boosts
0
Views
96
Activity
Jun ’25
RevenueCat Error: None of the products registered in the RevenueCat dashboard could be fetched from App Store Connect
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.
Replies
1
Boosts
0
Views
252
Activity
Dec ’25
Verification failed with status INVALID_CHAIN_LENGTH
我正在通过集成app-store-server-library-java来实现 iap服务端校验。我参照了官网提供的Verification Usage 的代码,运行的时候异常信息如下: at com.apple.itunes.storekit.verification.ChainVerifier.verifyChainWithoutCaching(ChainVerifier.java:98) at com.apple.itunes.storekit.verification.ChainVerifier.verifyChain(ChainVerifier.java:71) at com.apple.itunes.storekit.verification.SignedDataVerifier.decodeSignedObject(SignedDataVerifier.java:186) at com.apple.itunes.storekit.verification.SignedDataVerifier.verifyAndDecodeTransaction(SignedDataVerifier.java:72) 我的代码如下: import com.apple.itunes.storekit.model.ResponseBodyV2DecodedPayload; import com.apple.itunes.storekit.verification.SignedDataVerifier; import com.apple.itunes.storekit.verification.VerificationException; import com.auth0.jwt.JWT; import com.auth0.jwt.interfaces.DecodedJWT; import java.io.FileInputStream; import java.io.FileNotFoundException; import java.io.InputStream; import java.util.Base64; import java.util.Set; public class ExampleVerification { public static void main(String[] args) throws FileNotFoundException { String bundleId = "com.example"; Environment environment = Environment.SANDBOX; Set<InputStream> rootCAs = Set.of( new FileInputStream("AppleRootCA-G3.cer"), new FileInputStream("AppleRootCA-G2.cer") ); Long appAppleId = null; // appAppleId must be provided for the Production environment SignedDataVerifier signedPayloadVerifier = new SignedDataVerifier(rootCAs, bundleId, appAppleId, environment, true); String appTransactionJWS = "eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkFwcGxlX1hjb2RlX0tleSIsIng1YyI6WyJNSUlCeXpDQ0FYR2dBd0lCQWdJQkFUQUtCZ2dxaGtqT1BRUURBakJJTVNJd0lBWURWUVFERXhsVGRHOXlaVXRwZENCVVpYTjBhVzVuSUdsdUlGaGpiMlJsTVNJd0lBWURWUVFLRXhsVGRHOXlaVXRwZENCVVpYTjBhVzVuSUdsdUlGaGpiMlJsTUI0WERUSTFNRFl3TXpFeE1UQXdNRm9YRFRJMk1EWXdNekV4TVRBd01Gb3dTREVpTUNBR0ExVUVBeE1aVTNSdmNtVkxhWFFnVkdWemRHbHVaeUJwYmlCWVkyOWtaVEVpTUNBR0ExVUVDaE1aVTNSdmNtVkxhWFFnVkdWemRHbHVaeUJwYmlCWVkyOWtaVEJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFCTnZZZ3o1MW1CbEMweE5McW9rMUJCcithRWJEb1ZEeVkyaVRsejZsK1JjYVR4QStVY2ptMjBESTNncFFlM280a2doRGxSbGowdEo1enBGUHgyQWR2VCtqVERCS01CSUdBMVVkRXdFQlwvd1FJTUFZQkFmOENBUUF3SkFZRFZSMFJCQjB3RzRFWlUzUnZjbVZMYVhRZ1ZHVnpkR2x1WnlCcGJpQllZMjlrWlRBT0JnTlZIUThCQWY4RUJBTUNCNEF3Q2dZSUtvWkl6ajBFQXdJRFNBQXdSUUloQU40bUJWTHBoZkpjYjdweHF2b09XcjkyK1czYU5LRG9pazV5Vk9BT0NEVmxBaUFYWVF0czJubWZGMStGYzlSODJHXC96QWhaVU00aDNTXC9VdFE4Q1lPS2p3ZlE9PSJdfQ.eyJhcHBsaWNhdGlvblZlcnNpb24iOiIxIiwib3JpZ2luYWxQdXJjaGFzZURhdGUiOjAsImJ1bmRsZUlkIjoiYnJpZ2h0LnVuaWhhbmQuY24iLCJhcHBUcmFuc2FjdGlvbklkIjoiMCIsImRldmljZVZlcmlmaWNhdGlvbiI6IlRYdGRvMWZtNDhQVDdXUUh5cHU4K2l3TW55YmNoTTNNeG5XUnhOR1JqSFhQQnVqMXdUaldcL05zN3JtUmJlQTd3IiwicmVjZWlwdFR5cGUiOiJYY29kZSIsIm9yaWdpbmFsQXBwbGljYXRpb25WZXJzaW9uIjoiMSIsInJlcXVlc3REYXRlIjoxNzYxMDM1OTMzNTE3LCJvcmlnaW5hbFBsYXRmb3JtIjoiaU9TIiwicmVjZWlwdENyZWF0aW9uRGF0ZSI6MTc2MTAzNTkzMzUxNywiZGV2aWNlVmVyaWZpY2F0aW9uTm9uY2UiOiI1ZDhmNzM5Mi01N2YwLTQyM2YtOTMzNy1hZDQ0YTk5MDM4Y2EifQ.2ZO5xsx-yywP4IyaDz4KQ3mq181ZGwlX2uANSm-kHq50KIdMMUDveMsCrcZmHdzLH2rpfPsXKaIMdM25Hdcuuw"; DecodedJWT unverifiedJWT = JWT.decode(appTransactionJWS); String header = unverifiedJWT.getHeader(); System.out.println(new String(Base64.getDecoder().decode(header))); try { signedPayloadVerifier.verifyAndDecodeTransaction(appTransactionJWS); } catch (VerificationException e) { e.printStackTrace(); } } } 查看了ChainVerifier.java 源代码,发现 private static final int EXPECTED_CHAIN_LENGTH = 3; // <--- 关键常量 // ... PublicKey verifyChainWithoutCaching(String[] certificates, boolean performRevocationChecking, Date effectiveDate) throws VerificationException { // ... 解析证书代码 ... if (parsedCertificates.size() != EXPECTED_CHAIN_LENGTH) { throw new VerificationException(VerificationStatus.INVALID_CHAIN_LENGTH); // <--- 抛出异常点 } // ... 后续验证代码 ... } appTransactionJWS是来自客户端的沙盒环境。 我发现沙盒环境的jws总是包含一个证书,而后端验证又必须要求三个证书,请问这个问题如何解决。
Replies
0
Boosts
0
Views
96
Activity
Oct ’25
Guideline 2.1 - Performance - App Completeness
Apple review says , my app displayed an error when we attempted to purchase subscriptions. Please review the details and resources below and complete the next steps. Device type: iPad Air (5th generation) OS version: iPadOS 26.0.1 Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code "Sandbox receipt used in production," you should validate against the test environment instead. Question: Is it due to Device being used by reviewer or is it really from my code. As my code relies on Apple infrastructure for purchases and all things. Initially i did had subscription reporting api for receipt handling and all.When i went through with ChatGPT it did say that issue is due to half baked subscription module on my server. So i decided not to send any Subscription related things to backend, now it's Apple only and on App side. Is it correct fix ? Or do i need to fix backend even though i have no use for it ? My team did test in sandbox env via internal testing that time we had no issues. And all was tested using Mobile devices, that's why i still have question just to be sure these errors are due to devices or not? Screenshot shared by Apple team did show they got a error popup saying Something went wrong : Unable to complete request. I am trying to reproduce in development but can't. Anyone had got same issue before and has information on how to resolve and test for it will be helpful. Thanks Shikhar Sahu
Replies
0
Boosts
0
Views
97
Activity
Oct ’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.
Replies
5
Boosts
0
Views
268
Activity
May ’25
How to switch in-app-purchases from sandbox to production?
Hello all, I am new to implementing payments in an app, and thus completely at sea here. I have created a small app that I have set a one-time (non-consumable) payment for a premium version. In the Xcode simulator (on all platforms) and on any physical test devices I have tried, the payment works as expected. I have a sandbox account and various test accounts, both dummy and actual real accounts (friends and family). Everywhere everything works perfectly fine. Yet, when I submit for review I get a rejection with this contents: We found that your in-app purchase products exhibited one or more bugs which create a poor user experience. Specifically, the app still failed to load the in-app purchase. Please review the details and resources below and complete the next steps. Review device details: Device type: iPad Air (5th generation) OS version: iPadOS 18.6 Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code "Sandbox receipt used in production," you should validate against the test environment instead. Additionally, note that the Account Holder must accept the Paid Apps Agreement in the Business section of App Store Connect before paid in-app purchases will function. Resources Learn how to set up and test in-app purchase products in >the sandbox environment. Learn more about validating receipts with the App Store. Steps I have done: I have signed all agreements and all bank account details are in order. Everything in the In-app-purchases section of the AppStoreConnect in an Active state. I have triple checked that the configuration of the in-app purchases is correct (product IDs, amounts, etc.) I have created test accounts and tested in sandbox What I don't understand from the reviewer's response is what receipts validation are they talking about? I have no payment servers (the whole concept of using Apple's in-app-purchases service is to not have to deal with my own payment implementation). The StoreKit documentation specifically reads: For each transaction that represents a current purchase, your app delivers the purchased products. To validate purchases, you can verify transactions on your server, or rely on StoreKit’s verification. So now I am confused. The reviewer's response is so vague, and so completely deprived of details that I have no idea what to do... Does the problem concern the product purchase trigger and the that in production environment it does not trigger? Is it that I haven't implemented a receipt validation? Do I need to? Although the documentation mentions that it can be done by StoreKit, I couldn't find anything concerning how to do it :( Can someone give me a hand please? Cheers, Alex
Replies
3
Boosts
0
Views
503
Activity
Oct ’25
Inconsistent appTransactionId in Transaction History
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.
Replies
1
Boosts
0
Views
189
Activity
Jul ’25
Auto-renewable subscriptions not loading in React Native app after App Store approval when testing via Xcode
Hello, I’m facing an issue with auto-renewable subscriptions in my React Native iOS app using react-native-iap. Before App Store approval, everything worked perfectly — I could test in-app purchases and subscriptions locally on my iPhone through Xcode using a development build and sandbox tester. After the app was approved and released on the App Store, I needed to make some updates. Now, when I build and run the same project again through Xcode (Debug, development-signed) on my iPhone, the subscriptions no longer load. The same product IDs are approved and live in App Store Connect. The live version on the App Store works fine (subscriptions load and process successfully). But on the local Xcode build, getSubscriptions() returns invalid product identifiers or an empty list. No changes were made to the bundle ID or product IDs The build is signed with an Apple Development certificate and uses the same team and bundle identifier as the published app. “In-App Purchase” capability is enabled. I’ve also tried deleting the app, rebooting the device, and re-logging into a sandbox tester account, but the issue persists. It looks like the sandbox environment no longer works for the app after its first App Store release. Has anyone experienced this issue where the same approved app’s IAPs work in production but fail to load in sandbox/dev builds through Xcode after release? Any guidance on re-enabling sandbox testing for updates would be greatly appreciated. Environment: Xcode 26.0.1 React Native with react-native-iap Auto-renewable subscriptions (3 SKUs) Thank you!
Replies
0
Boosts
0
Views
113
Activity
Oct ’25
StoreKit beginRefundRequest issue
I'm developing storekitV2, my app is providing the way to refund some product, and I use method below. func beginRefundRequest(in scene: UIWindowScene) async throws -> Transaction.RefundRequestStatus however when i call the method, the modal view presented but the view shows error with message 'cannot connect'. when I select retry button, something done with indicator and get same result. how can I solve this problem?
Replies
3
Boosts
0
Views
494
Activity
May ’25
Is the following subscription cancellation flow possible for an iOS in-app subscription?
Is the following subscription cancellation flow possible for an iOS in-app subscription? (Note: This is during the feature planning stage, not actual app deployment.) Planned user flow: User taps the “Cancel Subscription” button Display a “Wait a moment!” screen showing how much the user has enjoyed BFLIX content (to encourage retention) User taps “Proceed to Cancel” Collect cancellation reason from the user Redirect the user to the Apple subscription management page to complete cancellation Can this flow be implemented under Apple’s current in-app purchase and App Store Review guidelines?
Replies
0
Boosts
0
Views
35
Activity
Nov ’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。 感谢您的及时协助,期待您的回复以帮助我们为用户解决问题。
Replies
1
Boosts
0
Views
113
Activity
Sep ’25
unable to cancel test subscriptions
I tested a subscription with my developer account, it never charges but at the same time I can't cancel it anymore. It does not appear in the list of my official purchsed subscriptions. I tried to login to the sandbox with my developer account, but then when I click on "Manage" I just keep getting the error "Can't connect - retry". I have already tried to logout from all the services, App store, etc. and re-login, nothing worked. Is there anything I can do? Thanks in advance to anyone who can give any tips.
Replies
0
Boosts
0
Views
101
Activity
Sep ’25
Best practice to prevent users from switching between subscriptions in the same group?
Hello everyone, For example, our app currently has one subscription group in App Store Connect with 5 plans (2 annual, 2 monthly, and 1 quarterly). By default, users can go into Apple Subscriptions in Settings and freely switch between all of these plans. However, our business requirement is to only allow users to stay on one annual plan and one quarterly plan. We don’t want them to switch to the other plans. My questions are: Is there any best practice or recommended approach to restrict subscription switching within the same group? Would removing the unwanted products from sale be the correct approach, or are there any risks/downsides with this method? Has anyone faced a similar situation and found a practical solution? Any guidance or shared experience would be greatly appreciated. Thanks!
Replies
4
Boosts
0
Views
169
Activity
Sep ’25
Delete Offer Codes
Regarding the offer codes in https://developer.apple.com/help/app-store-connect/manage-subscriptions/set-up-offer-codes, I set up some incorrect offer codes by mistake. Currently, I can only deactivate it but I can't delete it. Is it possible to let me delete the incorrect offer codes due to the below reasons? Thank you. I can't recreate the offer code due to error message This reference name is or has been used by another offer in this subscription group. When I use the offer code redemption view in https://developer.apple.com/documentation/SwiftUI/View/offerCodeRedemption(isPresented:onCompletion:), it shows all the deactivated offer codes. I don't want them to be displayed in the page.
Replies
0
Boosts
0
Views
80
Activity
Sep ’25
In iOS 26 beta3 version, the finishTransaction method is unable to remove transactions from the SKPaymentQueue, causing transactions to remain in the queue even after being processed.
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.
Replies
4
Boosts
0
Views
357
Activity
Jul ’25
How to make StoreKit config & App Store Server notifications work together?
Hi, Using StoreKit 2 with App Store Server notifications like so: User selects a purchase App calls Product.purchase() If successful, App Store notifies our backend with the transaction details, importantly with a UUID for the transaction ID. This works fine, but when I try to test contingent pricing via the handy StoreKit config Transaction Manager in Xcode by creating a PurchaseIntent if I then complete the purchase in the app the Transaction ID is sequential, (0 for the first, 1 for the second etc), which doesn't work for us as the backend might already have that ID stored so the purchase never completes. If I disable the config file it works fine, but then I can't use the Transaction Manager debug tool. Is there a way to override the ID of a custom transaction that's created via the StoreKit configuration? Thanks
Replies
0
Boosts
0
Views
81
Activity
Jun ’25
How to check if user still have valid subscription?
Is there an API Endpoint that I can call to check if user still have valid subscription? I want to be sure that his subscription renewal was succesful (ie: I dont want to give him another month/year/.. if his latest renewal wasnt successful) Would GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId} be the correct API endpoint to call? But I wonder, after subscription auto-renews, do we still use the same transactionId to check whether his subs is still valid?
Replies
0
Boosts
0
Views
58
Activity
Jul ’25