“restore purchases”

In testflight you make the purchase. Then you delete the app from the device. Then you reinstall the app on the device through tesflight and try to restore the IAPs you bought.This assumes the old app had the same productIdentifiers for the IAPs as the new app and that you haven't changed the bundle identifier.

When developing for Auto-Renewal; this was a common problem that I ran into. I wouldn't always receive all 6 transactions. More often I'd receive just the first one, then nothing else. Sometimes it would 3 or 4.In the end I re-wrote my whole system with the aim of capturing enough information to try to determine if this was my problem or Apple's. I stored the date and time of the last unexpected restored transaction, (you know when the user has tried a restoredCompletedPurchases as you request that, so when you get a restoredTransaction that wasn't trigger by this, then it's highly likely it's a Auto-Renewal).I then displayed a screen to the user, showing this information and when the receipt was last updated. I then offered the user a series of numbered options.1. Restore Purchases.2. Refresh Recipt.3. Manually Renew.4. Contact us.When the user clicked on Contact Us, it provided all this information and a human readable version of IAP transactions in the receipt, also what steps the user ha

We're sure that it's not an SKPaymentTransactionStatePurchasing state transaction.When there is an unfinished trasaction of a product identifier of p1, should p1 not allowed to make another new purchase, insteading, an alert box will show the user that it will be restored freely? So there might not be two transactions with same transaction identifier of the same product identifier.So, it may now disabey the princeples of In App Purchase.

Same here. The sandbox env is EXTREMELY slow. A ping times out. Trying to purchase some product results in not showing up the purchase dialog. Restoring works in 2 of 10 cases.Also a curl request to https://sandbox.itunes.apple.com/verifyReceipt sporadically gives mecURL error 56: OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 104 (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

Thanks for your reply?I want to leave the no ads part in the app for the people that previously paid.I want to delete the in-app purchase button from the user interface completely. But I supppose I really have to keep a restore option in the app? Also when I remove the IAP from sale in ITC for older app versions?If I don't offer a restore option, users who have previously paid and resinstalled the app for some reason, would not be able to benefit from the no ads part.

The same phenomenon occurred with the sample code for in-app purchase provided by Apple. Offering, Completing, and Restoring In-App Purchases https://developer.apple.com/documentation/storekit/original_api_for_in-app_purchase/offering_completing_and_restoring_in-app_purchases?language=objc I get the same symptom when I download the sample code, change the product ids for team and in-app purchases to my own, build with Xcode 13 and run it on an iOS 15.0.1 device. I checked it on multiple devices with iOS 15.0.1, but the same phenomenon occurred. Is there something wrong with the SANDBOX?

After a user restores an auto-renewing sub to a new device, that device will automatically receive updates about subsequent renewal transactions. But does the first device (i.e. the one on which sub was originally purchased, before it was restored on a second device) continue to recevie the same updates? And more specifically, if updates detailing latest renewal transactions are being sent to both devices - is the receipt data being sent to both devices identical, with same Transaction ID value for latest renewal transaction? The Restore process generates new transaction IDs for each restored transaction, but I don't understand what happens with the receipts that follow or how that works across mutliple devices. Thanks in advance for any light you can shed here.