#dev-travis_error
knotty zealotBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1436343229451603998
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- dev-travis_error, 1 day ago, 6 messages
ebon burrow
👋 Hi there, just taking a look now
late mulch
I need edit my comment:
Our merchants typically keep the app running for many hours. Sometimes, they lock the device using the physical power button and leave it idle for a while.
However, when they return to use the app, we encounter this error inside the collectPaymentMethod function.
It seems the SDK does not automatically reconnect the reader (autoReconnectOnUnexpectedDisconnect: true doesn’t take effect).
After this error, if we attempt to initiate a new payment, we get another error: “You did not provide an API key.”
So, I’m planning to handle the reconnect manually, but I’m concerned that this might conflict with the SDK’s built-in auto-reconnect behavior.
ebon burrow
Just checking for reasons that it wouldn't be auto-reconnecting, but if you do want to handle the reconnect manually, just set autoReconnectOnUnexpectedDisconnect to false, and this will prevent any conflicts
late mulch
@ebon burrow Hi , Thanks for follow up.
Yes, I know that, I can implement my own reconnect logic,
but what important is why SDK auto reconnect not working?
And I think It's better to rely on SDK auto reconnect.
Would you please retrive data from device serialNumber ?
like disconnecting reasons?
ebon burrow
Yep, just looking into that now
late mulch
Thanks a lot.
ebon burrow
Is this in test mode or live mode?
late mulch
live mode
ebon burrow
So the autoReconnectOnUnexpectedDisconnect option is designed for reconnecting when, for example, a network connection drops temporarily, but what it happening in this case is by locking the device for an extended period of time, it's causing the app to close as if you had specifically closed the app. In this case, you need to restart and re-connect, it's not handled by the flow related to autoReconnectOnUnexpectedDisconnect
knotty zealotBOT
late mulch
ok thanks for checking.
1)As I see in docs :
not only for a network connection drops temporarily
it also cover Tap to Pay reader unexpectedly disconnect
-
We’re using the IMIN Swift 2 Pro device with kiosk mode enabled, so users can’t move the app to the background.
We’ve also set unrestricted battery usage from the app settings and use the Duraspeed app to ensure optimal performance and prevent Android OS from killing our app’s processes. -
Just to clarify — do you suggest restarting the entire app, or should I only re-run the reader discovery and connection process?
I’m concerned that doing so might conflict with the SDK’s built-in autoReconnectOnUnexpectedDisconnect behavior.
4)Also, were you able to find anything useful from the device serial number?
rose scarab
Hi there, taking over for @ebon burrow as they had to step away
Let me catch up on the conversation. I did take a look at the logs from the device serial number, but there weren't any errors that stood out, at least in the last 24 hours. Do you know a specific time I should look for when this issue was occuring?
late mulch
Yes, The last two hours.
rose scarab
The only error I see on our side during that time is this, which is not that informative in this case
2025-11-07T12:35:30.479 com.stripe.stripeterminal.external.models.TerminalException: Tap to Pay reader is not connected
late mulch
Yes, exactly — that’s the one I was referring to.
late mulch
ok thanks for checking.
1)As I see in docs :
https://docs.stripe.com/terminal/...
@rose scarab ,Would you plz check this comment??
rose scarab
Yes, juggling a couple of threads right now, will make sure to find the answers to your questions
late mulch
Ok, No problem.Just take your time.
trail burrow
Hello
Jumping into help out here
Just a few clarifying questions
- In your ask, Is the reader getting disconnected when your app is still in active state?
- Are you seeing any of the attched delegate methods getting called?
I see you've mentioned that merchants sometime lock the screen, I suspect the OS is reclaiming idle memory and disconnecting the Reader automatically
autoReconnectOnUnexpectedDisconnect is supposed to work when the application is in active state
Some devices run a flavor of android which is more aggressive in deleting stale references/objects which might interfere with the SDK's operation.
You'd generally get “You did not provide an API key.” error when the Connection Token has expired and the SDK was unable to fetch one before you called the SDK method
In order to prevent the error, you can check the connection status before you resume the flow by calling getConnectionStatus()
One other option you can try is to build a "retry" mechanism where if you see any connection related errors then try to re-initialize the SDK
late mulch
Hello @trail burrow , Thanks for your time.
-
Kiosk mode enabled on all of devices(and protected with passcode) , so merchants can’t close the app.(so app will be in active state).
just merchants Sometimes they lock the device using and leave it idle for a while. And I thinks you right : Android OS may reclaim idle memory and disconnecting the Reader automatically. -
None of this callbacks not worked for me and not triggered even in normal conditions like disconnected internet (I wondered why ?)
-
If I implement a retry logic based on what you suggested — for example, re-initializing the terminal when a disconnect occurs — will that conflict with the SDK’s built-in autoReconnectOnUnexpectedDisconnect behavior?
trail burrow
It shouldn't since that callback isn't really getting invoked anyway.. But you can disable that since you are going the manual reconnection route.
late mulch
Would you please explain more?
knotty zealotBOT
late mulch
So you saying: always handle disconnect manually and forget about auto reconnecting?
trail burrow
Yeah since the Reader only gets disconnected when the device gets locked, you could try that to see if that makes a difference.
I've just tested my test app and I do see autoReconnectOnUnexpectedDisconnect working as expected so I'm not sure if this is an integration issue or a device specific issue
late mulch
ok , last question :
In your example app auto-reconnecting work after lock the device and open it after 1h?
trail burrow
Unfortunately I can't test that due to time constraints
You can clone this - https://github.com/stripe/stripe-terminal-react-native/tree/main/example-app and give that a try
late mulch
Ok, and thanks for your time.
Have a good day.