アプリ内課金を実装しようとしていますが、サーバサイドのセキュリティに関してについて質問です。 StoreKit２を使えばアプリとApp Store Connect間のレシート検証は不要だが、 購入情報をサーバーで管理する場合は アプリからサーバーに購入情報を渡す際にレシート検証する必要があると考えるがその認識であっているか教えていただきたいです。

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!

Dear Apple Developer Support, Our iOS application offers subscriptions with a free trial period. We understand that in South Korea, due to local subscription regulations, users must explicitly provide consent for recurring payments before the subscription converts from a free trial to a paid period. We have the following questions regarding how StoreKit handles this scenario: When a free trial is about to convert to a paid subscription for a user in South Korea, does StoreKit send a StoreKit.Message (or SKStorefront.Message) to the application to obtain the required consent for recurring payments? If such a message is sent, would the Reason for this message be StoreKit.Message.Reason.priceIncreaseConsent, or would it be another specific reason related to initial recurring payment consent after a trial? If our application receives such a message and we choose to defer its display, what is the maximum recommended or permissible deferral period? Is it possible to save the data of a received StoreKit.Message and display it to the user at a later time, for instance, after the application has been closed and subsequently reopened? Are there any best practices or limitations regarding this? We need this information to ensure our application correctly handles these consent requirements in compliance with South Korean policies and provides a smooth user experience. Thank you for your guidance.

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

Question on token testing in development: Hello, I'm developing a React Native application using StoreKit External Purchase. I'm having difficulties testing the transaction token retrieval in the development environment. Specific questions: Is it possible to test the transaction token retrieval in development/sandbox environment? Is there a special testing mode for developers that would allow simulating token reception without going through the App Store? Are there specific debugging tools to verify proper token reception? Question on native implementation: Regarding the native implementation of StoreKit External Purchase: Is there detailed documentation on creating native modules for React Native that implement StoreKit External Purchase? Can you confirm if the following approach is correct for native implementation: Using NSClassFromString(@"ExternalPurchase") Calling presentNoticeSheetWithURL:completion: Retrieving the token in the completion block Are there any code examples for complete native implementation? Question on implementation validation: For validating StoreKit External Purchase implementation: How can we verify that our implementation is correct before App Store submission? Are there validation tools or automated tests to check compliance? What are common errors to avoid during implementation? Question on best practices: Regarding implementation best practices: What's the best way to handle potential errors during token retrieval? How to handle cases where the user cancels the transaction? What are the recommended security checks for server-side token validation? Question on documentation: I'm looking for additional resources on StoreKit External Purchase: Is there specific documentation for integration with frameworks like React Native? Are there complete code examples for native implementation? Where can I find information about testing and debugging best practices? Additional technical question: Technical implementation details: What's the correct way to handle the ExternalPurchase class initialization in React Native native modules? Are there specific requirements for the URL passed to presentNoticeSheetWithURL? How should we handle the token in the completion block to ensure it's properly passed back to React Native? Question on testing workflow: Testing workflow questions: What's the recommended testing workflow for External Purchase implementation? How can we verify the token format and validity before production deployment? Are there any tools or methods to simulate the complete purchase flow in development?

We are facing a serious issues with in app purchases in our app. We offer 3 IAP: auto-renewable subscription 1W, auto-renewable subscription 1Y, non-consumable one-time purchase (LifeTime access) In our case 90-95% of transactions fail and we mostly get SKError code=2 . Sometime purchase fails several times for the same user so it’s very hard to believe that user intentionally cancels transaction for the same product 4 or even 5 times in a row. It happens regardless iOS version, device model, our app version. We've checked multiple threads with the same issue but coudn't find any solution. We do not offer any promotions, product identifiers are valid... Some users are able to make a purchases without any issues.

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?

