#radu-m_api

1 messages · Page 1 of 1 (latest)

halcyon isleBOT
#

👋 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/1499015001749327913

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

old escarp
#

hi there!

#

can you share the exact error you get?

agile lodge
#

Hello

#

The offline reader doesn't get disconnected, even after the token refresh times out.
Because of that, the device remains offline and doesn't take transactions online, nor does it send the offline stored transactions.

This is a change compared to Stripe Terminal Android SDK, v4.7.3 that we were using before.
In that version, once the device went online (after being offline), the reader was disconnected immediately.
Then we got the same timeout, but because the reader was disconnected, our app attempted to re-discover and re-connect to the handoff reader.

halcyon isleBOT
balmy rivet
#

Hey! Taking over for my colleague. Let me catch up.

#

Let me catch up here and better understand your integration. You are using Apps on device with an S700 right ?

agile lodge
#

Yes

balmy rivet
#

Why the need for the Connection token in this case ?

agile lodge
#

Are your referring to this section? :
In version 5.0.0 of the Android SDK, you can use the easyConnect method to combine reader discovery and connection into a single API call to simplify integration. See the SDK migration guide for details.

balmy rivet
#

That's an new method to combine discovery and connect to the reading on a single call

#

the device waits for ~3 minutes to retrieve the token from the backend
I'm referring to this part, what token and what backend are you referring to here ?

agile lodge
#

We are using Stripe Connect.
I am now trying to find the Stripe documentation page where the reader connection token process is described.

balmy rivet
#

Regardless of using Connection here, if you want to discover and connect your apps-in-device to the host S700 reader, you need to follow the guide I shared above

agile lodge
#

The guide you provided is probably correct, but from what I can tell, is not enough to fully configure and initialize Terminal.

balmy rivet
#

This isn't an apps- on device. Can you first confirm what integration are you doing here?

#

So you have an Android device (acting as a Point of Sales) and a reader S700 ?

agile lodge
#

Hmm, I was under the impression that this is what we are using: Apps-on-Devices. We have our own Android app running on an S700, integrating with Stripe Terminal SDK.
By looking over the documentation you provided, this is what we have: Point of sale app on a Stripe smart reader

balmy rivet
agile lodge
#

OK, let's then suppose it's not Apps-on-Devices, but a regular Android integration.
What you're saying is that this Android integration would require a connection token, but it's intended to be used when you have your own Android device, and a separate Stripe Reader?

balmy rivet
#

OK, let's then suppose it's not Apps-on-Devices, but a regular Android integration.
Sorry, we need to confirm what integration you are using, because these are completly different integrations.

#

What you're saying is that this Android integration would require a connection token, but it's intended to be used when you have your own Android device, and a separate Stripe Reader?
Yes you need to generate a connection token if you have an Android device that will tries to connect to a S700 reader (via bluetooth or internet)

agile lodge
balmy rivet
#

you don't need a locationId to connect to a reader. You get a connection token from your backend, that can be used for readers in any locations.
That's for setting the terminal SDK, but when you connect to the reader you'll need a location Id

#

What guide are you following to connect to a reader ?

agile lodge
balmy rivet
#

You are mixing two integrations here. This isn't correct. You should follow the same integration flow from the begining to the end.

#

If you are doing apps-on-devices then you need to use the apps-on-devices flow.

agile lodge
balmy rivet
agile lodge
balmy rivet
balmy rivet
#

These are two completly different integrations.

agile lodge
#

So how do you setup Terminal here, with Apps-on-Devices?

image.png
balmy rivet
agile lodge
#

OK, so basically you're taken to the same page where you started 🙂

#

Let's go with Apps-on-Devices. Since when you discoverReaders, the locationId can be null (so no locationId), where exactly are you required to provide it?

balmy rivet
#

Actually try to pass it null and see if that works, but usually you should pass the locationId, I'm hesitating here when you shared that the Java SDK is accepting nullable value.

#

If it wokrs without passing a location Id then that's even better for use case.

agile lodge
balmy rivet
#

Yes

agile lodge
#

Out of your knowledge, besides the discoverReaders(@Nullable locationId), is there any other place where you actually need the locationId present?

