15

I am writing an in-app purchase capability for ma iOS app. I'm selling some simple consumables (no downloads). I based my code on this tutorial/topic How do you add an in-app purchase to an iOS application? However I noticed it conflicts with official apple docs.

In this code when a Transaction fails for whatever reason, this code [[SKPaymentQueue defaultQueue] finishTransaction:transaction]; is called. However on apple pages https://developer.apple.com/library/ios/documentation/StoreKit/Reference/SKPaymentQueue_Class/Reference/Reference.html#//apple_ref/occ/instm/SKPaymentQueue/finishTransaction: it is written: "Your application should call finishTransaction: only after it has successfully processed the transaction and unlocked the functionality purchased by the user."

So which approach is correct? Should I call finish on failed transactions?

Community
  • 1
  • 1
Kraszim
  • 173
  • 1
  • 8
  • I think you should ask the provider of the answer to clarify this. It might be an oversight on their part and I would go with Apple unless that person explicitly stated that the Apple docs are incorrect. – trojanfoe Jul 09 '14 at 12:58
  • However with 1 rep you cannot post comments can you? I think you need to work-up some rep first and then ask... annoying. – trojanfoe Jul 09 '14 at 12:58
  • I can't. I'd require 50 rep which will be hard to get quickly I think. – Kraszim Jul 09 '14 at 13:01
  • Well if you can spare the time, give it a go. See if you can do it in a day. I'll start with upvote here. – trojanfoe Jul 09 '14 at 13:03
  • Does this answer your question? [IAP - How to cancel a purchased transaction if the content download fails, or the receipt is invalid ?](https://stackoverflow.com/questions/15906236/iap-how-to-cancel-a-purchased-transaction-if-the-content-download-fails-or-th) – Roman Podymov May 03 '20 at 20:50

2 Answers2

21

According to the Apple's In-App Purchase Programming Guide

Your app needs to finish every transaction, regardles of whether the transaction succeeded or failed.

So regardless of the transaction result, you always finish the transaction to remove it from the payment queue and then handle the state (successful or failed) in your code in order to provide the user with the appropriate information

spassas
  • 4,778
  • 2
  • 31
  • 39
  • 3
    You need to finish the transaction if the purchase itself failed (i.e. if the transactionState is set to failed). Once the purchase is completed, your app must only finish the transaction after the content is made available to the user (downloaded or unlocked). If the content delivery fails, the docs specifically state to *not* finish the transaction. "After you finish a transaction, don’t take any actions on that transaction or do any work to deliver the product." and "Don’t try to call the finishTransaction: method before the transaction is actually completed". – Luke Van In Dec 15 '17 at 20:35
  • @LukeVanIn The OP asks if he should call `finishTransaction:` when a transaction fails and that's what the answer is for. – spassas Dec 18 '17 at 17:42
3

This is an old thread, but I find the answer incomplete, which can be misleading, and Apple docs are a bit vague on the subject. The problem is how we define a 'failed' transaction.

We can identify many states:

SKPaymentTransactionStateFailed

You get notified Apple noticed something went wrong (i.e. user cancelled, credit card declined, the kid is not authorized by its father to make the purchase, etc) and informs you of the event.

You must call finishTransaction

SKPaymentTransactionStatePurchased

We can split this one in multiples ones:

  1. Receipt validated and content delivered. You must call finishTransaction
  2. Receipt is invalid. There is no agreement here, as Apple docs are vague. It's 95.0% certain this is a hacked/jailbreak purchase. You could call finishTransaction to remove it from the queue and thus lighten the load on your servers (otherwise the queue will keep asking your client to revalidate). However the other 5% is that Apple servers were down and somehow they returned invalid (or you interpreted as invalid) when actually Apple servers just were temporarily down.
    • This applies specially to consumable IAPs. Because once you call finishTransactions, the consumable IAP is gone from the receipt
    • For non-consumable IAPs, you can safely always call finishTransaction because worst case scenario the user can tap the button to restore transactions (which you have to implement as per App Store Guidelines)
  3. Receipt is valid, but could not be verified for temporary reasons (e.g. your servers are down, Apple servers down, internet connection went down). You must not call finishTransaction. The payment will remain on the payment queue and it will eventually ask you to try again (note that the device that attempts to try again may be a different iPhone, if the user is logged on from multiple Apple devices). Hopefully this time the servers will be back up.
    • This is a must for consumable IAPs. You can't call finishTransactions or else you'll get legit angry customers
    • Once again, for non-consumable IAPs, you can safely always call finishTransaction and rely on Restore Transactions instead.

If you don't perform validation nor have server-side inventory, none of this really matters to you, since there are not many points of failure.

Without validation nor server-side inventory, after receiving SKPaymentTransactionStatePurchased you update your database on the phone's storage with the additional/unlocked content, and after that you just call finishTransactions.

SKPaymentTransactionStateRestored

Same flow as SKPaymentTransactionStatePurchased.

SKPaymentTransactionStatePurchasing

You must not call finishTransaction

SKPaymentTransactionStateDeferred

You must not call finishTransaction

Matias N Goldberg
  • 357
  • 2
  • 9