#kev3200-terminal-android

1 messages · Page 1 of 1 (latest)

cunning raven
terse dragon
#

(Sidenote: first time seeing discord threads in use, useful to unclog main chat)

cunning raven
#

yeah threads can be helpful for this. Give me a few minutes to dig into this

terse dragon
#

Lmk if you need more context on the issue

cunning raven
#

How do you initiate Terminal? Like from what I can see in our sample apps you define a TokenProvider that can fetch a ConnectionToken and it should automatically get a new one on expiration

#

(sorry I'm less familiar with this and asked my team but no one has replied yet)

terse dragon
#

I'll check our integration, one second sorry

#

Yes we do have a /connection_token endpoint on server side that the client makes request to. This is working, I can see console logs each time a token is received. It seems to be fetching connection tokens perfectly fine during reader/discovery phase, but (sporadically) errors with 401 api_key_expired usually during the payment intent phase

#

So it's just odd to me that it would be working fine with the readers but then error later in the same flow.
Question: Is the connection token only used to connect to the terminal reader or also used for all the requests to Stripe API?

river veldt
#

@terse dragon

but (sporadically) errors with 401 api_key_expired usually during the payment intent phase
do you think that is happening a long time after? (i.e. you suspect the connection token expiring?)

or is it happening possibly sooner too? like minutes after you create the ConnectionToken for a new Reader connection?

terse dragon
#

I would say it happens more frequently after a longer period of time, but also sometimes within 5-10 or so minutes

cunning raven
#

We should be able to prove that quickly with the PaymentIntent id if you have that

terse dragon
#

hmm let me look on dashboard to try and find it

#

I don't see any of the "failed" purchases with that error. I guess the payment intent was never created right since the api call failed?

#

also if helpful, we're letting the SDK handle all the payment intent creation/payment_method/confirmation status updates, not going through our backend, I believe it just calling Stripe API directly

cunning raven
#

talking with a few team members they don't think the ConnectionToken is really expiring and that something else is happening. If you could provide a relevant PaymentIntent id that you are trying to confirm or what your code is doing exactly when you get that error it;'d be helpful

#

like maybe you are caching the ConnectionToken sometimes? Sorry it's vague because it's hard to pinpoint without more details

terse dragon
#

Here is the full text my coworker captured for context:

#

08-26 19:19:58.015 8144 8391 I StripeTerminal: class=RestClient message="url=https://api.stripe.com/v1/payment_intents request={"amount":"187","captureMethod":"manual","currency":"usd","description":"Test terminal payment flow","paymentMethodTypes":["card_present"]}"
08-26 19:19:58.162 8144 8391 I RestResponse: REST response with code 401 received
08-26 19:19:58.165 8144 8391 I StripeTerminal: class=RestClient message="url=https://api.stripe.com/v1/payment_intents status=UNAUTHORIZED response={"error":{"type":"invalid_request_error","code":"api_key_expired","docUrl":"https://stripe.com/docs/error-codes/api-key-expired","message":"Expired API Key provided: pss_test_YW*********************************************************************_******sCBs"}}"
08-26 19:19:58.166 8144 8391 E StripeTerminal: Stripe API error
08-26 19:19:58.166 8144 8391 E StripeTerminal: com.stripe.stripeterminal.external.models.TerminalException: Stripe API error

cunning raven
#

I believe this occurred during payment intent creation so I don't have an id since the request failed
(EDIT: this is wrong) nope that's impossible. PaymentIntent creation happens server-side in your application and uses your Secret API key. It doesn't happen client-side

#

Annnnd I am wrong and @river veldt rtold me you're right

terse dragon
#

haha ok, yea we're using the SDK to handle all the payment intent steps up until requires_capture on client side

#

as in, they are initiated from the client, which contacts the Stripe API directly, bypassing our backend

#

Although, is there any benefit to handling it server-side instead? Not sure if related to this issue but if it's more secure/stable in some way, we could potentially migrate the logic there

river veldt
#

@terse dragon so we have some assumptions. The ConnectionToken might be expiring but not the way you think. Do you have multiple instances of your app / point of sale software running?

My leading assumption is that you connect PoS-1 to Reader, so it has ConnectionToken-1, then you connect the same Reader to PoS-2 so it gets a new ConnectionToken-2 (and when that happens, ConnectionToken-1 is invalidated) but somehow that older ConnectionToken is being used (presumably due to that Terminal instance being cached or the older PoS interacting with the reader still, etc)

terse dragon
#

you know what, could it have to do with hot reloading a react native app?

#

and the JS context being destroyed between reloads

river veldt
#

oh

#

actually

#

possibly, it could!

#

RN hot-reloading is just 🪄 to me

terse dragon
#

but the Java keeps ahold of the old token

#

same

river veldt
#

but yeah it might be that

terse dragon
#

I've only recently started to wrap my head around what reloading actually does

#

but it would make sense that Java side would still try to use the previous values. Since this project is working on integrating with terminal, I'm disconnecting and reconnecting to the same reader fairly frequently

river veldt
#

yeah I would try to extensively test on a single load of the app (no code changes and no hotreloading) to connect, create PaymentIntent, confirm it, create another PI, confirm it, then re-connect to the same reader, then repeat

just to iron out if that same issue every happens during that.

and if not, that gives us some confidence that it might be related to hot reloading

terse dragon
#

awesome I will do that. Thanks for thinking through this with me 🙂

river veldt
#

np! Let us know how it goes!

terse dragon
#

Hi I'm not sure if this will revive this chat, but I have some more info about this issue. We've managed to consistently repro this error

#

@river veldt I think your assumption was correct, there were multiple instances of the app running used by different devs, however the reader we were connecting to was the simulated reader from Android SDK. My initial thought was that there is no way those could conflict since the simulated reader is part of separate Terminal class instances, but then I remembered that the simulated reader is using the same serial number "CHB20SIMULATOR" and that Stripe might be treating this as the same "reader" in terms of validating and expiring connection tokens

cunning raven
#

Since last time we talked, we found something internally too where we had a unique id for the simulated reader

#

and so it made it looks like someone was "replacing" the connection to your reader even though they used their own simulated reader, if that makes sense

#

exactly what you found on your own

#

We also spent hours digging into this with @river veldt and @jade cypress and others on my team when we found literally that this week where someone just fixed it last week

#

I'm so sorry you had to spend so long digging into this yourself too and that it turned out to be the same root cause/issue 😦