#milan_terminal-reader-timeouts-idempotency
valid bobcatBOT
👋 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/1404499588068413442
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
compact comet
Hi 👋
Even minor network outages could cause this. Since you say the payments go through then what is happening is the reader is successfully sending the payment confirmation to Stripe but the connection gets dropped before the response gets back to the reader. Let me check the logs for this reader.
Looking at some of the connection logs we have, it looks like this reader switches between a 2.4GHz and a 5GHz channel on the same network
Do you have a lot of traffic on your network?
Hmmm... I'm seeing a lot of disconnection events over the past week 🤔
sturdy rivet
I can't really tell, we are working on this remotely. I'll definitely relay the connection stability info to our client, but on my side, I need to make sure a dropped connection does not result in a payment being captured, while the sale order or invoice remains marked as unpaid.
compact comet
To your specific question:
Would sending the request again (instead of immediately considering the payment failed), as recommended in the docs, be enough to guarantee consistency?
This is the recommended approach but with one minor tweak. Make sure you make an idempotent request like we document here
I can't really tell, we are working on this remotely.
Okay yeah that makes a big chunk of Terminal troubleshooting difficult, since the performance tends to bottleneck around network connection issues.
but on my side, I need to make sure a dropped connection does not result in a payment being captured, while the sale order or invoice remains marked as unpaid.
This is where using the idempotency key from the initial request will help. In fact, network drop outs like this are pretty much the ideal use case. Since the request was successful, it's just the response that failed, the Stripe APIs will just re-send the response payload
So no new action will actually be attempted
sturdy rivet
Got it, thanks for the info and research! I see some references to idempotency keys in our code but haven't checked every single case; I see some idempotency keys on all requests when inspecting them in dashboard.stripe.com workbench view, does this mean they were indeed included in each case, or are they auto-generated when missing?
compact comet
Our SDKs automatically generate them so, if you need to re-run the same request, you can use that idempotency key
compact comet
Happy to help 🙂