Stripe-ios: 3DSecure redirect issues

[raulabamobile]

Summary

Facing same behaviour as closed bug #917.

• startRedirectFlow and startSafariViewControllerRedirectFlow: the safari view controller seems to come and go back in a flash without any intervention and brings me back to the app.

• startSafariAppRedirectFlow: when I click on "Return to App", the appdelegate boolean stripeHandled returns as false, even though I can see that the url returned to the app is the one that I set as the return URL while creating the 3D source,

Code to reproduce

let cardParams = STPCardParams()
        cardParams.number = "4000000000003063"
        cardParams.expMonth = 12
        cardParams.expYear = 18
        cardParams.cvc = "424"       
        let sourceParams = STPSourceParams.cardParams(withCard: cardParams)
        STPAPIClient.shared().createSource(with: sourceParams) { (source, error) in
            if let s = source, s.cardDetails?.threeDSecure == STPSourceCard3DSecureStatus.required {
                let threeDSecureParams = STPSourceParams.threeDSecureParams(withAmount: 1000, currency: "eur", returnURL: "myexample://stripe-redirect", card: s.stripeID)                             STPAPIClient.shared().createSource(with: threeDSecureParams, completion: { (source, error) in
                    if let error = error {
                        NSLog("ERROR:")
                    } else {
                        let redirectContext = STPRedirectContext(source: source!, completion: { (sourceId, clientSecret, error) in
                            if let s = source, s.cardDetails?.threeDSecure == TPSourceCard3DSecureStatus.required {                                if s.status == STPSourceStatus.chargeable {
                                    NSLog("+++ STATE: CHARGEABLE +++")
                                } else if s.status == STPSourceStatus.consumed {
                                    NSLog("+++ STATE: CONSUMED +++")
                                } else if s.status == STPSourceStatus.canceled {
                                    NSLog("+++ STATE: CANCELED +++")
                                } else if s.status == STPSourceStatus.pending {
                                    NSLog("+++ STATE: PENDING +++")
                                } else if s.status == STPSourceStatus.failed {
                                    NSLog("+++ STATE: FAILED +++")
                                } else if s.status == STPSourceStatus.unknown {
                                    NSLog("+++ STATE: UNKNOW +++")
                                }
                            }
                        })                   
                        redirectContext?.startRedirectFlow(from: self)
                    }
                })
            } else {
                // Send to Server
                NSLog("Send to Server")
            }
        }

iOS version

10.3.2, 11.2 , 11.3

Installation method

CocoaPods: pod Stripe

SDK version

13.0.2

Other information

[ssebi]

I am having the exact same issue, also running SDK version 13.0.2 and the code is similar. iOS version 11.4

[joeydong]

Hi @raulabamobile, thanks for opening an issue.

startRedirectFlow and startSafariViewControllerRedirectFlow: the safari view controller seems to come and go back in a flash without any intervention and brings me back to the app.

Are you able to reproduce with Xcode attached? If so, do you get any error messages in the console? Can you set a breakpoint on the first line of your STPRedirectContext completion block and check the value of error?

startSafariAppRedirectFlow: when I click on "Return to App", the appdelegate boolean stripeHandled returns as false, even though I can see that the url returned to the app is the one that I set as the return URL while creating the 3D source,

I think we have some leads to try and fix this one. Let me check.

[joeydong]

Hi @ssebi,

Can you explain a little bit more what issue you are facing? Is your app switching to Safari or is it showing an in-app browser? Can you reproduce with Xcode attached and check if there is an error as I mentioned to @raulabamobile?

[raulabamobile]

Hi @joeydong ,
No error messages in the console and the app is not executing (or stopping) the completion code. startRedirectFlow and startSafariViewControllerRedirectFlow are flashing an in-app browser for a second and closing it.
Thanks for your help.

[ssebi]

Hi @joeydong,

I have the same behaviour as @raulabamobile has. startSafariViewControllerRedirectFlow and startRedirectFlow are flashing and there's no error in the console. startSafariAppRedirectFlow is the one that works although is not the best choice from a user experience point of view because it jumps into Safari. After the return to app button is pressed, completion block in STPRedirectContext is not being called and the method Stripe.handleURLCallback which is called in the AppDelegate returns false.

[ssebi]

After some digging I found out that following method is not being called causing the redirectContext not be be called also:

• (BOOL)handleURLCallback:(__unused NSURL *)url {
  stpDispatchToMainThreadIfNecessary(^{
  [self handleRedirectCompletionWithError:nil
  shouldDismissViewController:YES];
  });
  // We handle all returned urls that match what we registered for
  return YES;
  }

it should be called from within STPURLCallbackHandler, line 72 [callback.listener handleURLCallback:url] but when stepping into with the debugger it just skips.

[joeydong-stripe]

startSafariAppRedirectFlow: when I click on "Return to App", the appdelegate boolean stripeHandled returns as false, even though I can see that the url returned to the app is the one that I set as the return URL while creating the 3D source,

So the cause of this behavior is because the STPRedirectContext listens for both the App Delegate's "openURL" call and "App Entered Foreground" notification. Looks like, currently, the "App Entered Foreground" fires first and completes the STPRedirectContext so the [Stripe handleStripeURLCallbackWithURL:url] returns NO. Does that make sense? I think the recommendation is to ignore the failure because it was already successfully handled elsewhere?

[joeydong-stripe]

I think the move forward for this SDK is to eliminate the "openURL" listener and rely on the general "App Entered Foreground" notification all the time

[ssebi]

Yes, it does make sense and I will ignore it. Thank you for your quick answer! Any news about the flashing issue?

[joeydong-stripe]

Yes, it does make sense and I will ignore it. Thank you for your quick answer! Any news about the flashing issue?

Yep, I think we're still trying to understand what the problem is beyond what the interface is doing. Would you be able to set a breakpoint here: https://github.com/stripe/stripe-ios/blob/master/Stripe/STPRedirectContext.m#L213 and see if it's ever called? What are the values of the function parameters?

[raulabamobile]

Yep, I think we're still trying to understand what the problem is beyond what the interface is doing. Would you be able to set a breakpoint here: https://github.com/stripe/stripe-ios/blob/master/Stripe/STPRedirectContext.m#L213 and see if it's ever called? What are the values of the function parameters?

It's not stopping when in-app browser flashes.

I think the move forward for this SDK is to eliminate the "openURL" listener and rely on the general "App Entered Foreground" notification all the time

If we do this, STPRedirectContext completion code is never called and we can't check the payment status. Any other ideas or way to do it?

[joeydong-stripe]

Hi, I just opened this pull request (https://github.com/stripe/stripe-ios/pull/962) to try and solve the second issue. If you can, please try it out and let me know if it helps :)

[plevetsky]

I had the same 2 issues when declaring STPRedirectContext as a local variable. Once I moved the STPRedirectContext instance to be a property of the class with a strong reference (like in the Stripe iOS sample app) the redirect started working as expected.

[joeydong-stripe]

Good tip @plevetsky! Thanks!

Please open a new issue if any of you have any further trouble. I'm going to close this issue because it's getting long and losing focus.