richappz - terminal

[austere bay]

Hey there, can you share some more context around this? Are there any specific error codes raised you can share?

[safe urchin]

Basically I can replicate this issue

DEVICE A: Connect to a reader > send payment to reader > cancel the transaction > disconnect reader

DEVICE B: Follow the same process

DEVICE A: Connect to the reader > send payment to reader > this will disconnect the reader with that error

Crazy thing is your delegates do not return a disconnect, don’t actually understand the error. And if you reconnect everything is fine again

[safe urchin]

This is on iOS

We are confirming on Android at the moment

[austere bay]

OK thanks - doing some reading here

[safe urchin]

Android SDK seems to be fine

[austere bay]

OK thanks for checking that and sharing your steps here. Are you able to share any specific error codes or messages raising by the Terminal SDK when this happens?

[austere bay]

your delegates do not return a disconnect
Can you share what you'd expect to see here instead?

According to the disconnection handling docs, showing a UI message is up to your app. Is this this not something you're displaying deliberately?
https://stripe.com/docs/terminal/payments/connect-reader?terminal-sdk-platform=ios&reader-type=bluetooth#handling-disconnects
Are you able to share the integration details related to your use of didReportUnexpectedReaderDisconnect

if you reconnect everything is fine again
You may want to store the reader serial number and handle this like the automatic reconnect flow:
https://stripe.com/docs/terminal/payments/connect-reader?terminal-sdk-platform=ios&reader-type=bluetooth#automatic-reconnection
and then re initiating payment collection

[austere bay]

I see you're offline @safe urchin but I looked into this some more. While the message of this error is coming form the stripe terminal SDK, as far as I can tell we do not show the UI Alert and this is being presented by your app. Can you confirm this, and what the underlying error is?

To debug this in more detail, I'd suggest logging each step of the flow (every SDK call) when Device A does the second connection/payment attempt. That is, can you specifically confirm that the device is in fact reconnecting, and which call causes the error to throw. One theory is that you might be trying to re-use the connection token from the first attempt with device A, rather than getting a new connection token. You should log what connection token is being used to confirm.

If you can do some additional testing to get more detail here, please either open a new thread with us here or email in to [e-mail] mentioning you spoke to us on this Discord (including my username), and we'll make sure to have someone investigate.

There more you're able to share the better we'll be able to try to reproduce the result you're seeing and determine why that is happening.