I have a question about the status (21010) of the receipt verification of in-app purchases. From time to time, I am doing receipt verification and I get the following error: 21010 The user account cannot be found or has been deleted. Guessing from the text of the official documentation, this error is expected to occur when performing receipt verification for users whose Apple ID has been deleted. Is this correct? Also, if correct, is it possible to reproduce this case? I tried deleting my Apple ID, but after a few days, the receipt verification did not show the above error. Does it take time for my Apple ID to be completely deleted? If anyone knows how to reproduce when the status of 21010 is returned, please let me know.

I have three questions about receipts for in-app purchase production environments. About receipts obtained locally We get the receipt in the following ways: let receiptURL = Bundle.main.appStoreReceiptURL let rawData = try Data(contentsOf: receiptURL!, options: []) Does the receipt obtained by this method include the receipt information of other apps? I would like to know if a purchase associated with multiple Bundle IDs is included in this receipt. In the Sandbox environment, only one application's information was confirmed. 2. Receipt if you haven't purchased anything What happens if a device that has not purchased anything gets a receipt using the above method? The behavior related to receipt is different in the sandbox environment and the production environment, so I would like to know the facts of the production environment. 3. Receipt when you sign in with a different Apple ID In the Sandbox environment, if you sign in to a different Sandbox account, you can see that the receipt for your previous Sandbox account remains. Is it a Sandbox specific issue? We're trying to solve this problem using the SKRefreshRequest method in the Sandbox environment only, is it unnecessary in the production environment? I would appreciate it if you could answer. Thank you very much.

If you purchase products that belong to the same subscription group, originaltransactionid remains the same. However, I don't understand if the originaltransactionid does not change in the following cases. cases Purchase a subscription Renew the subscription Cancel the subscription(on App Store App) Repurchase the same subscription Is originaltransactionid still unchanged in this case?

I'm considering how to handle Server to Server Notifications (S2S Notifications) for multiple server environments.I have two servers; one is for staging, the other is for production.I want to:- direct the sandbox notifications to the staging server- direct the production notifications to the production serverHowever, the following reasons make the above difficult.- Just one notification endpoint URL can be set for an app.- All the S2S Notifications are sent to the same endpoint URL regardless of the type of notification (production/sandbox).Therefore I came up with some ideas. I want to know if these are good ideas or any other reasonable solutions.■Solution 1Register two apps in App Store Connect, and use one as the test app, which will never be released. This way allows me to register two endpoint URLs. I wonder if this was a common solution, although I don't think it is an excellent idea to register apps that won't be released on App Store Connect.■Solution 2Receive all the notifications at one endpoint on the production server, and store them in the production database. Then forward the sandbox notifications to the staging environment by a batch script. With this solution, I'm worried that the source code between the production server and the staging server has to be different.■Solution 3Set the endpoint URL of a proxy server to receive the S2S Notifications. The proxy server is aware of the notification type (production/sandbox) and sends it to the appropriate server.I'm concerned that the risk of failure increases due to adding the proxy server in my system. And the security risks may increase as well.Any advices or suggestions?