typical Apple, no explanation, will it be fixed? when will it be fixed? If there is a problem, they never answer and do not inform we were very unfair to Microsoft

Same here, please at least an explanation about the problem, so we can sure and stop killing our time.

You mentioned the general behavior. But that's not my question.When updatedTransactions method returns SKPaymentTransactionStatePurchased statate, we send the receipt to the server for validation. As I said, in some rare cases, server returns validation error because of empty in_app_purchase. In this case, the client downloads the receipt again with SKReceiptRefreshRequest and sends it to server again for validation. In this way, after the 2nd and 3rd trials, we can experience situations where the product comes to the in_app_purchase array and receipt can be validated.Apart from that, as I said again, we can get strange alphanumeric transactionId's. We got validation error from our server when transactionId is alphanumeric. But for example when the user restarts the application, updatedTransactions returns SKPaymentTransactionStatePurchased on app start and we get proper formatted transactionId. After we try validation, we get success now. This is another rare situation that we don't know the reason.We need to clearly understand the reasons of these situations in order to respond to the user correctly and to provide better service.Thanks..

We have a similar problem. We got a lot of timeout problems when validating receipts for out testflight users. Their receipt sizes are bigger than 200kb. How can we delete contents of Sandbox Receipts for out testflight users. They are using testflight version more than 3 year. With every unconsumable product purchase sandbox receipt size gets bigger.