I use server side receipt verification.
When client's
- (void)paymentQueue:(SKPaymentQueue *)queue
updatedTransactions:(NSArray *)transactions
is called, and transactionState is SKPaymentTransactionStatePurchased,
client sends the receipt to our server,
and our server verifies it.
When the server side receipt verification succeeds,
client obviously calls finishTransaction, no problem.
When the server side receipt verification failed, because apple temporary returned non json, or client sent invalid receipt, or something, server returns that information to client.
Next, what should our client do?
Should we call finishTransaction?
This leads to invalid transactions living forever in the queue? like said in this question: iPhone in-app purchase: receipt verification
But if you find out that a receipt is invalid, you should finish the associated transaction. If not, you may have extra-transactions living forever in the transaction queue. That means that each time your app runs, paymentQueue:updatedTransaction: will be called once per transaction...
But if we do finishTransaction, our precious user is charged by this receipt (which we failed to verify), right?
Or does the verify-failed-transaction expires in some period?
Is this documented somewhere in apple's document? I couldn't find any in http://developer.apple.com/library/ios/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html
Yes, you have to finishTransaction.
It's up to you if you give the user what they want then. In some cases it's better to give the user what they want, even if the receipt is invalid or fake (using jailbreak). Especially when it costs you nothing.