#kuvana_api
obsidian thicketBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1260618485529182249
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
sly geyserBOT
lusty seal
Hi 👋 that's because the reader doesn't handle the actions if you aren't using the Server Driven integration pattern. They're controlled by the SDK instead.
sullen vortex
Gotcha, so with the SDK, would you look at the current state of the reader with this? stripeTerminal?.getPaymentStatus()
lusty seal
You don't check the reader's state if you aren't using the Server Driven pattern. Which of our SDKs are you referring to working with?
sullen vortex
Javascript. There must be some way to get the status of the reader from the SDK. I know in a previous integration, we use getPaymentStatus to check if the terminal is was already in a state of waiting_for_input or processing but I wondered if there was a better option
lusty seal
For a Javascript integration, you wait until you get a result from collectPaymentMethod:
https://docs.stripe.com/terminal/payments/collect-card-payment?terminal-sdk-platform=js#collect-payment
Is there something you're hoping to accomplish by checking the reader state before you hear back from that call?
sullen vortex
Yes, we want to check the state of the reader before starting the collection process to ensure it is not already in a collection process. The use case is a customer may only have one terminal, but multiple computers. One computer (A) could be connected to the terminal attempting to process a payment, another computer (B) could want to start a payment, but if we automatically connect from (B) without checking the payment is in process, it would cancel payment from (A) without warning.
A current flow we use
obsidian thicketBOT
lusty seal
It sounds like you'd want to use the fail_if_in_use parameter when connecting to the reader, so that the connection fails if the reader is already in the middle of something:
https://docs.stripe.com/terminal/payments/connect-reader?terminal-sdk-platform=js&reader-type=internet#multiple-connections
sullen vortex
Correct, that is what we are trying to do, but we still need a way to determine if the terminal is in use before sending fail_if_in_use as true or false.
lusty seal
I'm not following. You can set fail_if_in_use to true, and then the second computer won't be allowed to connect to the reader if the reader is in the middle of an action, and that failure is also your indication that the reader is busy.
sullen vortex
Right, but we don't want to automatically fail if in use. We only want to force connect the reader on user approval. There are use cases where a user tries to connect to a reader, but upon being told the reader is in use, they want to bail, and maybe choose a different terminal to send the payment to
lusty seal
In that case I'd:
- try to connect with
fail_if_in_useset totrue - if that connection fails because the reader is busy with another connection, you can then prompt your user for how they would like to proceed
- if the user wants to abandon, then you let them leave the flow. If they want to connect anyway, you make another connection request with
fail_if_in_useset tofalseto force the connection.
sullen vortex
Gotcha, that makes sense. Thank you