Question

I have a few doubts about transaction receipt verifications:

• why is an external server necessary? Why can’t I just contact http://buy.itunes.apple.com directly from the iPhone?
• what if this external server is down, or the receipt is not valid? How to communicate it to the payment queue? finishTransaction would still show a ‘payment succeeded’ alert view, because the transaction was actually successful, and I guess this would confuse users.

Sorry if I misunderstood the in-App Purchase flow or my questions aren’t clear enough. Thanks.

Edit: I guess I shouldn’t call finishTransaction if I find out the receipt is not valid, but is this a problem? The documentation says the application should always call that function. Also, at that point the money has already been transferred… confused

Answer 1

Receipt validation ensures that the transaction is complete and successful. You don’t want to do that from the iPhone because you can’t really trust the user’s phone.

1. The user initiates an in-app purchase
2. When complete, the app asks your server for validation
3. You validate the receipt with Apple: if it’s valid, you can perform whatever action linked to the purchase (unlock/deliver content, register subscription…)
4. The app removes the transaction from the queue (finishTransaction)

If the server is down, you shouldn’t finish the transaction, but display an “unavailability message” to the user.

- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions

will be called again later.

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…

In my apps, receipt validation is done through a web service, returning an error code in case of an invalid receipt. That’s why an external server is needed. If a user somehow manages to skip receipt validation (by faking the web service “success” response), he won’t be able to unlock the content / access functionality because the server has no trace of the purchase.