radu-m_api

[umbral birch]

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

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

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

• radu-m_api, 2 hours ago, 42 messages

[vernal prawn]

Does this process reveal any errors to your on any surface? Or is this a silent failure?

[thin torrent]

Hello, I started the conversation with another user, and I provided steps to reproduce and the environment I am working with.
The gist of it: the Stripe Terminal SDK v4.7.3on a v2.41.2.0 Stripe S700 Devkit doesn't go online after the device itself is connected to Wi-Fi.
Your colleague suggested I upgrade to Stripe Terminal SDK v5.x and try that way.

I upgraded, went through the documentation at: https://docs.stripe.com/terminal/references/sdk-migration-guide?terminal-sdk-platform=android&lang-android=java#migrate-to-version-500 , but now Offline Mode doesn't work at all.
The reader gets connected after I start my app, but after the first token retry it prints the attached error in logcat.

then it disconnects and keeps trying to get a connection token. This fails because the device is offline.

[lost phoenix]

hi there, I'm taking over for synthrider as they had to step away. just to clarify, was offline mode working before you upgraded the SDK? has the error changed at all between versions?

[thin torrent]

Yes, Offline is working fine with Stripe Terminal SDK v4.7.3.
We have it working in production for almost 2 years now.

I tested on my DevKit earlier today, with v4.7.3 that disconnectReader doesn't happen (the error I attached above)

[lost phoenix]

have you isolated which part of the code is throwing that error? if so, can you share the code?

[thin torrent]

By the looks of it, Stripe asks for a connection token in order to get the reader connected.
The device is offline, and the token cannot be retrieved.
From my understanding, Stripe should use an offline token, basically the last token that was retrieved when the device was last time online.

It looks like this doesn't happen with v4.7.3:

With v4.7.3, Stripe uses the offline token:
StripeTerminal com.goodbox I class=RemoteReaderResourceRepository message="Network status offline, using offline token"

[lost phoenix]

I'm trying to understand which part of the code is throwing this message: "Cannot get token: account ID not set"

[thin torrent]

that is the Stripe code:
2026-04-21 17:06:39.503 12422-12588 StripeTerminal com.goodbox W class=AndroidLocalSessionTokenRepository message="Cannot get token: account ID not set"

In our integration, I implemented a class: TokenProvider implements ConnectionTokenProvider that provides a connection token inside this method: fetchConnectionToken
This is per the Stripe documentation here: https://docs.stripe.com/terminal/payments/setup-integration?terminal-sdk-platform=android&lang-android=java#connection-token-client-side

[lost phoenix]

and you're sure the reader connects initially? I'm seeing some suggestion that this error occurs if the reader has never successfully connected for this account (which means the account ID never gets persisted). can you try connecting with a different network, perhaps a mobile hotspot?

[thin torrent]

That class retrieves a token (if device online) and provides it to the callback.
In this case, the fetchConnectionToken is called multiple times, through a retry mechanism, and after the second retry the reader disconnects:

The last line is from our code, but all the others are from Stripe.

It might be that with v5.3.0, the reader never connects, despite the logs showing it's disconnecting the reader (implying it was connected? )

With v4.7.3 (device offline - not connected to Wi-Fi):
StripeTerminal com.goodbox D class=ProxyTerminalListener message=onConnectionStatusChange(DISCOVERING)
StripeTerminal com.goodbox D class=ProxyTerminalListener message=onConnectionStatusChange(NOT_CONNECTED)
StripeTerminal com.goodbox D class=ProxyTerminalListener message=onConnectionStatusChange(CONNECTING)
StripeTerminal com.goodbox D class=ProxyTerminalListener message=onConnectionStatusChange(CONNECTED)

With v5.3.0 (device offline - not connected to Wi-Fi):
StripeTerminal com.goodbox D class=ProxyTerminalListener message=onConnectionStatusChange(DISCOVERING)
StripeTerminal com.goodbox D class=ProxyTerminalListener message=onConnectionStatusChange(NOT_CONNECTED)
StripeTerminal com.goodbox D class=ProxyTerminalListener message=onConnectionStatusChange(CONNECTING)
StripeTerminal com.goodbox D class=ProxyTerminalListener message=onConnectionStatusChange(NOT_CONNECTED)

[lost phoenix]

would it be possible for you to downgrade back to 4.7.3 and test again? we want to make sure this is isolated to the SDK version and isn't an integration issue

[thin torrent]

When you say downgrade, you mean try with a code version that uses 4.7.3 as dependency, and uses the 4.7.3 specific SDKs (that were refactored in 5.x), right? I can't just downgrade the dependency to 4.7.3 and test without changing the code to use the 4.7.3 SDK, it won't compile.

[lost phoenix]

got it, does any part of your code call clearCachedCredentials anywhere? or do anything else that might clear the local cache of the account ID?

[thin torrent]

Yes, I am calling this in 3 places:

• upon Terminal.getInstance().discoverReaders, new Callback.onFailure: basically if the reader failed from being discovered
• upon Terminal.getInstance().disconnectReader, new Callback.onSuccess: basically if the reader disconnect was succesful
• upon force resetting the reader connection (through an end-user button press), right before performing another reader discovery