Is it possible transaction_id may changes?

Sounds like you are being hacked. Is that possible? How is your server getting access to the decoded receipt? Can the user/hacker intercept that transmission and substitute a fake receipt with a 'different' transaction_id?

I would report, yes, in any case. The more feedback Apple gets in these cases, the more pressure they'll feel to help devs instead of just the users.

IAPs seem to be more trouble than they're worth lately, which is a shame, given the push towards subscriptions, I think.

No, it's not possible. I store signed apple receipts on my server, and update each of them directly using verifyReceipt iTunes api every day

Are you saying that you take the same receipts, send them to the Apple servers on different days and they return different transaction_ids?

If so, you must be storing transaction.transactionReceipts - those are deprecated, stop using them.

> Are you saying that you take the same receipt.

Yes. I can say more. I got updated receipt from apple and overwrite existing.

> If so, you must be storing transaction.transactionReceipts - those are deprecated, stop using them.

I don't use deprecated fields. I use fields from transaction data. All of them described here (and no info about something are deprecated):

https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html#//apple_ref/doc/uid/TP40010573-CH106-SW12

Also I found the thread https://forums.developer.apple.com/thread/26360 with the same issue, but without any replies.

This sounds like a bug report to me as well. However, it would be good to review the data first, but this is not the venue for an in-depth review of the problem. You can submit a bug report using the Apple Developer Bug Report web page - make sure to select the iTunesConnect product, then email me with the bug report number and I can ensure that it reaches the correct team.

The more difficult aspect of reporting this issue lies in providing a means to replicate the problem. The iTunes Production Support QA team will only process bug reports where they have an application binary and the instructions to use the binary that will provide the results which you've described. Of course you could provide applicationReceipt samples, but there will only be limited analysis and little action - that is until the QA engineers can see the problem happening live with an app. The reason for this requirement is to be able to see the server respond - which is key to understanding the problem. The iTunes Store server is the entity that is sending the contents of the applicationReceipt that is updated in the application. Seeing the server gather it's data to place in the receipt is important to analysing the problem.

The other thing is that the QA folks will start the test from the beginning - I wonder whether you have seen this problem with a new test user account.

A different way to approach this issue - why are you analzying the transaction numbers. The applicationReceipt is signed by Apple so modifying the receipt should not be possible, except by Apple. If the applicationReceipt is forwarded to your server, then passed to the appropriate verifyReceipt server and the contents are validated, then the in_app array should present a current purchase history of the user's in app purchases (at least current as the applicationReceipt)

rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

But wait - we need to get the facts here before calling 'bug' rather than 'new feature'. The OP says they are sending pre-existing receipts to the server on a daily basis in order to get 'latest_receipt' information. (Actually they wrote "Yes. I can say more. I got updated receipt from apple and overwrite existing. ")

So either

1) they are sending a transaction.transactionReceipt.

or

2) they are sending a

NSURL *receiptURL = [[NSBundle mainBundle] appStoreReceiptURL];

NSData *receiptData=[NSData dataWithContentsOfURL:receiptURL];

If they are sending #1 then its deprecated (despite protestations to the contrary) and the deprecation may be causing this behavior.

If they are sending #2 then there is no documentation indicating that they are to expect a latest_receipt or latest_receipt_info field in the non iOS-6 style receipt let alone that if such a thing exists it comes with the correct information.

I am assuming it is #2 - and Apple is returning updated information even though the documentation indicates otherwise. And this is a feature enhancement that we want. With the correct tarnsaction_id.

We have the same issue — https://forums.developer.apple.com/message/252423 .

We have the same issue, did you find any better solution? Or the reason why this happens?