#intelagent_api
violet pewterBOT
👋 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/1248608744997130251
📝 Have more to share? Add details, code, screenshots, videos, etc. below.
analog scroll
hi there!
crimson finch
hi!
analog scroll
I'm not sure I understand. can you describe step by step the issue? like
step 1: terminal is waiting for user to enter their card
step 2: ...
step 3: ...
crimson finch
step 1: operator 1 send payment intent to reader1 and is waiting for customer to enter their card
step 2: operator 2 sends a payment intent to that reader1 by accident (instead of reader2)
step 3: customer taps card on reader1 and the wrong payment intent (meant for a different customer)
In short I guess the question is how can I acquire some sort of lock on a reader to avoid 2 users attempting to use the reader at the same time
analog scroll
got it! the flow described above is how it currently works? and you would like that at step 2 the operator get back an error?
crimson finch
to my understanding and from what I've seen testing yes. I would like it if the operator that tried to handoff a payment intent to the reader while there was already one on it - got a reader budy error
But clearly I'm just misunderstanding something here... .
analog scroll
and can you clarify which Terminal integration you are currently using? Javascript SDK, server driven, iOS/Android, ...
crimson finch
server driven with s700
Maybe it's enough to just fetch status before sending a payment intent? and any race conditions may be taken care of by terminal_busy_errors as stated here:
A reader can only process one request at a time. If you make two API requests to the same reader in parallel, one of them fails with a terminal_reader_busy error:
analog scroll
Maybe it's enough to just fetch status before sending a payment intent?
yes that's what I was going to suggest
crimson finch
it's unclear if that is a proper solution though from reading the docs imo
analog scroll
let met check with a colleague.
crimson finch
Ok great! Thank you very much
analog scroll
this is actually covered here: https://docs.stripe.com/terminal/payments/collect-card-payment?terminal-sdk-platform=server-driven&lang=node#verify-reader
To make sure the reader completed an action, your application must verify the reader state before initiating a new reader action or continuing to capture the payment
crimson finch
How exactly does that cover the case where 2 users might send a payment intent to the reader and one overwrites the other? Are you thinking that before sending a payment intent, we must check the reader state, confirming what we're thinking above?
analog scroll
Are you thinking that before sending a payment intent, we must check the reader state, confirming what we're thinking above?
yes exactly
crimson finch
Ok great, thanks for the help just tested this a bit and things seem like they are working pretty well. Have a good one!
analog scroll
happy to help 🙂