[BUG] Stuck in Adyen Drop-in view
Describe the bug The Adyen Drop in is not possible to dismiss after switching payment option to card payment if the the previously chosen method was opening another app. The user is stuck in the drop in and cannot anymore use the app. This happening when using Swish as a payment option and then switching to card.
In DropInComponent, the paymentInProgress seems to be true in the cancel button method.
private func didSelectCancelButton(isRoot: Bool, component: PresentableComponent) {
guard !paymentInProgress || component is Cancellable else { return }
userDidCancel(component)
if isRoot {
self.delegate?.didFail(with: ComponentError.cancelled, from: self)
} else {
navigationController.popViewController(animated: true)
}
}
To Reproduce Steps to reproduce the behavior:
- Choose payment option Swish
- When Swish is opened, manually navigate back to the app without continue the Swish payment
- Change payment method to Card
- Try to cancel the drop in
- Nothing happens...
Expected behavior The user should be able to close the drop in.
Screenshots
https://user-images.githubusercontent.com/95345576/153404982-4a209c8e-b35b-43f9-ace4-f899f4ee284a.mov
Smartphone (please complete the following information):
- Device: iPhone 12 Pro
- OS: iOS 15.1.1
- SDK Version: 4.6.1
Additional context Add any other context about the problem here.
Hey @bonmw
Thanks for reaching out.
I would say that this is an "expected" scenario: shopper choose another payment method and can still successfully complete a payment. :)
Expected scenario is shopper clicking "Cancel" in Swish and automatically redirected to app - than it is handled as "Cancelation error" and you can start new payment flow.
If user manually returns to app, both Swish and Adyen SDK still believes that payment is in progress: new payment attempt is recorded and will appear on your Customer Area portal. There is no way to tell if shopper is going to get back to that payment in future and finish it.
Potentially, we can add paymentInProgress = false to DropInComponent.didFinalize(with success: Bool).
Then you can observe UIApplication.willEnterForegroundNotification and call dropInComponent?.finalizeIfNeeded(with: false).
However, you should realise that in this case user can still do two (multiple) payments.
In general, after /paymens request is submitted, your app should consider that payment is pending and only start another payment (open another DropIn) if user explicitly confirmed that they are "canceling" and willing to try again.
Ok, but if the user manually switch back and is not choosing another payment option, then the user is able to press the cancel button. It is only when the user choose another payment option the user can get stuck.
Indeed. We can improve UX it by blocking payment methods list completely, so shopper can only close, but not select another method.
Unfortunately, app-to-app redirects are fragile and because SDK is loosing control over the payment flow - there might be unpleasant consequences for shopper or your business(chargebacks, conversion drop).
We are investigating potential improvements for app-to-app redirects, but ATM I can only suggest to monitor lifecycle of your app with UIApplication.willEnterForegroundNotification in your own manner.
Hey @bonmw
Were you able to resolve the problem?
I am going to close this ticket due to lack of activity. Feel free to reopen it or continue here