#mordil
1 messages · Page 1 of 1 (latest)
They're running firmware version 2.12.2.3 on their readers
Location ID is tml_ErrAEglKhWUFIo
Reader Serial Numbers
WSC513208040004WSC513105012537WSC513105012538
We've only been able to reproduce mid-transaction, the iOS device losing internet connection (going into airplane mode)
Though, it seems to be very consistent for this user
They're claiming it's like every transaction
But this is the only user out of hundreds that's reported this so far
I do see some reports of terminal_didReportUnexpectedReaderDisconnect in our Sentry reports for this user
👋 hopping in here to take a look
They're running a version of our app that shipped with the following Stripe SDKs:
- (via Cocoapods) Stripe 23.8.0
- (via SwiftPM) Stripe Terminal iOS 2.20.0
They're saying it's happening on all 3 of those readers?
It'd be really helpful if I could get a specific Intent ID that they said failed midway through - or even specifics on which reader and in which time frame they experienced this so I can narrow down the logs
Supposedly, yes. All 3 readers
Let me see if our backend is capturing intent IDs in logs somewhere, otherwise we don't have that.
I'll try to get a timestamp of a reproduction, and which reader
👍
@woven ocean just checking in here - did you get anymore details?
No, I'm waiting for the interview w/ the user to be scheduled - sorry. It's going to be a bit
No worries! This thread may get closed (we close threads if it's been a while with no update) - but once you have all the details feel free to ask again in the main channel
I just sat with them over a call to walkthrough what they're seeing, and to ask them about "when" they saw errors with the transactions
They said "literally every transaction would freeze the reader" and "all the readers".
However, while trying to connect to one while over the call, our app wasn't able to find the registered reader
I verified they were using the correct reader serial #, and we confirmed they were also correctly registered, and that we passed the location ID to stripe.
The stripe SDK was returning back a count of 0 available readers to connect to.
We also verified that both their iOS device and Wise POSe were on the same Wifi Network
This was between 1630 and 1705 US Central
The reader they were testing with was WSC513208040004
They've been using these readers "for about a year now" is what they said, but they didn't start seeing issues until around April - which coincides with when we shipped the latest version of the Stripe SDKs
(we do SDK updates once every quarter, at the start of the quarter)
Their network is a bit "nonstandard" in that they have access points scattered through their building to extend the Wifi network range, and they have multiple wifi networks to constrain different categories of devices to (they're a VR company, and backpacks talk to servers via wifi on a separate network)
Okay I'm looking at the most recent error logs for that reader (WSC513208040004) and I'm a little confused. You mention an iOS integration but the SDK that is communicating with that reader is the JavaScript SDK
And I do see many dropped connections occurring over the past 24 hours for this reader.
I tried connecting via a web client on a separate network
We didn’t get an error while connecting - it’s technically a happy path. It’s just the SDK returned 0 reader options when starting a manual scan
Yeah, we’re seeing them too, and we’re not sure why they have been dropping connections
Given the "nonstandard" nature of the wifi networks, I think it would be expected. They are likely having semi-frequent network dropouts and those are happening to hit when the SDK is trying to ping the reader.
But you are saying these connection issues have been occurring more frequently since April? Is there any chance they modified their network around that time?
Also what does "serrated network" mean in this case?
They say nothing has changed with their network.
It was a typo of ‘seperate’
I guess the big question right now is: what conditions would cause the iOS SDK to not be able to find readers to connect to?
According to the logs the only SDK connecting to this reader was the JavaScript SDK, so I'm not sure how the iOS SDK comes in here.
🤔
But in all likelihood this is something that we could only debug if you physcally had the reader with you and were directly connected to the network in question. I have some guidelines on how to troubleshoot but you will need to be on the same wifi network as the reader
We're calling discoverReaderManually(delegate:configuration:) and we're getting the delegate method terminal(_:didUpdateDiscoveredReaders:) invoked with 0 readers passed to us
But the reader was right next to the iOS device, and we confirmed both before & after that both devices were on the same Wifi network
and we've confirmed that the reader is registered to this location, and our app doesn't even let us get to this point if we don't get a location back from our BE, so all of the configuration is "correct"
The location wouldn't matter if the WiFi network drops the connection to the reader.
Your POS needs to be able to connect directly to your Terminal reader. Here is how you can check on the connection depending on the device.
https://stripe.com/docs/terminal/readers/bbpos-wisepos-e#reader-has-ip-address-and-can-communicate-with-stripe,-but-not-with-your-point-of-sale-application
https://stripe.com/docs/terminal/readers/verifone-p400#reader-has-ip-address-and-can-communicate-with-stripe,-but-not-with-your-point-of-sale-application
Readers use a hostname such as
10-0-0-5.abc123.device.stripe-terminal-local-reader.net where 10-0-0-5 represents the hyphen-delimited local IP address of the reader and abc123 can be any random string. The exact string typically is not relevant, but you can get it from the base_url on each result from discoverReaders().
From the POS device, the following commands are informative diagnostics:
1/ nslookup 10-0-0-5.abc123.device.stripe-terminal-local-reader.net
This needs to resolve to the local IP address (eg 10.0.0.5). If it does not, it is likely that your router or other DNS provider is using DNS Rebinding protection.
2/ ping 10-0-0-5.abc123.device.stripe-terminal-local-reader.net
This needs to be able to connect to the reader. If it cannot, it is likely that the network is preventing device-to-device direct connections as a security measure.
We just found an issue on our end that may have affected it - we have multiple locations registered to this user, and we may be sending the wrong location ID to the SDK
So it may be that we were sending the wrong location.
None of our logs were capturing that, that's our bad
Got it, yes that could be part of the issue. I think there is still a decent chance their network is dropping the connection and it's just bad luck that it is occurring just as they are trying to use the reader. But definitely review the location mapping and see if that improves the reliability
It's just curious that they may be losing connection exactly when they're doing a transaction, every single time - according to them
But that very well may be their own unique network setup. We'll investigate.
Do you have other guidelines / help for troubleshooting their setup other than the docs linked above?
Given the issues you are encountering I think the steps outlined above are your best bet to determine if the networking is the souce of the problem
Yeah, thanks.
We solved the connection issue, and we're back to debugging the transaction failing & the reader freezing. We may have to do an on-site debugging
We're not even seeing on the Stripe dashboard the transaction being started - there's no record of it at all. Failed, Captured, etc.
That is one of the more difficult parts of the JS integration, the need to be on the same wireless network for debugging.
This is iOS, the JS is a misdirection as I was trying to connect via a separate client earlier
We've got 1 reader correctly processing transactions just fine, and another not - I'm getting the serial #s of them
Both devices are on Version 2.12.2.3
Ok... now it seems like both are working
Yeah, this is sounding very suspiciously like network issues.
Thanks for talking through this...
We'll try doing deeper digging on their network