#bwurtz999_unexpected
1 messages Β· Page 1 of 1 (latest)
π 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/1317181654154084422
π Have more to share? Add more details, code, screenshots, videos, etc. below.
HI π
There are lots of reasons that this might take a while, only a few of them I can review here.
Looking at the request you shared, I can see the total duration of that request in Stripe's servers was 0.8s, so that seems normal
Looking in the logs for this reader, it looks like this reader is receiving many repeated duplicate requests. This can slow down the processing as the reader has to identify the request is a duplicate and then ignore it.
Interesting. Can you give me a timestamp with an example so I can see for myself what you are talking about?
Or a request ID?
I'm not sure why my app would be sending duplicate requests but I can look into that
2024-12-13T17:52:08.792
2024-12-13T17:52:08.786
2024-12-13T17:52:08.779
2024-12-13T17:52:08.773
we don't have request IDs in the logs I"m looking at unfortunately
Timestamp is great! Thank you!
But you can see that, within the same second, we are firing Received duplicate message, ignoring logs
That's UTC right?
Yeah, everything we do is UTC
OK. I will look into that. This is probably related that issue, but I have a question about two different requests
req_dRfrBdYQIkuVJL was a failed request to process a payment intent, sent at 12:26:24 ET
Sorry
wrong request ID
req_S3DCh1rzHSZRkx was sent at 12:32:05 ET
13 seconds later, req_ZfkuFTpKBEvBRG was sent confirming the payment intent
I cannot explain this. How would the terminal process the payment if the process_payment_intent request failed?
Can you share the full log for this? The screenshot shows what I can see for this timeframe from the dashboard
Sorry but there isn't anything more in the logs besides the timestamp and error messages I shared
As for the PI that was confirmed
The reader still had the EMV data from a card_present tap
But if the process_payment_intent failed, how did it confirm the PI?
I guess I just don't understand how the terminal processed the payment if the request to tell it to accept card information failed
I find that confusing as well, since in the /confirm request, we clearly have the card details
Yeah exactly. This is a location with bad WiFi and it's been giving me all kinds of problems
There are long delays between adding cart items and having the card reader respond, etc
But the biggest issue is these unexplained payment confirmations
This is a location with bad WiFi
Yeah bad wifi is the bane of all terminal integrations π
But the biggest issue is these unexplained payment confirmations
Does this happen frequently?
Yes, happens multiple times per day
We are getting them a better hotspot
But I'm trying to update my application so it can handle this issue
I'm having a hard time recreating it in the first place (locally)
How does the terminal get the card details if process_payment_intent fails?
Or actually, I guess the terminal is always ready to accept card details
Well hold on, let me dig a bit on this request
The error says the reader is busy
So I want to make sure it's clear what the reader is doing while it's busy
It will beep when someone taps their card even if the cashier hasn't prompted for payment
This would be really helpful to know! Thank you
Wait .... sorry I got the error message wrong π€¦ββοΈ
It's reader timeout
Ah
Unfortuantely this is really hard to debug without being physically present
Here's the problem with this specific error
- The error says the reader did not respond back to the API
- The reader still could have received the command and initiated card collection
- At that point, the reader has the card details saved locally, which is why you see it in the
/confirmcall
Ultimately, the error is just saying the reader wasn't able to send a response within the timeout window
Yikes
OK
So how can I recreate this locally? For testing purposes
My use case is a business cafe POS, which are typically in basements. Hence the bad WiFi
I think you would have to send the API request but disconnect the reader (in the router UI) before you read the card
What does router UI mean?
I mean you log into your WiFi router admin panel and kick the reader off your network before you scan the card
OK so the steps would be:
- Initiate
process_payment_intent
- Disconnect terminal from WiFi
- Tap card
- Reconnect terminal
And that should recreate the scenario I'm seeing?
I think so. You should see the same error response from process_payment_intent.
And then the /confirm, is that coming from my server? Or from the terminal itself?
Has to be my server, right?
Oh no, its the reader
That comes from the reader
Yup
You can see it in the User Agent header
{"client_type":"ANDROID_READER","client_version":"2.27.7.0","device_uuid":"WSC513208043810"}
So why is that confirm request coming from the terminal?
"confirmation_method": "automatic", is this why?
Yup. You didn't specify a confirmation behavior and for that API version we will default to automatic confirmation
I think for my application I don't want to change that
But OK this is making a lot more sense now. I now understand why Stripe is processing the payment but my app is not
My app gets the timeout error back from Stripe and works from there
Is there a way to poll the terminal to check/confirm if it got the card details?
Yes there is! In fact, I wrote that into my test integration to retrieve a reader status
But you're right. The part that makes poor networks an issue with terminal is that we don't know what is going on with the terminal reader if we don't get a response
The request to do something on the reader may have succeeded or it may not
We just don't know
Yeah...
When I first built this integration, server-driven was considered the recommended integration
Is a native integration (iOS or Android) any better?
My first build was the JS integration, but with poor WiFi I had all kinds of problems
Server-driven has been better. But still has issues
Oh yeah, that gets really bad
Native iOS and Android integrations make sense for Bluetooth readers but I haven't done any testing with Smart readers like the Wise POS E or the S700
Oh right those are Bluetooth
Can these potentially work with Bluetooth?
The Wise POS I mean
Actually I guess it doesn't matter. I use a web-based solution right now. I see the Bluetooth integration requires an SDK
Going back to an earlier comment you made about the duplicate requests, do you think that's related to the bad WiFi? Or is that an issue with how I built my app?
Honestly it depends. I don't have enough information on my end. I think the delay in updating the reader's display is 100% related to poor Wifi
Those basements need to install some mesh routers
Preaching to the choir...
Clients won't even let us on the guest wifi due to security measures, so we use mobile hotspots
But anyway
This has been really helpful
Thank you for the insight
Oh wait
Actually
Would you be able to check on something else for me?
Sure, what's up?
I had a terminal get stuck in Terminal events connectivity: Connecting...
I chatted with someone on here
I could find the conversation if necessary
But they said I should write into support for further help
I did that
And it's been weeks
Did you reach someone who said they were an engineer?
All I get is once a week saying "we are looking into it"
Through support, no
Someone named Anushka
Unfortunately, we may be waiting on product engineering teams. However, I recommend creating a new case that will route to us more quickly
Let me give you the link, one sec
Hello @muted charm, we have sent you a direct message, please check it at https://discord.com/channels/@me/1317204075913154603
- πThe message has instructions on how to open a direct support case with our Developer Support team, in order to help you more effectively.
Oh wait. I was chatting with you! haha
That link looks like I'm DMing the Stripe Bot
Is that right?
Oh
Second link
Got it
The StripeBot should h ave DM'd you with instructions on how to create a case that will be accelerated to us
You'll need to restate your case and provide us all the details again (sorry) but it should get handled faster
Okay nope I see it
That's where you start.
Sweet
You have been so helpful! It's so great to be able to chat with devs on here who can actually answer questions
Okayt I found your old case
This whole server is amazing
Amazing. Is it being worked on? Or ignored?
It is being worked on
Great! I'm glad we got back to you on that
I didn't reach out to support. I think this was just an automated message
At least they know it's a problem and are working on it
Well if it was something we recognized on our end, we can sometimes identify the impacted accounts and send out communications about the issue