in-app fraud

Hmm—those "bad" IDs look an awful lot like UUIDs. Those can be generated as easily as

UUID().uuidString

I don't have any answers but I'm curious... What form does the fraud take?

(i.e. What happens that someone should look out for?)

I'm not an IAP expert, but I understand that most fraud of this sort is performed by spoofing the storage used to record whether items have been purchased. If apps aren't careful to verify the App Store receipts that accompany purchases, it would be relatively easy to just modify that storage to trick the app into thinking that something has been purchased when in fact it hasn't.

Server side validation is simple if you have a server. In the app validation may be more secure because it can verify that the receipt is intended for the device. ----- The 50/50 ratio is misleading because hackers will indiscriminately try to scam all apps while real purchasers are more discerning. ------ It is very easy to push a call to the updatedTransactions method that looks like a real purchase but does not have a valid receipt - that is what you are getting. ------ Valid transactionIds are decimal number strings not hex.

Thanks, I will look into "receipt validation". Do you know if doing it locally prevents the common hack apps, or if you need to do it on your own server for it to work?

Well, you need to record the transactions you app makes on your own server, then compare the number of purchases that your log says occured, and that Apple says occured and pays you for. There are hack apps people can install that lets them make any in-app purchase for free, and they are very commonly used, especially in some coutries.

Thanks. So do you think I can safely reject any of the hex strings? From my logs it definately seems that way.

Yes, a hex string is wrong. But just looking for a hex string is not completely secure.

Fraud is not "widespread" if you do a serious work at validating transactions. But if you don't (and you don't) there are severail IAP crackers around for some times now. So users can cheat like a snap. Just having those crackers installed gives them your iAP.

We even see regularly users conplaining that their "purchase" was rejected as a fraud, because they wanted to do a regular legit purchase and "forgoten" they had the cracker. Some others pretend that the cracker came installed with a jailbreak without them installing it.

So server side validation is recommended or serious in-app checking if you can't, but the later is more difficult and less safe.

>So server side validation is recommended or serious in-app checking if you can't, but the later is more difficult and less safe.

Decoding and checking the receipt in the app is more safe than server validation. In the app you can check the identifierForVendor hash to be certain the IAP is intended for that device. You can't do that using the server unless you decode it yourself. Yuo also have to use a secure method of transfering the receipt from the device to your server.

By the way - server validation use to be able to use a unique transaction_id value to assure no duplicates. You can no longer do that because a repurchase-for-free will have a duplicate transaction_id.

Decoding and checking the receipt in the app is more safe than server validation. In the app you can check the identifierForVendor hash to be certain the IAP is intended for that device. You can't do that using the server unless you decode it yourself. Yuo also have to use a secure method of transfering the receipt from the device to your server.

Right. I published here somewhere and on StackOverflow the code to control the hash server side. That code is not more complicate as the one needed in-app. And, sure, you have to transmit IFV and receipt data through SSL. Then this is a matter of choice. Server model is more work to set-up and manage, while giving you purchase history details and log.