Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QL] Update BTAppContextSwitcher.sharedInstance.universalLink to URL Type #1232

Merged
merged 13 commits into from
Mar 26, 2024

Conversation

jaxdesmarais
Copy link
Contributor

@jaxdesmarais jaxdesmarais commented Mar 22, 2024

Summary of changes

Checklist

  • [ ] Added a changelog entry

Authors

@jaxdesmarais jaxdesmarais requested a review from a team as a code owner March 22, 2024 13:57
@@ -38,12 +38,12 @@ import BraintreeCore
baseParameters["payer_email"] = userAuthenticationEmail
}

if enablePayPalAppSwitch {
if enablePayPalAppSwitch, let universalLinkURL = BTAppContextSwitcher.sharedInstance.universalLink {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think we should return an error if they try to opt into enablePayPalAppSwitch but don't have a universal link set?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 that's a good question - I think it depends on the merchant experience we want. If this is not set we would get nil back as the paypalAppApprovalUrl so would just continue with the ASWeb based flow, but nothing would blow up. On the other side of things I can see a merchant ``not wanting the ASWeb flow if they have set enablePayPalAppSwitch in which case we should add a check on the client that if true this value is also set. Which way are you leaning?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I lean toward returning an error if they don't have the universal link set.

Actually brings me to another thought - we don't need them to pass us the URL in their app delegate, do we? We shouldn't need it that early. We only need it at the time of making the GQ hermes POST request. We could enforce this at the BTPayPalRequest init level. We can add an additional init specific to this flow that takes in everything we need: email, flag, link

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that is a great question - I was just rolling with the design we had outlined. Technically I don't think the returnURLScheme for the Venmo flow needs to be set in BTAppContextSwitcher either. It's also not used until the tokenize method is called. Do you know historically why those were set in that manner instead of on the clients?

I am down to move this into a new init - I think that makes sense in this PR. We would also need to make a very fast follow docs PR since that was merged in today to be released Wednesday. I think if we make it required in the init we won't need to throw an error from the request or do a check in the client and throw the error there.

If that sounds good to you I can make the change here and get up a docs update as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@scannillo this update is reflected in the PR - if we are good with this change, I will open a new docs PR and ping the docs team as well as update our HLD. In BTPayPalVaultRequest I added a new init with the required properties and made universalLink an internal var on the class so it can only be set on the init - this will enforce it as required without us needing to throw an error in the init for this flow.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know historically why those were set in that manner instead of on the clients?

Unfortunately I don't know why it was that way

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, it's a great question in any case! I'm going to add a NEXT_MAJOR_VERSION note to returnURLScheme so we can move that to the clients in the future. 🚀

/// Optional: Used to determine if the customer will use the PayPal app switch flow.
/// Defaults to `false`.
/// - Note: This property is currently in beta and may change or be removed in future releases.
public var enablePayPalAppSwitch: Bool
var enablePayPalAppSwitch: Bool = false
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider defaulting this to true? Do we even need this property at all or can we assume if the universal link is passed a merchant is opting into the flow?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm yea that's a good point ~ imo i feel it's safe to remove this property since we can assume whether or not to launch the app switch flow based on if universalLink is passed in

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we are going to leave this as is for now to make it apparent to merchants that they are opting into this flow with both the bool and a universalLink. With just the universalLink it may make merchants think we are using that on the existing web flow (which we are not)

/// - Parameters:
/// - userAuthenticationEmail: Required: User email to initiate a quicker authentication flow in cases where the user has a PayPal Account with the same email.
/// - enablePayPalAppSwitch: Required: Used to determine if the customer will use the PayPal app switch flow.
/// This property is currently in beta and may change or be removed in future releases.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit(optional): can we move this line after all the parameter comments

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually going to move it with the main note: 631b3e3. Here is what a merchant will see:
Screenshot 2024-03-26 at 12 15 36 PM

@@ -87,7 +87,12 @@ class PayPalWebCheckoutViewController: PaymentButtonBaseViewController {

@objc func universalLinkFlow(_ sender: UIButton) {
// TODO: implement in a future PR - used here so we don't have to remove lazy instantiation
let request = BTPayPalVaultRequest(enablePayPalAppSwitch: true)
// TODO: replace URL with https://braintree-ios-demo.fly.dev/braintree-payments
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The gateway has not yet allowlisted our URL for this flow, so we are using a URL that is included in their allowlist currently.

CHANGELOG.md Outdated Show resolved Hide resolved
@jaxdesmarais jaxdesmarais merged commit 6720c73 into paypal-app-switch-feature Mar 26, 2024
5 of 7 checks passed
@jaxdesmarais jaxdesmarais deleted the universalLink-to-url branch March 26, 2024 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants