I don't believe this can happen. finishTransaction is a local thing.
> “paymentQueue: removedTransactions” Observer callback response.
This indicates finishTransaction worked.
>'finishTransaction:' will fail, but the transaction will be delivered and removed from the queue
This indicates that finishTransaction worked.
>"This In-App Purchase has already been bought. It will be restored for free."
This indicates that finishTransaction worked. The transaction is finished, the purchase completed. If you try to buy a non-consumable IAP a second time you get this message.
1. Does
finishTransaction:
always succeed?
Pretty much, yes.
2. Is the purchased SKPaymentTransaction always 'SKPaymentTransactionStatePurchased' when consume processing succeeds or fails after finishTransaciton: is called?
SKPaymentTransaction is set in a call to updatedTransactions. finishTransaction is called after that call to updatedTransactions - the value of the SKPayementTransaction won't change when you call finishTransaction. But the value won't be preserved after you exit updatedTransactions.
3. Is there no need to distinguish between cases where finishTransaction fails due to network disconnection?
Only in the case of a consumable IAP to avoid giving the purchaser a double credit. You can use paymentQueue:removedTransactions to check that finishTransaction worked. But how often do you expect the network to break given that it was working in the call to updatedTransactions? This is one reason why I think 'better than best practice' is to call finsihTransactions from within updatedTransactions and take over the responsibility to 'complete' the transaction with any remote server.
4. 'Calling 'finishTransaction:' results in a response of 'paymentQueue: removedTransactions:'. At this time, can I not check whether the transaction status is consumed?
I am not sure what you mean by 'status is consumed' but a call to this method indicates you have finished the transaction.