Problem Summary Apple's provisioning servers are not generating the com.apple.developer.storekit entitlement for App ID com.driftnotes.app (Team ID: 43Y6AG5NPY), making it impossible to build iOS apps for physical devices despite all configurations being correct. Environment macOS: 15.3.1 (24D70) Xcode: 16.1 (xcode-select version 2409) Flutter: 3.35.2 • channel stable Account: Individual Developer (Kazakhstan) Bundle ID: com.driftnotes.app Team ID: 43Y6AG5NPY Error Message Error (Xcode): Provisioning profile "iOS Team Provisioning Profile: com.driftnotes.app" doesn't include the com.apple.developer.storekit entitlement. /Users/vyacheslavkuzin/Desktop/FlutterProjects/DriftNotesDart/ios/Runner.xcodeproj Steps to Reproduce Configure App ID with In-App Purchase capability (✅ verified in Developer Portal) Add In-App Purchase capability in Xcode project (✅ done) Configure entitlements file with StoreKit keys (✅ done) Enable automatic signing in Xcode (✅ done) Run: flutter build ios --release Build completes successfully ("Xcode build done. 13,8s") but fails at signing stage Expected vs Actual Result Expected: Provisioning profile should include com.apple.developer.storekit entitlement Actual: Profile is created WITHOUT the entitlement, despite all configurations being correct Configuration Details Developer Portal App ID com.driftnotes.app has In-App Purchase capability enabled ✅ All agreements are active in App Store Connect ✅ Xcode Project In-App Purchase capability added via Signing & Capabilities ✅ Automatically manage signing: Enabled ✅ Team: 43Y6AG5NPY (Vyacheslav Kuzin) ✅ Entitlements File (ios/Runner/Runner.entitlements) <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.in-app-payments</key> <array> <string>merchant.com.driftnotes.app</string> </array> <key>com.apple.developer.storekit</key> <true/> </dict> </plist> Build Settings CODE_SIGN_ENTITLEMENTS: Runner/Runner.entitlements ✅ PRODUCT_BUNDLE_IDENTIFIER: com.driftnotes.app ✅ DEVELOPMENT_TEAM: 43Y6AG5NPY ✅ Troubleshooting Attempted Multiple Attempts Profile Recreation: Manual and automatic profiles recreated dozens of times Cache Cleanup: Complete removal of: ~/Library/Developer/Xcode/DerivedData/* ~/Library/MobileDevice/Provisioning\ Profiles/* Flutter clean & pod cache clean Signing Methods: Tested both manual and automatic signing management Wait Periods: 48+ hours for server propagation Complete Profile Deletion: Removed ALL profiles from Developer account per Apple Support Apple Support Workaround Following Senior Advisor recommendation: ✅ Deleted all provisioning profiles from account ✅ Confirmed IAP capability in project ✅ Created StoreKit Configuration File for testing ✅ Verified automatic signing management ✅ Multiple "Try Again" attempts in Xcode Result: Problem persists Apple Support Reference Case #102680105923 - Senior Advisor Simone confirmed after internal team consultation that this requires engineering team attention and directed to Developer Forums. Technical Analysis What Works Flutter build completes successfully Pod install executes without issues (25,9s) Xcode build finishes successfully (13,8s) All dependencies resolve correctly What Fails Provisioning profile generation: Server creates profile but omits StoreKit entitlement All profile types affected: Both manual and automatic profiles Consistent across configurations: Debug, Release, Profile all fail identically Root Cause This appears to be a server-side bug where Apple's provisioning systems are not properly correlating the App ID's In-App Purchase capability with the StoreKit entitlement generation for this specific App ID (com.driftnotes.app). The issue is NOT in client-side configuration - all settings match Apple's official documentation exactly. The problem occurs during the server-side provisioning profile generation process. Request for Engineering Team This issue requires attention from Apple's provisioning infrastructure team to resolve the server-side entitlement generation bug for App ID com.driftnotes.app. Impact Critical: Complete inability to build iOS app for physical devices Business: Blocking app deployment and updates Developer Experience: Extensive time spent on troubleshooting correctly configured setup All configurations have been verified multiple times and match Apple's official documentation. The issue has been escalated through Apple Support (Case #102680105923) and requires engineering team intervention.

We are using consumable in-app purchases. Starting from May 27th, we began receiving refund callbacks with the notificationType set to ONE_TIME_CHARGE immediately after users successfully completed a payment. { "notificationType": "ONE_TIME_CHARGE", "signedPayload": "..." } During this period, we did not make any changes to our App release or server-side purchase handling logic. Could this issue result in actual refunds being processed? What steps should we take to resolve this issue? We also noticed in your changelog that a new notification type ONE_TIME_CHARGE has been introduced. Can we safely ignore callbacks with the ONE_TIME_CHARGE notification type without affecting refund processing or user experience?

I am currently using the App Store Server API Get All Subscription Statuses in the app I am in charge of. Please let me confirm the following regarding Get All Subscription Statuses. ■Prerequisites The language used is Objective-c, and I am using both XCode 15 and 16. I also have an App Store Connect account. ■Questions Is it possible to set and test each status of the App Store Server API Get All Subscription Statuses with TestFlight?

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

Unsure if this has been reported before, but I'm seeing a specific scenario where Apple is sending back faulty information in App Store Server Notifications. When users have payment failures that result in the membership expiring, and then reactivate later on with a different subscription, they are given a new originalTransactionId, yet we have three cases where we receive messages about the old originalTransactionId, indicating that after the user recovers their subscription, Apple is resurrecting the old subscription and treating it as if it is active BUT ultimately decides to deactivate it. Here is a sample screenshot of an impacted user. We only have three month and annual plans. Timeline: March 21st: This user signed up for a 3 Month Plan June 21st: This user fails to pay July 7th: After our 16 day grace period, this user loses access July 29th: This user sees they lost access and repurchase Augsut 19th: Their membership is deactivated (long before their 3 Month Subscription is up) For further verification I've also attached a record of all the payloads we've received from Apple for this user. Please let me know if you need any more details to fix this bug OR if it has already been fixed! Thank you. user_webhook_data_sanitized.csv

I am currently developing an auto-renewal subscription in-app purchase for my app. Currently, the subscription items have already been approved in appStoreConnect, and the .store file is synced with appStoreConnect, so the subscription items are displayed well and the test is also progressing well. However, when I build without using the .store file to perform sandbox testing, the subscription items do not appear and response.invalidProductIdentifiers appears. Is there anything I need to do additionally so that the subscription items can appear in response.products? ps. The bank account item in the contract is in 'processing' status, and the paid app contract status is 'waiting for user information'.

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.

I try to access the AppDistributor.current (using try await) and the property never seem to return nor throw. The code I'm using looks like this: do { print("accessing current") let current = try await AppDistributor.current print("current obtained") switch(current) { case .appStore: return "AppStore" default: return "Unknown" } } catch { return "Exception: \(error)" } But the log only shows the accessing current and never the current obtained. Trying to step in the property starts with some assembly, but at some point, the debugger just never returned. I join a full Swift file of a sample test I'm using: SwiftMarketplaceTests.swift

The same store kit configuration file works in iOS and iPadOS, but not in macOS for the same multi platform application project with a single scheme. Here’s a more detailed write up with the sample code and screenshots. When the simple app is run on https://www.reddit.com/r/SwiftUI/s/KJsYcggWOa EDIT: I’m using Xcode 16.4

I'm working on an app the has implemented inapp purchases. They have been working so far, and they keep working currently. But just a couple of days ago, a specific user sent us a support ticket stating that when he purchases and item the bank charges it for the purchase, but within the app, the purchase fails and he doesn't receive the item. He sent us screenshots showing: The iOS native modal when a purchases has been finished correctly ("You're all set - Your purchase was successful "). Right after that modal, the app shows an internal modal showing "The purchase failed, please, try again later". Checking the app logs, that failure modal was triggered by "The operation couldn’t be completed. (StoreKit.StoreKitError error 1.)". Reading docs about this error leads me to think about device or user restrictions (parental controls, usage limits, etc...). It seems that in theses cases the bank charge could be issued but refunded later once Apple ultimately declines the purchase. However the user says that he doesn't have any kind of restriction. The only related thing is a "this device is also restricted by a profile" message, but everyone seems to have this message. What could it be causing this issue? In what scenariowould the app show a native OK modal but a storekit error 1? I'm pretty sure the app is well configured because I keep receiving purchases of all kind, from different users with any problem.

My server is able to receive notifications for successful purchases. However, we are experiencing an issue where we do not receive any server notifications when a consumable product is refunded. Could you please help us verify if this behavior is expected? Also, is there a way to trigger a test refund notification for consumable products in the sandbox environment, so we can ensure our server is correctly set up to handle it?

Hi all, I've received emails from other apps after making a purchase, with content like: You have purchased {App Name} on {Date & Time} and acknowledged that if you download or use this in-App Purchase within fourteen days of buying it, you will no longer be eligible to cancel this purchase. Do anyone know under what circumstances Apple sends a Purchase Confirmation Letter to the user's email after they purchase our digital products via IAP? Is this something developers can control? Additionally, I've seen pop-up reminders before making a payment in apps, with content similar to the above message. Are these reminders provided by Apple, or can developers create their own guidance to help users avoid accidental purchases? Kindly, Vanto

Hello, Our app supports family sharing skus, we successfully ran tests on family sharing features in sandbox, we noticed the feature does not work on live builds. The family member (child account) do see the subscription as "Shared with you". We attempted to restore multiple time and there is nothing to restore.