ios – StoreKit deferred transaction life cycle – which callbacks to anticipate?

SKPaymentTransactionState has 5 states, certainly one of which is .deferred. It appears .deferred funds will largely come from the Ask to Purchase program.

Per the docs linked above, upon receiving a .deferred transaction, we have to:

Replace your UI to point out the deferred state, and wait for one more
callback that signifies the ultimate standing.

Questions:

• What callbacks might be fired concerning the ultimate standing of a .deferred transaction? Will I all the time obtain both a .bought or .failed transaction for every previously-.deferred transaction, or are there some cases the place a .deferred transaction is deleted from the queue and doesn’t fireplace a callback?
• When ought to we name finishTransaction for a .deferred
  cost?

If it is within the docs, I have not been capable of finding it. Wanting via related questions on this website and others, I’ve discovered that .bought might be fired if the transaction is accepted. However I am unable to get readability on if or when .failed will fireplace. There’s additionally disagreement on when to name finishTransaction.

Conflicting findings to this point:

This reply mentions within the feedback that we should always not name finishTransaction on the .deferred state, since if the request is declined or ignored, .failed will fireplace:

No, we don’t want to complete the transaction for the .deferred state. It should keep within the transaction queue for twenty-four hours, in between if a father or mother permits buying of the merchandise, then we are going to get .bought acknowledged in transaction observer, in any other case after 24 hours we are going to get transaction .failed observer.

This reply mentions the identical factor:

Replace UI that you’re nonetheless ready for father or mother approval. You will get .bought if the father or mother accepted, or .failed if both the father or mother declined or 24 hours have handed for the reason that request.

Nonetheless, this accepted reply on the Apple Developer boards mentions that if a request is ignored for twenty-four hours, then it disappears with no transaction hitting the queue:

Whether it is ‘canceled’ by the father or mother your app will get a .failed transaction to updatedTransactions, if it maintains an observer (or the following time it provides an observer). If the father or mother doesn’t reply inside 24 hours it disappears with no transaction.

Lastly, this accepted reply on the Apple Developer boards says that it is best to name finishTransaction on the preliminary .deferred transaction, since it can later be added to the queue if profitable, or it can disappear with no transaction hitting the queue whether it is declined:

While you initially observe a transaction go into the .deferred state, you’ll be able to mark it as completed (finishTransaction) to clear it from the queue, because the profitable transaction might be added to the queue, or whether it is declined no replace happens on gadget.

The docs for finishTransaction say:

Name finishTransaction(_:) solely after the app has completed all work it
performs to finish the transaction.

And goes on to debate .failed, .bought, and .restored, however doesn’t point out .deferred. It appears to me .deferred has not completed all of the work it wants to finish the transaction, so that is implying to not name finishTransaction in that state. This is smart, however a extra direct reply can be good to know.

Abstract:

Listed below are the 2 questions I’ve concerning the .deferred life-cycle for which I have not been capable of finding official documentation, and solely conflicting solutions:

1. Ought to finishTransaction be referred to as on the preliminary .deferred transaction, or ought to we wait to name this till the transaction is finalized as a .bought or .failed transaction? I feel the reply to that is don’t name it on the preliminary .deferred state.
2. If a .deferred transaction is accepted, it can fireplace .bought. Whether it is declined, it can fireplace .failed. But when it is ignored for twenty-four hours, will it nonetheless fireplace a .failed callback, or will it simply be deleted from the queue with no notification in any respect?

Comply with-up query to #2 can be: whether it is deleted with out notification, what’s the finest apply to trace and deal with these, since we will not anticipate a callback? However that will require a separate query to be posted. A potential resolution can be implementing paymentQueue(_:removedTransactions:), though the docs say you usually will not want this, so it appears unlikely.