#nabilfreeman_error

1 messages · Page 1 of 1 (latest)

pine karmaBOT
#

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

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

magic kestrel
turbid stream
#

👋

#

One moment, let me see if a colleague is available who is more familiar with this.

magic kestrel
#

Thanks

#

I'll just post a couple more things here that might give further context while the issue is fresh in my mind

#

  1. We also saw the Android alert "JENA keeps stopping" (where JENA is the name of our app) several times after getting the "Try again" loud beep. We have considered the possibility that there is some synchronous thing blocking the execution of code causing the AIDL server networking to error out.

  2. We are using a Monzo MasterCard debit card in real world testing. We have considered the possibility that perhaps we have been using this card too much and it is coming up against some rate limiting or something. We tried a MasterCard credit card and the error still happens, but less often.

finite prairie
#

Hello

magic kestrel
#

I noticed on the GitHub issues generally the terminal devs frequently ask for the serial number (our one is 3f80cfc2-2753-4560-b481-6553b8373326)

#

Hi @finite prairie !

finite prairie
#

Do you have an example PaymentIntent ID?

magic kestrel
#

Yep, let me try and find it

#

These 3 payment intents are the failed ones from the QA session where that photo was taken:

pi_3Py9uTHGq6fVLGOP04vwvO02
pi_3Py9tyHGq6fVLGOP1xDJTubM
pi_3Py9tPHGq6fVLGOP0BG6qnIr

finite prairie
#

Can you also share dependencies you have in your project? like in package.json

#

with their exact versions?

magic kestrel
# 
"dependencies": {
    "@stripe/stripe-terminal-react-native": "^0.0.1-beta.21",
    "expo": "~51.0.31",
    "expo-application": "~5.9.1",
    "expo-asset": "~10.0.6",
    "expo-build-properties": "~0.12.5",
    "expo-clipboard": "~6.0.3",
    "expo-constants": "~16.0.2",
    "expo-crypto": "~13.0.2",
    "expo-dev-client": "~4.0.26",
    "expo-device": "~6.0.2",
    "expo-file-system": "~17.0.1",
    "expo-font": "~12.0.10",
    "expo-haptics": "~13.0.1",
    "expo-image": "~1.12.15",
    "expo-image-picker": "~15.0.7",
    "expo-insights": "~0.7.0",
    "expo-linking": "~6.3.1",
    "expo-localization": "~15.0.3",
    "expo-location": "~17.0.1",
    "expo-mail-composer": "~13.0.1",
    "expo-notifications": "~0.28.16",
    "expo-router": "~3.5.23",
    "expo-sharing": "~12.0.1",
    "expo-splash-screen": "~0.27.4",
    "expo-status-bar": "~1.12.1",
    "expo-symbols": "~0.1.5",
    "expo-updates": "~0.25.24",
    "expo-web-browser": "~13.0.3",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-error-boundary": "^4.0.12",
    "react-native": "0.74.5",
    "react-native-gesture-handler": "~2.16.1",
    "react-native-reanimated": "~3.10.1",
    "react-native-safe-area-context": "4.10.5",
    "react-native-screens": "3.31.1",
    "react-native-svg": "15.2.0",
    "react-native-web": "~0.19.10",
    "react-redux": "^8.1.1",
    "redux": "^4.2.1",
    "redux-thunk": "^2.4.2"
  }

I've omitted a few private dependencies that are not related to the Stripe integration

finite prairie
#

gotcha. The ones you removed, are not related to networking correct?

magic kestrel
#

Only these:

    "axios": "^1.4.0",
    "url": "^0.11.3",
#

We also have an iOS version of the app out which is processing TTP payments without any issues

finite prairie
#

Is your app debug or release build?

magic kestrel
#

Release

#

This is a production build which is on the internal testing track in Google Play

finite prairie
#

Okay! do you have a different device you can test on? Trying to narrow down if this is device specific

magic kestrel
#

Yeah, it's a Google Pixel 6a

#

Here's the reproduction steps I posted in the GH issue:

To Reproduce
Steps to reproduce the behavior:

  1. Trigger collectPaymentMethod({ paymentIntent })
  2. Observe payment sheet appears
  3. Tap a payment card in the indicated location
  4. Observe either a successful payment (if so, restart the steps here), or a loud beep and "Try again" error
  5. After 2-3 "Try again" errors, observe the payment sheet dismisses and collectPaymentMethod promise rejects with the error message in the issue title.
#

The Stripe Terminal Android SDK version is 3.7.1 I think

finite prairie
#

Hmm so in our logs I'm seeing this error show up on largely two SDK methods..
connectReader and collectPaymentMethod

Are you disconnecting and reconnecting reader in your app flow?

magic kestrel
#

Here's broadly how it works:

#
  1. The payment screen opens. We call connectLocalMobileReader as soon as the TTP reader is discovered (or immediately if it has already been discovered).
  2. When the user presses the "Tap to Pay" button, we enter loading state, retrieve the payment intent using retrievePaymentIntent({ clientSecret }) and then pass the fetched payment intent to collectPaymentMethod({ paymentIntent })
#

The reason we connect when the screen mounts is because we found connecting when tap to pay is pressed results in a very slow user experience

finite prairie
#

When the payment fails, does the app go back to the payment screen? Triggering the connectLocalMobileReader again?

#

Could you try tweak your flow a little bit and see if you can do connection on button click?

Trying to rule out app lifecycle being the cause

magic kestrel
#

On the current build when there is a payment error we disconnect the reader, allowing for a fresh start next time the TTP button is pressed. The reason for this is because we noticed that sometimes the reader disconnects in background and we get an error "No localMobile reader connected"

#

Yes, I can revert back to making a fresh connection when the TTP button is pressed

#

So we will only do "pre-warming" on iOS

#

On iOS it works very well btw. We pre-connect to the reader when the screen opens, and then when the "Tap to Pay" button is pressed, there is zero latency presenting the reader.

#

Otherwise we had a 5-30 second wait from pressing the button to the reader presenting

#

Just to confirm, are you able to see the errors on your side?

finite prairie
#

Yeah, there might be some differences between how both platforms handle certain tasks.

You mentioned you have a different device you can test on.. Could you use that device and test to double check if the issue persists there too?

Just to confirm, are you able to see the errors on your side?
I'm able to see the logs using your serial number.. I have not been able to reproduce the issue though

magic kestrel
#

I only have the Pixel 6a available to test on

finite prairie
#

okay, NP!
Let's try adding the button

magic kestrel
#

Ok, here's what I'll do now... fresh build with pre-warming disabled on Android. Then I'll try to reproduce the bug and update you here (probably in 1-2 hours). Will confirm that the serial number is the same, or if it comes up different, I will send you the updated serial number. I will also share the payment intent

finite prairie
#

Sounds good!

magic kestrel
#

Thank you mate, it's really nice being able to talk directly to you guys

#

Speak soon