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 principally come from the Ask to Purchase program.

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

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

Questions:

• What callbacks can 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 hearth a callback?
• When ought to we name finishTransaction for a .deferred
  fee?

If it is within the docs, I have not been capable of finding it. Trying by way of comparable questions on this website and others, I’ve discovered that .bought can be fired if the transaction is authorised. However I am unable to get readability on if or when .failed will hearth. There’s additionally disagreement on when to name finishTransaction.

Conflicting findings to date:

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 hearth:

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 dad or mum permits buying of the merchandise, then we’ll get .bought said in transaction observer, in any other case after 24 hours we’ll get transaction .failed observer.

This reply mentions the identical factor:

Replace UI that you’re nonetheless ready for dad or mum approval. You will get .bought if the dad or mum authorised, or .failed if both the dad or mum 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 dad or mum your app will get a .failed transaction to updatedTransactions, if it maintains an observer (or the following time it provides an observer). If the dad or mum doesn’t reply inside 24 hours it disappears with no transaction.

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

Whenever you initially observe a transaction go into the .deferred state, you may mark it as completed (finishTransaction) to clear it from the queue, because the profitable transaction can be added to the queue, or whether it is declined no replace happens on machine.

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 sensible, 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 believe the reply to that is don’t name it on the preliminary .deferred state.
2. If a .deferred transaction is authorised, it should hearth .bought. Whether it is declined, it should hearth .failed. But when it is ignored for twenty-four hours, will it nonetheless hearth 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 greatest follow to trace and deal with these, since we won’t anticipate a callback? However which will require a separate query to be posted. A attainable resolution can be implementing paymentQueue(_:removedTransactions:), though the docs say you sometimes will not want this, so it appears unlikely.