#johio_api

1 messages · Page 1 of 1 (latest)

lost kilnBOT
#

đź‘‹ 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/1281689343114874983

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

hallow stone
#

Hello
It is possible that the network you've switched to has strict DNS settings which block certain requests to Stripe.

We have a doc here around network requirements: https://docs.stripe.com/terminal/network-requirements#smart-readers

followed by a troubleshooting guide: https://docs.stripe.com/terminal/network-requirements#troubleshooting

I'd recommend giving those a read and checking if updating DNS servers help. You would also want to make sure that Stripe IPs/Domains are whitelisted: https://docs.stripe.com/ips#stripe-terminal-domains

heady hearth
#

So just to make sure that these are the issues I want to provide additional information. Here is the initialize terminal code with console logs to debug which step is failing.

(async function initializeTerminal() {
  try {
    console.log('Starting reader discovery...');
    const discoverResult = await terminal.discoverReaders({
      method: 'internet',
    });

    if (discoverResult.error) {
      console.error('Failed to discover readers:', discoverResult.error);
    } else if (discoverResult.discoveredReaders.length === 0) {
      console.error('No available readers.');
    } else {
      reader = discoverResult.discoveredReaders[0];
      console.log('Found Reader')
      console.log(reader);
      const connectResult = await terminal.connectReader(reader);

      if (connectResult.error) {
        console.error('Failed to connect to reader:', connectResult.error);
      } else {
        console.log('Successfully connected to reader:', connectResult.reader.label);
        $('#pinpadInstructions').text(gon.check_out);
        $('#pinpadInstructions').css('background-color', 'rgba(0,171,238,1.0)');
        $('#pinpadInstructions').prop('disabled', false);
      }
    }
  } catch (error) {
    console.error('Error connecting to reader:', error);
  }
})();  // Immediately invoked async function

Now in the console I see

'Starting reader discovery'
'Found Reader'
{id: 'tmr_FtgQmAE9EQDbd0', object: 'terminal.reader', action: null, base_url: 'dwdxfzkcthqb645df47b.device.stripe-terminal-local-reader.net', device_sw_version: '2.25.3.0', …}
Failed to connect to reader

This means that my device discovered the reader and you can see the reader in the object 2 lines above, but failed to connect to it. Do you think the problem is the strict DNS still?

hallow stone
#

Yeah I don't believe this is an integration issue. It "could" be a DNS/firewall issue.

The fact that the only thing you changed in your case was your network and your integration stopped working, likely confirms some sort of networking related issue.

heady hearth
#

ya that's what I thought too, however, since the reader is discovered by my device that means the dns is allowing my device to find another device in the network. I thought that ruled out the case for a dns restriction being the problem. What do you think?

hallow stone
#

Hmm yeah, that's possible.

Could you try following and confirm if you're seeing the expected values:

On your point of sale device, try resolving 10-42-42-42.test.device.stripe-terminal-local-reader.net to an IP address. That hostname should resolve to the IP 10.42.42.42. If it resolves to a different IP, or if DNS resolution fails, configure your point of sale device to use Cloudflare DNS servers (1.1.1.1 and 1.0.0.1) or Google DNS servers (8.8.8.8 and 8.8.4.4) and try again.

Check your router’s configuration to see if connections between wireless (Wi-Fi) clients and wired (Ethernet) clients are being blocked.

Make sure you can ping the Terminal reader’s IP address from your point of sale device.

heady hearth
#

is this what I want?

hallow stone
#

yup, this rules out DNS being an issue.

#

Is POS and the reader connected via wifi? Do they have the same subnet assigned?

heady hearth
#

let me double check

#

yup both 255.255.255.0

hallow stone
#

Is your network using IPv6? That's not supported

heady hearth
#

no I think it has both, from running ifconfig on my mac I can see my active interface en0 (my main Wi-Fi network interface) has an IPv4 address: inet 172.35.xxx.xxx netmask 0xffffff00 broadcast 172.35.xxx.xxx and ipv6 address: inet6 fe80::c2fxxxx:xxxx:7475%en0 prefixlen 64 secured scopeid 0x6

#

but I think it is being configured using dhcp

hallow stone
#

Gotcha. Can you check what IP is the reader getting?
I suspect DHCP is assigning an IPv6 address which is causing this issue

heady hearth
#

ya the ip address is 172.35.100.142

#

also pinging the device via ip address from my laptop is getting the results expected:

