Automattic / woocommerce-payments

Accept payments via credit card. Manage transactions within WordPress.
https://wordpress.org/plugins/woocommerce-payments/
Other
173 stars 69 forks source link

Stripe Link payment with account having saved payment methods #7791

Closed frosso closed 9 months ago

frosso commented 11 months ago

Description

I am a customer, with saved payment tokens & I want to use Stripe Link. The saved CC payment token will appear as the default selected one on the checkout, which is good. Screenshot 2023-11-27 at 1 45 21 PM

Once I select Stripe Link as a payment method by clicking the "link" icon on the email field, and I opt to autofill, the saved token is still the selected payment method. Screenshot 2023-11-27 at 1 46 11 PM Screenshot 2023-11-27 at 1 47 08 PM

Instead, I would expect Stripe Link to be selected Screenshot 2023-11-27 at 1 47 20 PM

Acceptance criteria

When a customer selects "Stripe Link" as a payment method, Stripe Link becomes the selected payment method.

Designs

Testing instructions

Dev notes

Additional context

timur27 commented 9 months ago

Clarifying another use-case UX within the same area

This is a bit unrelated to the scope of this issue, but I've noticed something and can act on it here.

For a non-registered (in the Stripe Link system) user, clicking the Link button within the email input element doesn't lead to any changes when the saved payment token is chosen by default. As a user, I'd instead expect at least new payment token fields to be displayed so that I can add card details and get the save to Link checkbox in case my email is not registered. Instead, this button is now pretty non-functional when a saved payment token is selected by default, and users only see the save to Link checkbox once they manually select the new payment token.

One small drawback of fixing it (see the second recording) would be that for the registered users when they click the Link button within the email element, they see the Stripe Link autofill modal (which is expected), but also, the selected payment method switches from the saved payment token to the new payment token (card details). It's not a big downside because they'll see the same if no saved tokens are present on the checkout page, but still, I find it worth mentioning. Below are current and proposed behavior.

https://github.com/Automattic/woocommerce-payments/assets/22319444/6bb6da97-9a64-4524-9852-4aed7b33a70f

https://github.com/Automattic/woocommerce-payments/assets/22319444/559d6dd6-09ee-47e7-b3fa-d323a34d4f7a

@FangedParakeet, are we considering this as needing further discussion with the product and/or design, or does the nature of the improvement allow us to implement it straight away? It also covers only shortcode checkout, because with Blocks, we render the Link button only when the card element fields are selected. Thanks!

frosso commented 9 months ago

@timur27 that's a great observation!

FangedParakeet commented 9 months ago

For a non-registered (in the Stripe Link system) user, clicking the Link button within the email input element doesn't lead to any changes when the saved payment token is chosen by default. As a user, I'd instead expect at least new payment token fields to be displayed so that I can add card details and get the save to Link checkbox in case my email is not registered.

I agree with this and the proposed behaviour displayed in your second video seems logical and appropriate to me.

are we considering this as needing further discussion with the product and/or design, or does the nature of the improvement allow us to implement it straight away?

I'm willing to continue here with your behaviour proposal without pausing to ping design. I think if a user clicks the Link button, they indicate that they would like to proceed with a checkout using Link--be that using a registered payment method or registering a new one--and we should not conceal the path forward, if they select this action.

In terms of scope creep, I hope that the current resolution can be somewhat reused, just with the new trigger of the Link button select, in addition to the autofill trigger suggested in the original issue. Let me know if you foresee any further friction with including this functionality or if you think it might be better solved in a separate issue though. 🙏

One small drawback of fixing it (see the second recording) would be that for the registered users when they click the Link button within the email element, they see the Stripe Link autofill modal (which is expected), but also, the selected payment method switches from the saved payment token to the new payment token (card details).

I think this is natural and don't see this as too detrimental, unless I'm misunderstanding anything. If the user would like to continue using Link in any capacity, they will not be able to use their saved CC payment tokens and AFAIA we will have to select the new payment method option in either case. 🤷

timur27 commented 9 months ago

Thanks all for the input!

@FangedParakeet regarding the scope change: it's almost invisible, and https://github.com/Automattic/woocommerce-payments/pull/8017 already implements the proposed behavior on top of fixing the initial issue w/o a lot of additional work.

timur27 commented 9 months ago

I've found yet another edge case related to this topic, this time in Blocks checkout. Scenario

  1. save a payment method and open Blocks checkout afterward - Link button is not appearing, the selected element is saved card
  2. switch manually to the new payment method element - Link button now appears and is fully usable
  3. switch back to the saved payment method - Link is still on page and when clicking it it doesn't behave as expected

I'd fix it, but because there are two options, I'm bringing it here. The first option is to fix the button that appears on the page after switching from the new payment method to a saved payment method. This way, when clicking on the button, we'll switch from saved to new payment method automatically, as we do in shortcode checkout. The second option is to disable the Link button when switching to the saved payment method. This would align with the initial behavior after we open the page.

timur27 commented 9 months ago

Following up on https://github.com/Automattic/woocommerce-payments/issues/7791#issuecomment-1892418841: I decided to fix this behavior by implementing the second solution (remove the Link button when switching back to the saved payment method) for two reasons:

  1. the behavior is in line with experience on opening the page
  2. going with the first option (keep the link button when the saved payment token is selected) has a limitation because Blocks function in the way that payment elements are re-rendered on every click. The button should be assigned to a payment element. Since the payment element does not exist (when we choose saved payment token), there's nothing we can assign the button to. That's also the reason why, in Blocks, we're not rendering the button unless we choose the card element. To solve this, we could create a new button that will be responsible just for a click & opening cc elements, and then we'd use the separate logic to set up Stripe Link, but it's clear the work here is way more complex than with the option I chose with just disabling the button when switching to saved payment methods.

@FangedParakeet, please let me know if you think we need to align on anything further. I currently have the fix implemented and will polish it a bit in the meantime.

frosso commented 9 months ago

disable the Link button when switching back to the saved payment method

@timur27 to clarify - by "disabling" the Stripe Link button, do you mean:

EDIT: looking here, it seems that the button is removed. All good 👍 https://github.com/Automattic/woocommerce-payments/pull/8017/files#diff-94d342a0f23678b924afd5eeed0d5b56f830d13c2a08173d018b9433906b6b31R42-R49

timur27 commented 9 months ago

@frosso remove the button from the UI by stripeLinkButton.remove(). Once we open the card element again, the right button with the correct attachment to the PE will be created.