On iOS devices with iOS 17.4.1 Tap to Pay auto cancels after reconnection

[juananime]

Describe the bug

Stripe SDK tap on phone auto cancels collectPayment process after the previous payments has been cancelled as well.

To Reproduce
Steps to reproduce the behaviour:

On a iOS fresh installation on a iOS device with 17.4.1 iOS system :

• getting connection token;
• generated a payment intent.
• then calling collectPayment
• will show the Tap to Pay UI as expected.
• cancel payment.
• close app, forcing reader to disconnect.
• reopen app, wait for reconnection
• then try to go through payment process again.
• once you reach collectPayment the Tap to Pay tries to show up but it auto cancels all the time.

Expected behavior

• When user cancels payment on Tap to Pay and closes app, after reconnection to the reader, it should be accepting payments as usual

Screenshots

ad0e72a1-010b-4b31-b7a3-dbae3b7ffadb.MP4

Stripe Terminal React Native SDK version

0.0.1-beta.16

Smartphone (please complete the following information):

• Device: iPhone 13
• iOS: 17.4.1
• iOS terminal SDK: 3.4.0
• stripe-terminal-react-native : 0.0.1-beta.16

[phil-moonward]

Running into the same issue:

• Device: iPhone 12
• iOS: 17.4.1
• stripe-terminal-react-native : 0.0.1-beta.17

[juananime]

@phil-moonward gave me a working solution if anyone else bumps with this problem. When users cancels payment collection or any other error is been thrown, when collectPayment method is called, we must cancel the payment collection on the error block, calling the SDK method, cancelCollectPaymentMethod , same applies for the confirmPaymentIntent if that fails, we must cancel it as well, calling cancelPaymentIntent . Otherwise, seems that the failed payment would be cached somehow and get flagged as uncompleted. That seems to block any other future payments. Thanks @phil-moonward .

[phil-moonward]

@juananime Glad it helped. I deleted the original comment because even after adding these methods to the error blocks I was still getting the auto cancellation, but after doing further testing it definitely helped make the tap to pay screen come up more consistently - especially after the user hits cancel. If you're also still running into the auto cancel issue sporadically appearing and find a fix, let me know what worked.

[juananime]

@phil-moonward My guessing is that when users cancels , and app does not call those cancelCollectPaymentMethod and cancelPaymentIntent the operation gets cached somehow, and even if you call later on, until the cached not-complete-operation is cleared, the auto cancel issue may happen, but that is only a guessing. That si why still happens even after you cancels those methods.

[phil-moonward]

If anyone comes across this with similar issues, I found that building the app for testflight or as an ipa fixed all the remaining problems I was facing.

[brunoambr]

@juananime I have the same problem. Calling cancelCollectPaymentMethod does not help. Builded the app for TestFlight and the problem persists... When it starts to happen, it only works again after some time, so I think the operation may be cached somehow.

Did you find any other workaround?

[juananime]

@brunoambr Yes you are right, I'm having the same issue back again in another project.
So definitely call the cancel methods is not the solution.

[brunoambr]

@juananime Maybe I have some scenario information that will be helpful somehow..

We have two test devices (iPhone 13). One of them has a credit card added to Apple Pay, and the other one doesn't.

The device that does not have a credit card never bugged (same app and same version), while the other one bugs oftenly. When it is bugged and the Tap to Pay screen won't open and we try to use the credit card (tapping twice the blocking button), the message "Updating cards" is shown.

Maybe this is not related at all with the current issue, but maybe it could mean something.

Seems we don't have control at when it will happen or not, it seems random.

[phil-moonward]

@juananime I have the same problem. Calling cancelCollectPaymentMethod does not help. Builded the app for TestFlight and the problem persists... When it starts to happen, it only works again after some time, so I think the operation may be cached somehow.

Did you find any other workaround?

After a lot of testing is does seem that this issue appears at random even after building for testflight. I have not found a fix, but a temporary workaround for development & testing is to restart the phone, which for me consistently solves the issue (until it comes back again), which lends credence to the theory that the operation is being cached somewhere and doesn't clear. I also tested on the newest beta version of iOS 17 as well as iOS 16 and ran into the same problem after enough time, so it doesn't seem to be an iOS version specific problem.

[nazli-stripe]

hey all, we are actively trying to reproduce and debug this issue and i'll share more updates once we have a better understanding of what's happening

[nazli-stripe]

@phil-moonward @brunoambr @juananime is it possible to get serial numbers of the devices you are running into this issue on so we can take a closer look?

This is the serial number returned on the Reader object.

[tzecheng]

Hi, currently we have an issue which I am not sure is related:

1. Phone sleeps, say 2 hours or overnight, and in the morning, app is re-opened (it is in background, not terminated)
2. Take about 5 payments (number of payments varies) and the 6th and subsequent payments get cancelled
3. Need to either terminate the app or log out to continue payments, sometimes a phone reboot
4. iOS 17.4.1 / Stripe Terminal React Native SDK version 0.0.1-beta.17 / Stripe iOS Terminal SDK version 3.4.0
5. @nazli-stripe -> serialNumber: '1697e8369a6c7c58c74ddb15220ef411ec1fbf45def1ee04d0981c91966408cd'
6. This happens to me regularly so I think it is fairly easy to reproduce

[ermankos]

Hi, we also have the same issue.

In addition to all the problems described, the app also gets stuck in the 'background' state when this happens. ( I suspect there is a transparent/invisible layer of the ttp screen on top of the app that prevents interacting with the app). The only way to fix that was to lock the screen and then unlock it, then you can shut down the app and restart to fix it. This happened on iOS 17.4.1 as well.

I can give one example of serial number @nazli-stripe: 9d09b76bcfad6841002ba36cf2ba21cc52a70c97c5201c6908b288636761b82f

[brunoambr]

@phil-moonward @brunoambr @juananime is it possible to get serial numbers of the devices you are running into this issue on so we can take a closer look?

This is the serial number returned on the Reader object.

@nazli-stripe sure: 456f6fc3c478a3f11f660f3b493e001879329c287f049ec6d1edf66129a3b547

[tzecheng]

Hi, have updated to Stripe Terminal React Native SDK version 0.0.1-beta.18, but it does not help.

I found out that my issue is a native iOS problem in stripe/stripe-terminal-ios#300.

[nazli-stripe]

hey all, as @tzecheng mentioned we tracked down to issue to an underlying problem in the Terminal iOS SDK. You can follow stripe/stripe-terminal-ios#300 for updates. We need to first release a new iOS SDK version with the fix before we can update RN SDK

[nazli-stripe]

Copying over from stripe/stripe-terminal-ios#300

Hey everyone, Apple confirmed that this is a known bug with iOS 17.4.1. It should be patched if you upgrade to iOS 17.5. Thanks again for all the details!