After game restart first purchase is contained in receipt but the next ones is the same as first one so new purchases is not added. I afraid players can be charged for purchase but on my server I will not receive new purchases instead receipt with old one so they can do not receive in game currency. Will in production I receive a receipts with new consumable every time player purchase it? I use Unity3d In-app purchasing 5.0.1.

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

Issue Description I am experiencing persistent 401 Unauthorized errors when attempting to access the App Store Server API using JWT authentication. Despite following Apple's documentation and regenerating keys, I am unable to successfully authenticate. Implementation Details I'm implementing JWT authentication for the App Store Server API to retrieve transaction information from the following endpoint: https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionID} My JWT generation code (in PHP/Laravel) follows Apple's documentation: php$kid = '6W6H649LJ4'; $header = [ "alg" => "ES256", "kid" => $kid, "typ" => "JWT" ]; $iss = 'b8d99de7-b43b-4cbb-aada-546ec784e249'; // App Store Connect API Key Issuer ID $bid = 'com.gitiho.learnCourse'; // Bundle ID $payload = [ "iss" => $iss, "iat" => time(), "exp" => time() + 3600, "aud" => "appstoreconnect-v1", "bid" => $bid ]; $pathFileAuthKeyP8 = "AuthKey_6W6H649LJ4.p8"; $contentFileAuthKey = \File::get(base_path($pathFileAuthKeyP8)); $alg = "ES256"; $jwt = \Firebase\JWT\JWT::encode($payload, $contentFileAuthKey, $alg, null, $header); Steps Taken to Troubleshoot Verified that the Issuer ID is correct and in UUID format Confirmed that the Key ID matches the private key filename Regenerated the key with proper App Store Server API permissions Ensured the private key file is properly formatted with correct headers and footers Verified that the JWT is being properly encoded using the ES256 algorithm Confirmed the bundle ID is correct for our application Checked that the API endpoint URL is correct Additional Information This implementation previously worked correctly We started experiencing 401 errors recently without changing our implementation We are using the Firebase JWT library for PHP to encode the JWT Request Could you please help identify what might be causing these authentication failures? Is there any recent change in the authentication requirements or endpoint URLs that might be affecting our integration? Thanks for support me.

For testing purposes, I log out of media and purchases to use sandbox ID's to test in app purchases. Once I log out of media and purchases in device settings, in app purchases is still using my real apple ID, I'm not being prompted anymore to log into a sandbox ID for purchases.

I am finding that the verifyReceipt endpoint used to verify a receipt is failing on occassion starting around October 27, 2015. I realize this API is deprecated. I am using cURL to call verifyReceipt. The specific errors are 52 - Empty reply from server and 56 - Connection closed abruptly. This indicates an issue with Apple's server as I understand it. Is anyone else experiencing this as well?

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

Hi everyone, We operate an online game where all in-app assets are stored server-side and require a logged-in account (no device binding). I’d like guidance on four areas: Do we really need deviceVerification / deviceVerificationNonce? – Because every purchase is tied to an account and we enforce a global transactionId UNIQUE constraint, replay or cross-account reuse appears infeasible. Under these conditions, is omitting device verification acceptable, or are there situations where Apple still recommends it? Permanent rate-limit increase for the App Store Server API – During anniversary events we saw bursts of ~18 000 requests per hour, breaching the current hourly cap on the App Store Server API (verifyTransaction, getNotificationHistory, etc.). Is there a formal process to request a long-term rate-limit expansion (or an alternative tier) from Apple? When is an App Store Server API call required for a StoreKit 2 jwsRepresentation? Docs say “call the API if you’re unsure,” but there’s no clear cut-off. Because we fully validate the JWS signature plus the entire certificate chain (including CRL/OCSP checks) on our server, local cryptographic validation seems sufficient for consumables. For subscriptions we still plan to hit the API to fetch the latest status. Does this separation match Apple’s best practice? If Apple does recommend hitting the API for consumables as well, we’d like a concrete rule of thumb—e.g. “if the item price is USD 50 or higher, always use the API.” Is establishing such thresholds consistent with Apple’s intent? Refund-risk reduction from Send Consumption Info – Adapty reports a 40–60 % refund-rate drop for subscriptions when using Send Consumption Info (blog reference). Can we expect similar reduction for consumable IAP in social/online games? Any real-world results would be helpful. Thanks in advance for any guidance!

