#jbring34 - reset M2
1 messages ยท Page 1 of 1 (latest)
jbring34 - reset M2
Good question. Checking in to this and will get back with what I can find.
Thank you
It looks like there is a disconnectReader function that you can call. I am trying to confirm whether calling that and connecting again would reset some state on the reader https://stripe.com/docs/terminal/references/api/js-sdk#disconnect
Thank you!
Hello ๐
Can you clarify what kind of "state" are you trying to reset exactly?
Not sure I understand the context here
We had an issue where the reader got stuck in the collectPayment method and when we tried to disconnect we got this error
What SDK are you using? Looks like iOS but just want to confirm
iOS
So what we are trying to do is have a button somewhere where if this happens the user can press a "reset" button or something and the reader just goes back to it's idle state. We haven't been able to recreate this error but just want a solution in case it happens again
Gotcha. For iOS, when you call collectPayment then it returns a Cancelable object as shown in the example
https://stripe.com/docs/terminal/payments/collect-payment?terminal-sdk-platform=ios#collect-payment
https://stripe.dev/stripe-terminal-ios/docs/Classes/SCPCancelable.html
You need to use that to cancel the collectPaymentMethod action
You can't directly disconnect unfortunately
This is our collectPayment method, I believe we are cancelling correctly with it, can you take a look at that file and see if we are handling it correctly?
I can't seem to download the file for some reason ๐ค Can you share the snippet instead?
The second screenshot is the end of the function
Why are you setting self.cancelable as nil in your callback?
Because that is our class level cancelable, we set the collectCancelable to self.cancelable before we set it to nil and then use collectCancelable to call the cancel function
So far out of all the times we have tested, we have only hit this issue once, all other times it cancels correctly and the reader goes into its idle state
Gotcha. Are you also calling the same logic on a button click?
At the moment it looks like its only called if recollectAfterBrandDecline is false
Yes, we have an Exit button where the cancelable.cancel is also called
The button action is a function that calls it^
And you don't have a separate button for disconnect right?
We do, but not on this screen. Once they press the exit button they get taken to a screen where we have a disconnect button
Gotcha. Honestly, It could've been a race condition of some sort where the disconnect got called before cancellable succeeded.
What you have is exactly what we recommend, call cancellable first then disconnect Reader.
We don't have a "force" disconnect function in the SDK so there's no way to end the current action abruptly and start a new one.
Alright we kinda figured it was some odd case since we only saw it happen 1 time out of all the testing. Thank you for looking it into it!