ping 172.35.100.142
PING 172.35.100.142 (172.35.100.142): 56 data bytes
64 bytes from 172.35.100.142: icmp_seq=0 ttl=64 time=34.146 ms
64 bytes from 172.35.100.142: icmp_seq=1 ttl=64 time=254.269 ms
64 bytes from 172.35.100.142: icmp_seq=2 ttl=64 time=262.088 ms
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
64 bytes from 172.35.100.142: icmp_seq=3 ttl=64 time=2225.930 ms
64 bytes from 172.35.100.142: icmp_seq=4 ttl=64 time=1224.283 ms
64 bytes from 172.35.100.142: icmp_seq=5 ttl=64 time=222.386 ms
64 bytes from 172.35.100.142: icmp_seq=6 ttl=64 time=43.786 ms
64 bytes from 172.35.100.142: icmp_seq=7 ttl=64 time=71.660 ms

hallow stone
#

Hmm

heady hearth
#

ya in the network tab on my browser its the jackrabbit service thats failing. the request url:

https://172-35-100-142.dwdxfzkcthqb645df47b.device.stripe-terminal-local-reader.net:4443/protojsonservice/JackRabbitService

with the following payload:

{id: 1725651956307, service: "JackRabbitService", method: "activateTerminal",…}
content:"eyJwb3NfYWN0aXZhdGlvbl90b2tlbiI6InBzdF90ZXN0X1lXTmpkRjh4T1VWdWFIRktXalYxV0dKNU1XMURMREZ3TW1SR1lsWktjVW8xZFdwNGNHMXdlVWhzV0c5NFJqWkpXbmhzYm5RXzAwYmQ5SzZvOUwiLCJzdG9yZV9uYW1lIjoiZW1wdHkiLCJwb3NfZGV2aWNlX2lkIjoicG9zLTZxdTI3cjExNXJoIiwicG9zX3NvZnR3YXJlX2luZm8iOnsicG9zX3R5cGUiOiJwb3MtanMiLCJzZGtfdmVyc2lvbiI6IjEuMy4yIn19"
device_info:{device_class: "POS", device_uuid: "pos-6qu27r115rh", host_os_version: "Mac OS",…}
id: 1725651956307
method: "activateTerminal"
parent_trace_id: "81493983"
service: "JackRabbitService"
session_token: ""
version_info: {client_type: "JS_SDK", client_version: "1.3.2"}

hallow stone
#

Fwiw, you were running nslookup for incomplete hostname
nslookup dwdxfzkcthqb645df47b.device.stripe-terminal-local-reader.net

instead of
https://172-35-100-142.dwdxfzkcthqb645df47b.device.stripe-terminal-local-reader.net

The latter should resolve

#

If you switch the network on the reader and POS to let's say a mobile hotspot, it works right?

heady hearth
#

Let me try

#

well I mean when I was testing at home it was working

#

so it should work

#

yes I verified it works

hallow stone
#

I'm looking at your reader logs on our end and it looks fine..

Can you try reconnecting to the work network?

heady hearth
#

ok both my pos device and the reader are connected to the work network

hallow stone
#

Try running connectReader again

heady hearth
hallow stone
#

This is tricky. So what's happening here is:

  • When the reader is connected to a network, it sends us let's say a "heartbeat" every few seconds. This way our infra can track reader state. Based on this heartbeat, we generate the hostname

  • When the SDK calls discoverReaders, we return the available readers (which also contain the hostname)

  • When the SDK calls connectReader , the POS tries to talk to the reader directly using the hostname returned in the object.

The POS and Reader are connected to the network and most likely can talk to Stripe just fine. The issue arises when the POS tries to talk to the reader using the local hostname..

#

Based on the tests we've done above, DNS is working fine.. POS is able to ping the IP that the reader is assigned as well...

#

Oh wait, based on the logs it looks like the reader is continuously disconnecting and reconnecting with the wifi..

#

it seems "online" as it sends a "heartbeat" when it reconnects but then disconnects causing the connectReader to fail...

heady hearth
#

that might be because I disconnected to the wifi and connected to my phone to show a demo just now sorry

#

it is connected to the wifi

hallow stone
#

No, I'm still seeing logs that the reader is scanning for wifi..

#

like with current timestamp (so it is likely doing that in the background)

heady hearth
#

hmm okay, I will leave it at that for now and continue the thread on Monday if thats okay with you