iOS repeatedly asking for app store account info after In-App Purchase(IAP) purchased via Beta App

I setup an IAP for an autorenewing subscription, and got up and running on store kit using apple sandbox test accounts setup in itunes connect.


I followed the documentation for developemnt: sign out of the app store on a test device, and then launch the app and go through the IAP flow using the sandbox account when prompted for an authentication. That worked just fine.


At that point, I was ready to introduce our IAP flow in beta via test flight. Accoring to the TestFlight FAQ (pg 7), you can use a normal iTunes account under Beta and charges for IAP's are free within the context of the beta app.


In our beta app the IAP flow completes successfully with a normal itunes account. The trouble is that after a period of time iOS starts prompting for account authnetication all the time, both in and out of the app. All of our users are seeing this behavior. It seems like the account status gets screwed up once your subscription expires in the beta version (30 min subs with 6 extensions).


As far as I know, I am not able to affect this. The store kit API's basically allow me to initiate the process, and I get a callback from storekit with the status of the purchase attempt. I do not control asking for authentication or anything like that, so I'm at a bit of a loss as to what I might have done in my code to caused iOS to freak out and aggressively prompt for authentication.


Has anyone else seen this behavior with in app purchases within TestFlight distributions? Any help / insight appreciated...thanks


Environment:


We are targeting iOS SDK 8.0, building against the 9.0 SDK.


* iOS versions: 8.1.4, 9.0.0, 9.0.1, 9.0.2

* Devices: iPhone5, iPad mini, iPhone 6/6s

Accepted Reply

It sounds like the "endless loop" problem form many years ago. That was caused by failing to call 'finishTransaction' on all of the transactions that came from the app store (one every 5 minutes, usually stopping after 5 but on at least one occasion continuing for a few weeks). Your app may not be calling finishTransactions because:

1) a coding error on your part

2) there is a bug in iOS9 whereby the transaction is not sent back to the device under certain circumstances (see discussion on this topic on this forum)


Check out #1 to be sure you are finishing all transactions including the ones that will be generated 5 times to any device that subscribes and sent to that device the next time it launches with or subsequently adds a transaction observer

Replies

It sounds like the "endless loop" problem form many years ago. That was caused by failing to call 'finishTransaction' on all of the transactions that came from the app store (one every 5 minutes, usually stopping after 5 but on at least one occasion continuing for a few weeks). Your app may not be calling finishTransactions because:

1) a coding error on your part

2) there is a bug in iOS9 whereby the transaction is not sent back to the device under certain circumstances (see discussion on this topic on this forum)


Check out #1 to be sure you are finishing all transactions including the ones that will be generated 5 times to any device that subscribes and sent to that device the next time it launches with or subsequently adds a transaction observer

I am seeing this problem on iOS 8.1.x as well, so I'm leaning towards #1 (a coding error).


I can say this much about the implementation: I register a singleton delegate (SKPaymentTransactionObserver registered with the SKPaymentQueue instance) for store kit callbacks in application:didFinishLaunchingWithOptions:. It is the only code path for trx processing, so that should be easy to check and make sure marking trx's is balanced.


I did catch the fact that you needed to register for callbacks early in the lifecycle to avoid missing callbacks to process incoming trx's from the store kit. Apple mentioned that someplace in the store kit docs I read before getting started.


I'll double check #1 and post back. Thanks so much for your thoughts.


Regards,

Seth

Just a quick follow up.


We tested a beta release of the app with the fix. In my case, the calback handling restored trxs was only marking the newest trx as finished, skipping the others. The other cases / code paths are properly marking trxs finished.


Unfortunately, the auth prompting continues. The sure fire way to trigger it is to back out of the app and swipe down to search from your home screen.


Either I'm still missing something in code, or the issue was not actually prompted by trx's hanging in the queue. Thanks again for the idea.


Regards,

Seth

Are you getting more prompts or could these prompts just be those left over from those transactions that you failed to finish before. Remember, unfinished transactions don't go away until you finish them and you can't finish them until you sign in as that user.

I had considered that, and allowed a few run throughs of the app hoping store kit would grab the remaining transactions that were not handled. I can still pretty much reproduce these cases:


If I swipe down on springboard to search the phone, I will get the prompt. Also, if I start something up like the podcast app which tries to access the app store then I also get the prompt. The intensity of the prompts has definitely dropped. I was considering making an apple account with a clean slate just to run through the beta from TF with and see.


Thanks for the continued interest.


Regards,

Seth

It seems like the receipt processing eventually straightens out the mishandled transactions. Continued testing with the account that was having auth issues has slowly but surely corrected. Thanks for the help!


Regards,

Seth

I repeat what I wrote above with an additional caveat....if an transaction exists that is not finished (no call to finishTransaction) then it will keep haunting the device until the correct user logs in and calls finishTransaction.


Caveat - once a device has issued an alert asking to have that ghost user log in, it can sometimes remain quiet for 7 days before reappearing. Back a few years ago I could expect a revist of the multiple requests to log in every Saturday morning like clockwork.

Hi


I'm having this exact same problem, did you manage to resolve it in the end and was it a coding error?


Thanks Aaron

Hi

I'm trying implementing In-App purchase and getting same error again & again, I've applied all things but my signin prompt comes again & again. Please let me know when will I do?. it'll be very helpful for me.

Please check this attached screenshot.

Thanks