Allow Merchant to Only Set Universal Links for Venmo

[jaxdesmarais]

Summary of changes

• A bug was recently brought to the service channel where if a merchant trys to move from the deprecated BTAppContextSwitcher.sharedInstance.returnURLScheme for Venmo they get an error if only passing a universal link. We should allow merchants to only use universal links without needing to set both that and a returnURLScheme

I tested the following flows on device, please feel free to retest these or call out any use cases I missed:

• universalLink and returnURLScheme not set (returns an error)
• only returnURLScheme set (uses returnURLScheme for switch and return)
• only universalLink set (uses universalLink for switch and return)

Checklist

• Added a changelog entry
• Tested and confirmed payment flows affected by this change are functioning as expected

Authors

• @jaxdesmarais

[jaxdesmarais]

This logic seemed pretty odd, is there a usecase where we want a merchant to set a return URL for the switch but use universal links only for the return? That seemed a bit odd to me and what was happening. I would expect if a merchant passes a universal link we want to use that for the switch and return. Maybe we should be setting this for a new universalLinkkToggle instead so we can test both the UL and return URL scheme flows?

[scannillo]

I think this was added before we supported universal links to the merchant app. Down to consolidate them into 1! I don't know how much value there would be to having 2 separate toggles since technically a merchant can opt into the web-fallback (UL to venmo), but still use schemes back to their app

[jaxdesmarais]

I don't know how much value there would be to having 2 separate toggles since technically a merchant can opt into the web-fallback (UL to venmo), but still use schemes back to their app

I don't think this is true, as the logic exists if we get a universal link we use them for the return:

braintree_ios/Sources/BraintreeVenmo/BTVenmoAppSwitchRedirectURL.swift

Lines 60 to 62 in f1a6643

	queryParameters["x-success"] = universalLink.appendingPathComponent("success").absoluteString
	queryParameters["x-error"] = universalLink.appendingPathComponent("error").absoluteString
	queryParameters["x-cancel"] = universalLink.appendingPathComponent("cancel").absoluteString

Is there a reason we'd want to still use URL scheme's to return back to the app if a universal link is passed?

[scannillo]

Do we want to update this to Swift-y syntax instead of ObjC? Would you consider it a breaking change?

[jaxdesmarais]

Yeah I have always wondered how/if the NSLogs are actually useful to merchants. It's also interesting that we return an appNotAvailable for a missing return URL scheme and return nothing and instead fail later if the bundle ID doesn't contain the return URL scheme. To me it seems like they should both be handled the same, though not sure what we consider in scope for this PR.