#mordil

1 messages · Page 1 of 1 (latest)

grand cryptBOT
woven ocean
#

They're running firmware version 2.12.2.3 on their readers

#

Location ID is tml_ErrAEglKhWUFIo

#

Reader Serial Numbers

  • WSC513208040004
  • WSC513105012537
  • WSC513105012538
west cedar
#

Hey there

#

Thanks for the info, let me take a look

woven ocean
#

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

opaque turret
#

👋 hopping in here to take a look

woven ocean
#

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
opaque turret
#

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

woven ocean
#

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

opaque turret
#

👍

opaque turret
#

@woven ocean just checking in here - did you get anymore details?

grand cryptBOT
woven ocean
#

No, I'm waiting for the interview w/ the user to be scheduled - sorry. It's going to be a bit

opaque turret
#

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

crystal sonnet
#

Hi 👋

#

can you summarize what the current state of your question is?

woven ocean
#

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

grand cryptBOT
woven ocean
#

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)

crystal sonnet
#

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.

woven ocean
#

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

woven ocean
crystal sonnet
#

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?

woven ocean
#

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?

crystal sonnet
#

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.

woven ocean
#

🤔

crystal sonnet
#

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

woven ocean
#

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"

crystal sonnet
#

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.

woven ocean
#

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

crystal sonnet
#

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

woven ocean
#

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?

crystal sonnet
#

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

woven ocean
#

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.

crystal sonnet
#

That is one of the more difficult parts of the JS integration, the need to be on the same wireless network for debugging.

woven ocean
#

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