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

Clean up the payment options on Pay button in New Dot #33967

Closed
anmurali opened this issue Jan 4, 2024 · 10 comments
Closed

Clean up the payment options on Pay button in New Dot #33967

anmurali opened this issue Jan 4, 2024 · 10 comments
Labels
Engineering Reviewing Has a PR in review Weekly KSv2

Comments

@anmurali
Copy link

anmurali commented Jan 4, 2024

Problem:
The Pay button in New Dot has seemingly two sets of options
Pressing the button brings up payment options
image

Pressing on the drop down brings up options to pay elsewhere
image

This UX is pretty confusing.

Solution:
Pull all the options into one single dropdown labeled Pay <currency><amount>, which when pressed opens for the user to choose:
Pay with business bank account
Pay with personal bank account
Pay with debit card
Pay elsewhere

  • Let's remember payment preference based on the first payment by request type. E.g. IOUs vs Expenses.

Said another way, if you paid an IOU using a debit card, then next time you pay an IOU, unless you pressed on the down caret (dropdown), we assume you mean the same payment device and process the payment with the debit card. But if you then pay an expense in a workspace, we don't assume but ask you to choose a payment method.

  • When defaulting payment method for expenses, use the workspace default if one is set in workspace settings.

If there is a default at the workspace level, and the admin has access to that, use that.

  • When defaulting payment method for expenses, make it workspace specific.

Said another way, if you pay an expense on workspace A, we default you to that payment device the next time (unless you press the dropdown). But then if you go to pay an expense on workspace B for the first time, we do not assume.

Copy link

melvin-bot bot commented Jan 4, 2024

Triggered auto assignment to @yuwenmemon (Engineering), see https://stackoverflow.com/c/expensify/questions/4319 for more details.

@yuwenmemon
Copy link
Contributor

  • When defaulting payment method for expenses, make it workspace specific.

Said another way, if you pay an expense on workspace A, we default you to that payment device the next time (unless you press the dropdown). But then if you go to pay an expense on workspace B for the first time, we do not assume.

Would this be the same for all admins on the workspace? Or would it be unique per admin?

@yuwenmemon
Copy link
Contributor

Oh, one more question - let's say you haven't paid using any of the options before (this is your first time paying) what do we do when you click the left side of the button? Do we show you a dropdown or do we default to some payment method?

@anmurali
Copy link
Author

anmurali commented Jan 5, 2024

let's say you haven't paid using any of the options before (this is your first time paying) what do we do when you click the left side of the button? Do we show you a dropdown or do we default to some payment method?

We show you a dropdown

Would this be the same for all admins on the workspace? Or would it be unique per admin?

So in Classic, policies have a default reimbursement account set in their policy NVPs. We only show the Reimburse button to admins with access to that BBA (or a copy of that BBA). In New Dot, this behavior is totally different and @luacmartins has a GH to refactor that. Once that's done, we need to figure out what changes we need to make so ND behaves like Classic as I just described, for workspace defaulted BBAs. More on this here, in Slack

@yuwenmemon
Copy link
Contributor

@luacmartins do you know if once that's done, all admins will have access to the default reimbursement account? Or, if not, what will admins who don't have access to the default reimbursement account be able to see/do?

@luacmartins
Copy link
Contributor

@yuwenmemon they should have access yea. That issue aims to make storing bank accounts in NewDot consistent with OldDot, so instead of storing the bank account in the FREE_PLAN_BANK_ACCOUNT_ID NVP, we'd store it in the workspace NVP.

@tgolen tgolen assigned tgolen and unassigned yuwenmemon Jan 17, 2024
@tgolen
Copy link
Contributor

tgolen commented Jan 17, 2024

I talked with @marcaaron on Slack and we decided to put this into the Wave9 unassigned bucket. I was able to make a little progress on it, so I am leaving a draft PR behind in hopes that it might be useful for whoever picks this up next. The PR contains:

  1. The functionality to have the button text be Pay <formattedamount>
  2. The options for the dropdown menu (with 90% complete conditional logic)

I left off trying to figure out what to do with the KYCPaywall and how that works... I'm not sure what needs to happen with it.

#34689

@tgolen tgolen removed their assignment Jan 17, 2024
@anmurali
Copy link
Author

@tgolen

I left off trying to figure out what to do with the KYCPaywall and how that works... I'm not sure what needs to happen with it.

I don't quite get this comment. We are just cleaning up the dropdown options such that there's one single menu of payment options when you press Pay -- we're not actually changing the behavior when you select Pay with Expensify, so why would you need to figure this out?

@tgolen
Copy link
Contributor

tgolen commented Jan 29, 2024

There are multiple sets of options as mentioned in the original description. One set of options is in front of the KYCPaywall (pay with expensify, pay elsewhere), and one set of options is behind the KYCPaywall (bank account, personal bank account, debit card). In order to have all options in a single dropdown, then the way the dropdown interacts with the KYCPaywall needs to be refactored.

@MitchExpensify
Copy link
Contributor

Closing in favor of: #36301

@melvin-bot melvin-bot bot added Reviewing Has a PR in review Weekly KSv2 and removed Weekly KSv2 labels Feb 24, 2024
@melvin-bot melvin-bot bot added Weekly KSv2 and removed Weekly KSv2 labels Mar 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Engineering Reviewing Has a PR in review Weekly KSv2
Projects
None yet
Development

No branches or pull requests

5 participants