I’m trying to determine the most appropriate modern method for detecting whether a user originally downloaded a paid app (prior to transitioning the app to freemium/IAP-based access). Historically, this was done by checking for a valid App Store receipt and using SKReceiptRefreshRequest to ensure a fresh one was available. However, SKReceiptRefreshRequest and many related aspects of StoreKit receipt handling are now deprecated in iOS 17+. The current Apple documentation on receipt validation still refers to SKReceiptRefreshRequest, which makes things unclear. With so many deprecations and the push toward StoreKit 2, what’s the recommended path to: Check for a valid App Store receipt Confirm that the app was originally purchased (as a paid app, not via IAP) Persist this info to exempt the user from paywalling the app in the future I don’t need to validate purchases of IAPs — just to detect a legacy paid app download. Any guidance on best practice for this use case, preferably using non-deprecated APIs (StoreKit 2 or otherwise), would be appreciated.

We are currently using App Store Server Notifications V2 in a production environment, but occasionally encounter the error "Failed to parse signedTransactionInfo in the notification payload. status=VERIFICATION_FAILURE." What could be the cause of this error? Also, is there a way to resolve this error? After the notification from Apple was received on the server side, it was passed to the Apple library and an error occurred in the Apple library when decryption was performed.

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

Product Timeout, In App purchase is approved in App Store Connect. The Product ID and Bundle ID match. Environment macOS App in TestFlight Bundle ID: com.streamtime.StreamTime App Version: 1.1 (Build 51) StoreKit 2 Product ID: com.streamtime.premium Status: App & Subscription Approved Issue StoreKit product request (Product.products(for:)) consistently times out after 60 seconds in TestFlight, despite all connectivity checks passing. The same code works perfectly in Xcode with local StoreKit configuration. Diagnostic Results ✅ Successful checks: App Store connectivity (HTTP 200 from buy.itunes.apple.com) Backend API connectivity (HTTP 200) StoreKit 2 API available AppStore.canMakePayments: true Valid receipt exists Bundle ID matches Product ID matches approved subscription ❌ Failing: Product request times out after 60 seconds No products returned Code Implementation // Direct product request (fails in TestFlight) let products = try await Product.products(for: ["com.streamtime.premium"]) Logs 🔍 App Bundle ID: com.streamtime.StreamTime 🔍 Product ID: com.streamtime.premium 🔍 AppStore.canMakePayments: true 🔍 Apple Store connectivity: HTTP 200 🔵 Direct request for product ID: 'com.streamtime.premium' ⏱️ Direct request start time: 2025-08-30 10:21:32 +0000 ❌ TIMEOUT: Product request took longer than 60 seconds What I've Tried Removed manual in-app-purchase entitlement (per Apple's guidance) Using automatic signing Verified subscription is approved in App Store Connect Using Sandbox Apple ID in TestFlight Verified all network connectivity Questions Why does StoreKit timeout only in TestFlight when all other connectivity works? Are there additional configuration steps needed for macOS apps vs iOS? Could this be related to the automatic in-app purchase entitlement? Any guidance would be greatly appreciated as this is blocking our TestFlight validation.

