[QL] Parse App Switch Return URL

[jaxdesmarais]

Summary of changes

• Add implementation to BTPayPalAppSwitchReturnURL
• Rename BTPayPalClient.handleBrowserSwitchReturn to handleReturn since it will be used for both app switch and ASWeb returns
• Add implementation for handleReturnURL for App Switch flows
• Add new BTPayPalError.unknownAppSwitchError and update typo on invalidURL error
• Add BTPayPalAppSwitchReturnURL_Tests
• Add new BTPayPalClient_Tests for new code

Checklist

• [ ] Added a changelog entry

Authors

• @jaxdesmarais

[jaxdesmarais]

We had a typo here and also are using this error for URLs outside of authentication so updated this string.

[scannillo]

Were you able to test with any stubbed redirect URL (using our demo apps fly.io site)? I'm curious if /v1/payment_methods/paypal_accounts works as expected with an HTTPS path or if we'll need an update from the GW

[jaxdesmarais]

Were you able to test with any stubbed redirect URL (using our demo apps fly.io site)? I'm curious if /v1/payment_methods/paypal_accounts works as expected with an HTTPS path or if we'll need an update from the GW

I was able to test this and there were no issues with the HTTPS path, since we are mainly parsing the data from that path to send into paypal_accounts. It's a bit awkward to test since we are working off of mocks right now, but this is what I did (it needs a real EC token and BA token to work):

1. Comment out our UIApplication.shared.open line in the View Controller
2. Add a breakpoint in line 169 of handleReturn and grab the valid EC and BA token from the URL
3. Stop the app and replace line 169-175 with:

        let newURL = URL(string: "https://www.paypal.com/success?token=MY_EC_TOKEN&ba_token=MY_BA_TOKEN&switch_initiated_time=123456789")!
        guard isValidURLAction(url: newURL) else {
            notifyFailure(with: BTPayPalError.invalidURLAction, completion: completion)
            return
        }
        
        guard let response = responseDictionary(from: newURL) else {

4. Run the app again with this change
5. No errors are returned in paypal_accounts and we get a nonce back as expected in notifySuccess

We can really only test pieces of this so far until we actually start getting the expected data back, but working off of our mocks this should work as expected 🤞. Let me know if I misunderstood what you were thinking we'd test here, did a lot of very hacky workarounds based on mocks to test different pieces. 😅

[agedd]

curious why we add the check for universalLink being nil here 👀

[jaxdesmarais]

Good question, we only care about (and want to return false here for isValidURLAction) if the hostAndPath is not the callbackURLHostAndPath and if the universalLink is nil. That combination would mean that we aren't using the UL flow and the hostAndPath is invalid we wouldn't have a valid URL action. If we are using the UL flow we can essentially skip this check since it's not relevant to that flow.

[scannillo]

This line is a little confusing to read IMO. I think it will clear up in DTBTSDK-3751

[scannillo]

Now we have some return URL parsing happening in BTPayPalClient and some happening in BTPayPalAppSwitchReturnURL. Maybe for another PR, we can repurpose BTPayPalAppSwitchReturnURL to do URL parsing for both the web flow & app switch flows.

[jaxdesmarais]

Created DTBTSDK-3751 for this

[agedd]

left a few minor comments, looks good to me!

[scannillo]

Similar comment here, we aren't using this.

This surfaces that we need to ask the analytics folks what they want us to do with this number, let's ask them! They may want us including it in an additional analytic event send