balmy rivet
#

once the reader si connect you no more need to provide the locationId

agile lodge
#

I just tried following that guide (https://docs.stripe.com/terminal/features/apps-on-devices/build?lang-android=java#setup-app), and the first step is:

How am I supposed to initialize Terminal using the Apps-on-Devices integration? If I call "discoverReaders" (https://docs.stripe.com/terminal/features/apps-on-devices/build#discover-and-connect-a-reader) without first calling Terminal.init(...), I get an exception: Caused by: java.lang.IllegalStateException: init must be called before attempting to get the instance

image.png
balmy rivet
#

Ah so sorry, the doc got updated the setup part is now the same for Android and Apps on devices 🤔 , let me check further ..

#

I know this is confusing the Apps on device and the Android integration, there are some part are commun and others are different

agile lodge
#

Yes, indeed, very confusing 🙂

#

that's why probably I went down the road of Apps-on-Devices, but then still implemented my own ConnectionTokenProvider

#

OK, so how I did it, to ensure I am using the Apps-On-Devices integration, is:
Terminal.init( mainActivity, LogLevel.VERBOSE, new AppsOnDevicesConnectionTokenProvider(), stripeContainer, offlineListener);

with AppsOnDevicesConnectionTokenProvider imported like: import com.stripe.stripeterminal.appsondevices.AppsOnDevicesConnectionTokenProvider

balmy rivet
#

Yeah actually you need to implement your own connection_token provider (like you were doing initially)

#

Something like this:

class CustomConnectionTokenProvider : ConnectionTokenProvider {
    override fun fetchConnectionToken(callback: ConnectionTokenCallback) {
    }
}
#

I checked your reader's error in the past 7 days and I'm seeing the error
com.stripe.stripeterminal.external.models.TerminalException: Execution error while retrieving connection token
happened only one time

#

is this accurate ?

agile lodge
#

Yes, because I just now switched from my own ConnectionTokenProvider implementation to the AppsOnDevicesConnectionTokenProvider

#

Up until this point, I was having other issues with the integration, as mentioned in my initial message that started this conversation.

#

Now that I tried using the com.stripe.stripeterminal.appsondevices.AppsOnDevicesConnectionTokenProvider, I am bumping into this error I pasted earlier: com.stripe.stripeterminal.external.models.TerminalException: Execution error while retrieving connection token and you found for this DevKit logs.

#

Now, might it be that our app (com.goodbox) is not enabled for Apps-On-Devices?

balmy rivet
#

Now, might it be that our app (com.goodbox) is not enabled for Apps-On-Devices?
No no you should use your custom token provider

#

You need to switch back sorry for the confusion initially.

#

I'm trying to understand the inital issue now, your integration seems good so far (the initial one)

#

Sorry as I don't have a full vision on your full code base I'm not able to 100% understand your stack.

agile lodge
#

Alright, that's a fair point, kind of difficult to understand each individual implementation for the many clients that use Stripe Terminal.

balmy rivet
#

Now back to the connection token issue, you are facing this all the time ? because as I mentioned above I'm noticing this happened only once in the past 7 days

agile lodge
#

So, back to my original issue:

  • I have this device offline.
  • When it starts, Stripe asks for a connection token, but because there's no internet connectivity, I call connectionTokenCallback.onFailure(new ConnectionTokenException(errorMessage));
  • I bring it online
  • The device asks for a connection token (which is retrieved from the backend using gRPC)
  • Because the device was offline when it was powered-on the initially, the call to our backend stripe.api.rsm.goodbox.com to retrieve the connection token (step 2 above) was cached in the Android negative DNS cache. This means that it attempted to call that FQDN, failed, and cached the failure.
  • Now since the device is online, calls to stripe.api.rsm.goodbox.com will not go through until this negative DNS cache entry is invalidated. This takes about 3 minutes.
  • After 3 minutes, the call to the backend goes through successfully and I return a valid token to my ConnectionTokenProvider and call connectionTokenCallback.onSuccess(token);
  • Then I get this error message :
📎 message.txt
#

This is with Stripe Terminal Android SDK v5.4.1.
With v4.7.3, once the device was connected to the internet, the (offline) connected reader would get disconnected.
For 3 minutes, the reader would stay disconnected, and when a token was eventually retrieved, our app would see that the reader is disconnected and attempt to re-discover and re-connect to the reader.

Because with v5.4.1 the reader doesn't disconnect after going online, and eventually throws this TimeoutException, the device/reader stays offline even if the device is connected to the internet. Another side-effect is that the stored offline transactions are not forwarded out.

balmy rivet
#

So if you wait 3min before going online from the last offline attempts, you won't get the issue ?

agile lodge
#

The only solution we have right now is to restart the device, or let the user press a "Reset reader connection" button which in turn disconnects the reader, performs reader discovery and re-connects to the reader.

balmy rivet
balmy rivet
agile lodge
agile lodge
halcyon isleBOT
agile lodge
#

In the meantime, do you know of any changes that might've happened in the Stripe Terminal Android SDK around how the reader disconnects or doesn't disconnect when the device goes online?

agile lodge
#

Can you see it in the reader logs (in Sentry, I presume) on your side?

#

@balmy rivet - are you still around?

balmy rivet
#

Yes yes I'm still with you

agile lodge
#

phew, I thought this conversation will be closed and then I'll have to explain everything to someone else 😆

balmy rivet
#

before the gRPC channel is READY
is this happening with an HTTP endpoint too ?

#

the call to our backend stripe.api.rsm.goodbox.com to retrieve the connection token (step 2 above) was cached in the Android negative DNS cache. This means that it attempted to call that FQDN, failed, and cached the failure.
You call your backend via gRPC here right ?

agile lodge
agile lodge
#

Is there a way I might catch this TimeoutException and go through the process of re-discover and re-connect for the reader?

balmy rivet
balmy rivet
#

Do you have currently a try catch block for all runtime exceptions ?

agile lodge
# balmy rivet This seems something specific to gRPC, I don't think you'll face the same issue ...

Probably not, I didn't try to actually get a token through HTTP, but I tried to connect to my backend using HTTP, and the calls went through just fine.
The fact that my gRPC channel waits for 3 minutes until the connection to the backend is established is one problem, indeed.

This problem was mitigated by the fact that the reader disconnected immediately after the device went online.
This is no longer the case, with v5.4.1. The reader just stays connected, offline.

balmy rivet
#

This is no longer the case, with v5.4.1. The reader just stays connected, offline.
Yeah and I think this is aligned with the fact that you can accept offline payments with the reader even if it's not connected to the Wifi

agile lodge
balmy rivet
#

because the status connect/not connected isn't for the WIFI/connectivity, it's a connection status between your android app and the reader

#

The fact that my gRPC channel waits for 3 minutes until the connection to the backend is established is one problem, indeed.
I think you need to fix this, as this is particular thing to your integration

#

It shouldn't happen normaly, when the reader tried to fetch another connection token it won't get a cached response.

agile lodge
#

I spent days on end trying to get to the bottom of why the gRPC channel takes this long to get through to the backend.
I implemented a custom DNS resolver that would avoid going through the FQDN and would resolve the IPs using an external DNS service (8.8.8.8 - Google DNS).
Then I am creating the gRPC channel using the actual IP.
However, the InetAddress implementation in Android still attempts to get the FQDN associated with the IP, somewhere in its implementation.

#

Hence I'm back to square one with these 3 minutes.

#

Ok, I will have to go get my son from the kindergarden.
Is there a way we could continue this conversation, perhaps through the Support email, in order to get to the bottom of:

  • Where do I need to catch the TimeoutException Terminal throws upon waiting for 3 minutes to get the token?
  • Why was Terminal SDK v4.7.3 disconnecting from the reader upon device coming online (connected to Wi-Fi) and v5.4.1 doesn't disconnect from the reader?
balmy rivet
#

I think you need to find a solution for the 3 min issue here

#

Why was Terminal SDK v4.7.3 disconnecting from the reader upon device coming online (connected to Wi-Fi) and v5.4.1 doesn't disconnect from the reader?
Probably this is a recent change. And I as said previouslt this seems aligned because you can accept offline payments.

#

So the reader is considered conencted to the Android App (not to the wifi)

halcyon isleBOT