Closed frosso closed 9 months ago
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.
@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!
@timur27 that's a great observation!
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. 🤷
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.
I've found yet another edge case related to this topic, this time in Blocks checkout. Scenario
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.
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:
@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.
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
@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.
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.
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.
Instead, I would expect Stripe Link to be selected
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