The purchase date fields will work for this purpose. But the problem is that transactionIdentifiers are no longer are unique - they are duplicated in a restoreCompletedTransaction and in a repurchase-for-free. You used to be able to check the transactionIdentifier. But you must also check to be sure the receipt is unique and not copied. The issue in this case seems to be on Apple’s side and we’ve opened a DTS incident to try to get this resolved.

And then you can inspect the receipt for the correct productIdentifier. When verifying the receipts without a password they return a valid receipt JSON, so the receipt data seems to be ok. This is secure.Īlternatively you can send the receipt in a signed package to your server and respond back to the device using a similarly signed package in order to avoid a man-in-the-middle attack. That on board receipt will be signed with the user's identifierForVendor which will prove the receipt is for that device. Verify your receipt first with the production URL proceed to verify.

The only secure approach is to decode on the app itself using OpenSSL. Use the receipt fields in the responseBody to validate app and in-app purchases. This could then grant them access to my app (sic - you mean IAP) just by knowing the product name. Is there a way to tell whether it came from my app? I worry that someone could determine the name of my product and then spoof a receipt with the same name. On the validity of a receipt regardless of whether it came from my app.

Receipt validation apple sandbox