#jaybabu_reader-timeouts
long vineBOT
👋 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/1297918547351179345
📝 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.
- jaybabu_best-practices, 2 days ago, 40 messages
- jaybabu_error, 3 days ago, 15 messages
scarlet copperBOT
whole stump
https://docs.stripe.com/terminal/payments/collect-card-payment?terminal-sdk-platform=server-driven#reader-timeout - the docs say to retry like we have done
vital bear
Hi again 👋 it looks like you'll want to use a different idempotency key there.
Our idempotent requests work by serving the same response from the original request if an idemptoency key we've already been provided is used. If the initial request never completed then we don't have a response to serve again in that case.
whole stump
What happens if we pass in a different key with the same payment intent?
vital bear
You'll make a net-new request to process that intent
whole stump
On rare occasions, a terminal_reader_timeout error code is a false negative. In this scenario, you receive a terminal_reader_timeout error from the API as described above, but the reader has actually received the command successfully. False negatives happen when Stripe sends a message to the reader, but doesn’t receive an acknowledgement back from the reader due to temporary networking failures
this case is what is happening
You'll make a net-new request to process that intent
yes, as a physical human being in front of the device. i paid for it on the original request, which never got back to stripe but got to the me in front of the device. what would be my experience?
Our idempotent requests work by serving the same response from the original request if an idemptoency key we've already been provided is used. If the initial request never completed then we don't have a response to serve again in that case.
Isn't the original response, terminal_reader_timeout? That's not what I am getting when re-trying the requset
vital bear
I don't think so, but it's hard to say without the ID of the original request you're referring to.
whole stump
pi_3QCLaKDCuRuHsY0o1Ululf0j
this is the payment intent
i sent the request id earlier
vital bear
For the repeat request, can you share the ID of the original request that led to the timeout?
vital bear
No, it would have a req_ prefix, similar to the one you shared originally. I can try to hunt it down in a couple minutes if you don't have it handy.
whole stump
req_W7byXIkPHwWyeZ
You'll make a net-new request to process that intent
yes, as a physical human being in front of the device. i paid for it on the original request, which never got back to stripe but got to the me in front of the device. what would be my experience?
I basically need to understand this scenario to know what to do next assuming the original request actually made it to the device
vital bear
I don't understand what you're trying to ask there. You control your POS flow, so you control what the human in front of your flow sees for the most part.
whole stump
- I call process payment intent
- Request fails with terminal_reader_timeout
- Request actually made it to the reader
- Customer pays
- I retry with a new idempotency key on the same payment intent
- What happens? What am I going to get back from the api?
vital bear
Depends on the state of the reader, I'd imagine. Either processPaymentIntent is going to behaves as it normally does when there isn't a timeout, or it's going to thrown an error indicating that the reader is busy if that's the case.
whole stump
How can I test this? It is not easy to simulate. I need a concrete answer
vital bear
Checking to see if a teammate who is more familiar with terminal is around to provide more insight on that.
vital bear
They said there isn't a way to test this, unless you configure your network to cut connectivity to a reader in the middle of it working to be able to simulate the reader losing connectivity.
But did confirm that checking the state of the Payment Intent, to ensure it didn't move to a succeeded status, and then making new request to proces the Payment Intent is the correct approach to recover from this scenario.
whole stump
It’s not going to move to success in the 50ms gap. Maybe in 3-30 seconds
But it sounds like neither Stripe or me know how to properly handle this situation
waxen oriole
👋 stepping in as toby had to step away