-
Notifications
You must be signed in to change notification settings - Fork 293
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
[QL] Update BTAppContextSwitcher.sharedInstance.universalLink
to URL Type
#1232
Conversation
@@ -38,12 +38,12 @@ import BraintreeCore | |||
baseParameters["payer_email"] = userAuthenticationEmail | |||
} | |||
|
|||
if enablePayPalAppSwitch { | |||
if enablePayPalAppSwitch, let universalLinkURL = BTAppContextSwitcher.sharedInstance.universalLink { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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:
@@ -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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious why we can't use: "https://braintree-ios-demo.fly.dev/braintree-payments"
There was a problem hiding this comment.
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.
Summary of changes
Replace
BTAppContextSwitcher.sharedInstance.universalLink
with init:BTPayPalVaultRequest(userAuthenticationEmail:enablePayPalAppSwitch:universalLink:offerCredit:)
OG convo here: [QL] Add additional POST params to
/setup_billing_agreement
API call #1228 (comment)Checklist
[ ] Added a changelog entryAuthors