#dev-travis_error

1 messages · Page 1 of 1 (latest)

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.

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 :

https://docs.stripe.com/terminal/payments/connect-reader?terminal-sdk-platform=react-native&reader-type=tap-to-pay#handling-disconnects

not only for a network connection drops temporarily
it also cover Tap to Pay reader unexpectedly disconnect

  1. 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.

  2. 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
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

#
  1. In your ask, Is the reader getting disconnected when your app is still in active state?
  2. Are you seeing any of the attched delegate methods getting called?
Screenshot_2025-11-07_at_8.53.44_AM.png
#

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.

  1. 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.

  2. None of this callbacks not worked for me and not triggered even in normal conditions like disconnected internet (I wondered why ?)

  3. 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
trail burrow
#

That will explicitly disable auto-reconnect

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
late mulch
#

Ok, and thanks for your time.

Have a good day.