Should there ever be duplicate receipt data values when sending data to Apples servers?

After a purchase is made and I'm sending receipt data as outlined in documentation here...

https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-CH104-SW1


Should the "receipt-data" field change after every purchase? I am doing server validation and logging all purchases. The receipt data is logged before the validation is done and analyzing this receipt data which is sent from the client it seems there are numerous purchases made where the "receipt-data" field never changes. Is this correct behaviour?


I am using [[NSBundle mainBundle] appStoreReceiptURL] to get the receipt data of a purchase.

The receipt data should change after each purchase. the one exception to this is if your app chooses to verify the first receipt for an autorenewable subscription over and over again. For an autorenewable, Apple will look up the latest receipt and provide that information back to you. But there is a bigger question here. What do you mean when you say you are validating the receipt? Is it possible that you are not looking at the content of the validated receipt but just whether it is a valid receipt? All purchases come with a new unique transaction_id. If you get a repeated transaction_id then someone may be hacking your app by sending a copy of an old receipt through the system for you to verify.

Hey there,


Thanks for the reply. Good to know that the receipt data should change after each purchase we're not using any subscription purchases so that shouldn't be a factor here. Do you have any reference for citing that the receipt data should be different every time? I couldn't locate this in Apple documention. In terms of validating the receipt as far as I can tell we do have everything as required. At a high level we do the following...


- Pull [[NSBundle mainBundle] appStoreReceiptURL] on the iOS device after a purchase

- Send an HTTPS request to our server with the receipt data

- Our server sends a request to Apple for receipt validation

- Our server analyzes the response from Apple to check that receipt was validated correctly

- Our server sends an HTTPS response back to the iOS device on whether the validation succeeded or not


Duplicate transaction ID's is definitely something I will investigate as well thanks for mentioning that. On another note do you have any knowledge of what the transaction ID's should look like? I'm seeing serveral different formats come in one of which seems correct, one of which I'm not sure of and one which is definitely wrong. The formats are...


72E48523-670C-41DB-95BF-B8A90D060592

  • Obfuscated value seems valid to me


400000183133500

  • Long single value, not sure if this is valid or not?


com.mycompany.myapp.gems.tier41449669175207

  • Bundle identifier with random numbers on the end. Apple flags this as invalid which is what I would expect.


Looking at the purchase data if you factor out the known invalid purchases as indicated in the third case the daily purchase data dosn't add up from daily revenue reports provided by Apple.

The long single value (400000183133500) is the correct format. The others are both fakes. Quite unusual fakes - there must be more to your story.


Actually, I misspoke when I wrote that a repeated transaction_id must indicate that the receipt is a copy of a receipt from another transaction (i.e. a fake). It could be a repurchase (for free) of a non-consumable for which the transaction_id in the receipt is the original transaction_id. Apple seems to have broken their verification system in this case in that the transaction_id is not unique. You can check the receipt_creation_date to be sure it is a current receipt and not an old copied receipt pretending to be a valid repurchase-for-free receipt. Or you can tell the user that if they repurchased for free they should, instead, 'restore' the purchase. Or, you can figure out how to decode the receipt on board.

Hey there,


Thanks again for the info. Very insightful I'm wondering though how can you tell that the "72E48523-670C-41DB-95BF-B8A90D060592" format is incorrect? It does seem incorrect but can you point to any Apple documentation that justifies this?


In perhaps some somewhat related investigation I have found that there are a number of transactions coming in which have an empty "in_app" field for the receipt result returned from Apple's servers. Seems very suspicious and I can't see case where you would ever make a valid purchase and not having something in the "in_app" field consider we only have in-app purchase items as part of our purchases.

In you are seeing an empty in_app field, I refer you to Tech Note 2413 iAP FAQ <https://developer.apple.com/library/ios/technotes/tn2413/_index.html#//apple_ref/doc/uid/DTS40016228-CH1-RECEIPT-MY_APP_VALIDATES_ITS_RECEIPT_WITH_THE_APP_STORE_VIA_PAYMENTQUEUE_UPDATEDTRANSACTIONS__AFTER_A_SUCCESSFUL_PURCHASE__HOWEVER__THE_RETURNED_RECEIPT_CONTAINS_AN_EMPTY_IN_APP_ARRAY_RATHER_THAN_THE_EXPECTED_PRODUCTS_>

The Tech Note describes the suggested action for an app to take when there is an empty in_app array.

The only time that I'm aware of this happening is when the application is run on a ****-broken device.

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

If your IAP is not a consumable then you have most likely detected an attempted theft (aka hack) on your product. That is the purpose of verifying receipts.

Should there ever be duplicate receipt data values when sending data to Apples servers?
 
 
Q