Sudden issues with IAP receipt validation

Is anyone else having problems with the IAP validation?


My app was working fine for the past year until this morning. All of a sudden, people are still able to purchase an in-app but the receipt validation seems to fail, so they are not getting their content.


Anyone else experiencing something similar?

Replies

Can we have an updated "VerificationController" class for the https://developer.apple.com/legacy/library/releasenotes/StoreKit/IAP_ReceiptValidation/index.html ? So that, it helps most of the developers in getting the issue fixed for the exsting apps and submit the apps in store again to make the purchase working correct?

I'm running into this problem with a released app but not with Testflight builds. So I gather the certificate change doesn't affect IAP in Testflight?

Never mind, my mistake: I didn't realize we had receipt validation turned off in this build.

So, now how do we update the VerificationController? Did anyone figure it out yet?

Can anyone please point to the right direction on how to update the verification controller?

Use the new receipt not the deprecated transaction.transactionReceipt. Decode it using OpenSSL or send it to Apple servers. This has been known for years. Sometimes ostriches with their head buried in the sand get slaughtered.

Is there any guide to this?I am using the verification controller that was provided by Apple back in the days and what i would like to know is if i can change some parts of it to make it work?

As noted above, the certificate expired. You can


1) try to see if installing a new certificate will work - such an easy fix I wonder why it wasn't proposed by Rich so maybe it's not so easy.

2) delete those lines of code that use the cerrtificate.

3) use the new system described here:

https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Introduction.html

I managed to remove all the code that uses the certificate and everything works now but only in sandbox unfortunately.

You are a bit vulnerable because you are not checking that the entire receipt is signed and has been sent to you from Apple not from some hacker. But the good news is that there is no way the hacker can know what the device's identifierForVendor is and you check that to be sure it is correct. That is except if you have more than one IAP then the hacker can grab the first receipt, decode it and then send a new receipt into the device. It's hard but it can be done.


Look into decoding the new receipt.


I have thought about creating a method of sending receipts directly from the device to a trusted server and using that trusted server to verify receipts on Apple's server. I wonder if there is a need for that service.

Unfortunately the solution of removing the line sthat use the certificate does not work on the device only on sandbox, i just checked it with testflight. But i can not understand why this is happenning. It should work right? Maybe can i remove verification completely? But then wouldn't i have a problem with purchases? By the way i have 7 non-consumable iaps and 3 consumable.

Then either send the receipt to the Apple servers or learn how to decode a post-iOS6 receipt.

I want to verifiy receipt without returning 21007 .. can I do this or not ?
If there is a way how i can do it , and i want to know if server redirect automatically to sendbox server and return response or I must redirct with code ?

There is no automatice process to process the 21007 response to forward the receipt to the production verifyReceipt server. The process which sees the 21007 status result, must handle forwarding the receipt to the production server.


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI