I'm in the midst of tying my current app's IAP code with our backend server. One thing I was thinking of doing was to also use it to record canceled and/or failed transactions.
This brought up the question as to whether or not the transactionIdentifier for these types of transactions are considered unique? More specifically in the cancel case, I'm not quite sure if it is generating a temp identifier and then replacing it with one given by the App Store. And if so, is the temp one still unique?
I do happen to notice in Xcode a data member in SKPaymentTransaction called _temporaryIdentifier, which got me thinking about this possible scenario.
Note that I don't have to surface cancelled transactions to our server. I Just thought it would be helpful to have. It seems that I probably do need to send failure since I believe a deferred transaction that is not allowed will result in a failure.
No, don't count on them being unique, they are considered undefined for any state other than purchased or restored.
It is explicitly mentioned in the documentation for transactionIdentifier:
A string that uniquely identifies a successful payment transaction [...] The contents of this property are undefined except when transactionState is set to purchased or restored.