[Tap To Pay] Reader has been disconnected unexpectedly on Android devices

[ThanJack]

Describe the bug
After putting the Android app in the background for some time, then reopening the app to do the first Tap to Pay transaction causes the following issue happens:

[Stripe terminal]: didReportUnexpectedReaderDisconnect { message: 'Reader has been disconnected unexpectedly',
  code: 'UNEXPECTED_ERROR.UNEXPECTED_SDK_ERROR' }

It happened after after creating the Payment Intent by the createPaymentIntent function and before the collectingPaymentMethod function executes. Then the collectingPaymentMethod function throws this error, which causes the transaction to fail:

{ code: 'INTEGRATION_ERROR.NOT_CONNECTED_TO_READER',
  message: 'LocalMobile reader is not connected' }

To Reproduce
Steps to reproduce the behavior:

1. Put app to the background for a while (eg. more than 2 hours).
2. Reopen the app, start the first transaction.
3. Tap To Pay screen appears, try to tap a card.
4. The issue above happens.

Expected behavior

The Reader should not be disconnected unexpectedly when doing the transaction.

Stripe Terminal React Native SDK version

• ^0.0.1-beta.17
• ^0.0.1-beta.18

Smartphone (please complete the following information):

• Device: Google Pixel 3a
• OS: Android 12

[tzecheng]

Hi,
It also happens on a Pixel 4, running Android 13.
Note that the error is random. We left the app in the background over multiple periods, sometimes the payment works on re-opening the app, sometimes the above error happens.

[nazli-stripe]

@tzecheng and @ThanJack can you share account and serial numbers so we can investigate?

[tzecheng]

Hi @nazli-stripe , I can't find the account and serial numbers when the payment is cancelled.

The latest has id: pi_3PF7CwEcr8OExvfT1zxs98vO

Attached bugfender screen shot
android cancelled 4.pdf

Hope that helps. Thanks.

[KillianLarcher]

It also happens on a Pixel 4, running Android 13.
Note that the error is random. We left the app in the background over multiple periods, sometimes the payment works on re-opening the app, sometimes the above error happens.

Same problem here on Samsung Tab Active 3, running Android 13.

[nazli-stripe]

This appears to be a potential issue with our native Android SDK, we are investigating internally. Will update this ticket with new information

[tzecheng]

Hi @nazli-stripe ,

This is one of the latest instances where there is a serial number it it helps:
serialNumber: '7808ed1a-4ea0-4f73-9c83-5a7bc28a04f4'

[tzecheng]

Here's another serial number:
serialNumber: 'b7c812c4-0237-4b3b-9366-cc9318004df0'

[KillianLarcher]

Any news? @nazli-stripe

[tzecheng]

Hello, @nazli-stripe ,
Any progress on this?

[tzecheng]

Hi there,
Here's is a screenshot of latest failure,
Serial number: 6b16a116-d082-4568-af55-34e1104bdf3a

[tzecheng]

Hi there,

Have tried with
^0.0.1-beta.19 and ^0.0.1-beta.20

Problem is still there.
Latest serialNumber: '2e941d93-52cb-4eea-a3db-9fbe1ecd1c13'

[nabilfreeman]

We are also experiencing this. The only solution so far has been to disconnect and reconnect the reader every time we want to initiate Tap to Pay. It looks like the library is unable to monitor the connection state of the reader in background and auto reconnect properly.

[tzecheng]

Hi there,
Have updated to v0.0.1-beta.22, but this problem still appears occasionally.
Latest serial no:

[nazli-stripe]

hey sorry for the radio silence on this one, we just released beta.23 with upgrades to the native Android SDK. Do you run into the issue there as well?

[nazli-stripe]

@tzecheng did updating to beta.22 help with the occurrences of the issue?

[tzecheng]

Hi @nazli-stripe ,

Problem still happening in v0.0.1-beta.22, as mentioned in an earlier chat #693 (comment)

Will be testing with v0.0.1-beta.23 next week.

Thanks.

[tzecheng]

Hi @nazli-stripe ,

We updated to v0.0.1-beta.23, but unfortunately the error is still there.

1. First tap - it errors, the white Tap to Pay screen does not appear
2. App goes back to the payment screen - the amount is still there
3. Second tap - the white Tap to Pay screen appears, tap the card to the back of the phone and it completes

Latest error:
payment_intent_id: 'pi_3QPxgUEсr80ExvfT1oaFUjK6
serialNumber: '0cb69f75-032f-4863-b2a6-7b7a9ed4e4ab'

android bg error.pdf

[tzecheng]

Hi @KillianLarcher , @nabilfreeman ,
Not sure whether I should post this here:
Did you manage to find a work around for this and would you mind sharing it?
Users are finding this is frustrating especially when they need to take a payment quickly.
We show them an error modal and ask them to retry again which works, but it is still annoying.

cc: @nazli-stripe

[nabilfreeman]

@tzecheng the solution for us has been to disconnect the reader after every success/failure and make sure we are connecting from scratch whenever the user initiates the payment flow.

I mentioned this above in a comment a few months back - it seems that there are some issues with the library maintaining a synchronised connection state with the OS.

This is not necessary on iOS, but the Android side has a lot of Tap to Pay bugs and a degraded experience. See #809 for more problems

Worth understanding that this library is a wrapper for closed-source iOS and Android SDKs, which are often several versions ahead of the pinned version here, so it’s very difficult for us to debug.

[tzecheng]

Hi @nazli-stripe ,

We did some further testing with v0.0.1-beta.23 and this is our observation:

1. In our onDidReportUnexpectedReaderDisconnect callback, we remove our codes to disconnect any existing readers, then to discover and connect to readers - basically let the Stripe SDK handle the reconnects
2. On coming from background, we start a payment
3. onDidChangeConnectionStatus shows the reader trying to connect → happens 3 times
4. At this point, the payment intent returns a timeout about a second later
5. [Stripe terminal]: didChangeConnectionStatus now connects → appears about 5 seconds later
6. Now retrying the payment works since reader is now available
7. Note the timing is from our app, and will not apply across board

Our guess is that in our case, when coming from background or when network is reconnecting, the reader takes time to connect, but the payment intent has timed out.