We are currently integrating In-App Purchases for our app and have configured App Store Server Notifications (v2) in the Sandbox environment. During testing, we observed the following issue: When a transaction is cancelled, declined, or pending (e.g., Ask to Buy flows or authorization pending), No App Store Server Notification is sent to our webhook endpoint. We only receive webhook events where the status is "purchased". This becomes a critical problem for us because our backend must accurately track transaction states including failed and pending purchases, especially for wallet top-up use cases. Additionally, we tried mocking failed transactions (via Xcode local environment and turning off In-App Purchases from Developer Settings) to simulate a technical failure scenario. Even in these cases, no webhook notification was received when the purchase failed server-side. Is it expected behavior in Sandbox that only successful transactions ("purchased") trigger webhooks? Are failed or pending transactions suppressed in Sandbox intentionally? Will webhook behavior be different in Production (i.e., will we receive webhook notifications for failures there)? Is there any extra configuration or entitlement needed to fully test failure scenarios via webhooks in Sandbox?

Hello Fellow Developers, I recently built a simple craft related app called "Genie Crystals" with a landing page. there is a button on landing page which redirects to a main template generator page. Here the user can play with the parameters and create an output which can be exported. to export there is an unlock button which is linked to the in-app purchase configured in the app. Initially it was not capturing price properly so I modified the code slightly to keep the button in disabled state until the product details got fetched in background asynchronously. But when I released the app and downloaded it on a different device at the time of load itself, I am getting the alert - product not available. I have used correct product Id in the program. I have confirmed that. I think I am missing something. Any help will be appreciated. I am new to this so if I need to share any additional information kindly let me know. Thanks.

Hi, I am trying to obtain the subscription expiry date or purchase date from server using Storekit2 for my project. I have an account which is already having an active subscription but it still says no purchase found. Thanks

We have received reports from users that their in-app purchases suddenly appear as unpurchased. We would like to know the cause of this issue. Our implementation does not use a server; purchases are determined solely on the client side. These reports often occur after updating the app version, but we have been unable to reproduce the issue in our development environment.

Our app server has subscription feature and processes purchase life cycles based on App Store Server Notification v1. Last year, when users purchased subscriptions during the following timeframe, we received "INITIAL_BUY" notifications with "unified_receipt.Latest_receipt_info.purchase_date" set to future date(approx. 1 hour after the actual purchase). 2024-11-03 08:00:00 - 2024-11-03 09:00:00 Etc/GMT (UTC) For example, we received the following v1 notification at 2024-11-03 08:36:33 Etc/GMT. "notification_type": "INITIAL_BUY" "unified_receipt.latest_receipt_info[].purchase_date": "2024-11-03 09:36:02 Etc/GMT" Our server grants subscription entitlement based on "purchase_date" so the users had to wait 1 hour before the subscription features became available. The timeframe coincided with the end of daylight saving time in the U.S., so we assume that it affected the behavior, but our country doesn't adopt daylight saving time. We have some questions regarding this behavior. In countries without daylight saving time, how should we handle such notifications with future purchase date in order to properly grant subscription entitlement? In App Store Server Notification v2, could purchase date be set to future date at the end of daylight saving time in the U.S., just as in v1 notifications? JWSTransactionDecodedPayload.purchaseDate

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.

Looking for assistance in managing subscription upgrades for TestFlight users. I have a few monthly subscriptions, 30days, each with a different set of available features, 1 with all, and 1 with fewer. (All are in proper order and grouped in App Store connection subscriptions) subscribing seems to be working fine, and purchasing an upgrade is going ok. what is not: reflecting the upgraded plan in app (currently reflects it will start in 30days when current subscription expires) I’m lead to believe this will be resolved with a live app in App Store, that will then handle prorating, terminate the old plan and immediately start the new one. looking for help getting TestFlight to show immediate upgrades.

Hi, This is the first time I'm submitting an app using IAP with auto-renewing subscriptions. Everything keeps getting rejected (specifically, my subscriptions), and instead of telling me what's wrong or what I need to fix, my reviewer just keeps regurgitating generic passages from the rules. Is there a site/tutorial/whatever that explains how to set these up and submit them? I haven't found anything that looks official/legit, so I'll settle on something recommended by someone who has been through the process. I would appreciate any help. I have been at this for DAYS and am at my wits end. Thanks.

I had a two CS from customers that they couldn't buy a cookies(IAP). they got an alert "Purchases in this app are already purchased items." I was wondering if anyone has any similar experiences.