Follow-up: three possible causes of such purchase failures. I have continued investigating and now have three possible explanations for the STORE_PROBLEM result. None is confirmed, so I would appreciate tips on whether any could produce the complete sequence reported above. 1. Invalid or stale Apple sandbox session I performed a controlled test on my own iPad: I signed in with a valid developer-created Sandbox Apple Account. I confirmed that purchases worked. I deleted that account from App Store Connect while it remained selected on the iPad. I attempted another purchase. Apple displayed: You are not authorized to make purchases of this InApp in Sandbox at this time. This Apple Account doesn’t have permission to make In-App Purchases. After dismissing it, my app displayed the same high-level failure message seen during App Review. RevenueCat returned STORE_PROBLEM. I understand that App Review uses an Apple-managed sandbox identity that does not need to appear in my developer-created Sandbox Test Accounts list. I am not suggesting that the reviewer’s account was missing from that list. Could an Apple-managed App Review sandbox session temporarily have an invalid, expired, or stale commerce authorization token? Could that produce: Product metadata and price load → purchase() returns STORE_PROBLEM → subsequent purchase() calls return storeProductNotAvailable If so, is there a way for the developer to diagnose that session? Apple’s documentation confirms that the active sandbox and Media & Purchases sessions affect the account used by StoreKit: Testing In-App Purchases with sandbox. 2. Temporary network loss on the review device The failed attempt had this timing: 11:11:46 UTC — App reached my server and created the purchase attempt 11:11:48 UTC — App reached my server and started Apple checkout 11:11:48–12:52:59 UTC — StoreKit purchase request was running 11:11:59 UTC — App reached my server and reported STORE_PROBLEM The device was online immediately before and after the StoreKit request, but my previous diagnostics cannot confirm continuous connectivity during those nine seconds. For example: Reviewer taps Buy while online - app registers the attempt - Airplane Mode is enabled or connectivity is interrupted - StoreKit cannot reach Apple - connectivity is restored - app reports STORE_PROBLEM Apple defines SKError.cloudServiceNetworkConnectionFailed as indicating that the device could not connect to the network: cloudServiceNetworkConnectionFailed. RevenueCat maps this StoreKit error, as well as some SKError.unknown results, to STORE_PROBLEM. Does App Review intentionally test In-App Purchases while changing Airplane Mode or network availability? Temporary Apple sandbox service problem RevenueCat specifically documents STORE_PROBLEM as an error forwarded from Apple that can occur when Apple’s server is unavailable. It states that Apple server problems are more common in sandbox than production. RevenueCat also describes STORE_PROBLEM as one of the most common errors leading to otherwise unexplained App Review rejections. Their guidance says that Apple’s sandbox can experience momentary outages and that repeating or resubmitting the test may succeed. This theory is consistent with the following facts: Products, localized names, and prices loaded correctly. Apple created no transaction during the failed attempt. The same product and binary purchased successfully later. No RevenueCat webhook was expected because StoreKit created no transaction. Could a temporary Apple sandbox outage affect the purchase-authorization service while cached product metadata and prices remain available? Could an outage or partial sandbox-service failure produce STORE_PROBLEM first and then cause immediate storeProductNotAvailable responses for the same product?