3

While testing renewable subscription purchasing with a Sandbox User I noticed something odd. In AppStoreConnect you can select a checkbox to interrupt any payments for a given sandbox user. If you do this during the payment process

  • the payment should fail
  • the user should be prompted to accept new terms and conditions of the app store
  • and then a new transaction should be added to the PaymentQueue with the same product

My problem is: The delegate method is never triggered after that happens.

public func paymentQueue(_ queue: SKPaymentQueue, updatedTransactions transactions: [SKPaymentTransaction])

It does get triggered properly when I initiate transactions. It also seems like the transaction created AFTER user accepts T&C is added to the queue, but the method it self is only triggered and starts processing transactions when I either: add another transaction manualy OR minimize and reopen the app.

As per Apple documentation this seems almost correct:

StoreKit can notify your SKPaymentTransactionObserver instance automatically when the content of the payment queue changes upon resuming or while running your app.

Apple documentation for testing interrupted purchases for reference: https://developer.apple.com/documentation/storekit/original_api_for_in-app_purchase/testing_in-app_purchases_with_sandbox/testing_an_interrupted_purchase

My question is how to handle such a transaction? For this interrupted transaction it always fail with a SKErrorCode of "unknown", and the only viable solution I found so far was to ask the user to restart the app which is not acceptable.

Any help would be appreciated. Thanks!

  • This also happens w/ consumables as well. Per your 2nd link, item number 10 doesn't happen. There is no call to the delegate directly after user accepts the T&C but it is still in the queue. (this is testing on an actual device. Using the simulator works) – app4g Dec 21 '21 at 12:39
  • https://developer.apple.com/forums/thread/653144?answerId=620952022#620952022 See this comment from apple, does it sound like in **scenario** the app is backgrounded for the T&C agreement, but in IOS14, the T&C comes up like a card/segue and app isn't really backgrounded. Hence, there is no go to background, show T&C, user agrees, then App comes back to foreground process? Did you ever managed to get this resolved? – app4g Dec 22 '21 at 00:58
  • So it seems like an Apple bug right? No, I was not able to resolve this but luckily that scenario is very rare so we just decided to live with it for now. I am still interested to hear any solutions from anyone who has managed to fix this. – Paweł Zgoda-Ferchmin Dec 22 '21 at 09:45
  • I've been googling for days now and no solution in sight. Apple didn't flag this as a potential issue during app submission? if so, that's great. But ```interrupted purchase``` is supposed to be the "norm" for the European market isn't it? The whole SCA (strong authentication) thing. My App isn't live with in-app-purchases, but yours is live and this is what your users are actually seeing? – app4g Dec 22 '21 at 11:15
  • this is what I ended up doing. https://stackoverflow.com/a/70484643/14414215 – app4g Dec 26 '21 at 06:39

0 Answers0