Block checkout and cart block UI while express payment method is processing

[ricardo]

Is your feature request related to a problem? Please describe.

While using the Payment Request Button in Stripe, the UI is blocked by the Payment Request API dialog or Apple Pay dialog, but after the payment is confirmed, there's a small delay until you get redirected to the Order received page. This allows shoppers to be able to click the Payment Request Button again, leading to bad UX.

There's also a bigger delay when you use 3D Secure cards like 4000002500003155, after you authorize the transaction and wait for a response.

If you click the button again before the confirmation + redirect, it prevents the window.location change. So you might get stuck at the checkout page after the order has been processed.

More information in this GitHub thread.

Describe the solution you'd like

The credit card payment button gets blocked when you use the express payment method, but the same should apply for all payment methods, even after the Payment Request API processing has completed, but still waiting 3DS confirmation.

For express payment methods, perhaps adding an overlay mask would suffice.

Any design inputs are welcome.

[nerrad]

@vivialice this would be a good one to get your design input on. Basically we need some way to indicate loading state for the entire express payment method area while checkout is being processed. The screen below shows the current behaviour that Ricardo describes in this issue (watch for the period after the 3DS confirmation is clicked and before the redirect, you'll see that the "Buy Now" express payment button has an active state and there's no indication that something is being processed:

Another option we have here is to scroll the window down to the checkout submit button which does have a loading indicator. But given the express payment buttons are clickable during this process, it might still be good to have some sort of mask or otherwise over them?

This would also be applied similarly when express payment methods are used in the cart.

[ricardo]

Something like this could work. But as @nerrad mentioned in the original GitHub thread, ideally we should block all available payment methods.

loading-indicator.mov

[ricardo]

As a side note, I think the button should also be blocked while the cart is being updated, like in the shortcode cart.

shortcode-cart.mov

block-cart.mov

[vivialice]

Hey! I wanted to clarify something first - if you're using express checkout, do you need to use the checkout CTA? Or does it go to order confirmation when the payment is complete? @ricardo @nerrad

[nerrad]

Goes to order confirmation when the payment is complete - the only exception is if there is an error, at which point the shopper would be placed back into the base checkout flow.

[vivialice]

Thanks for clarifying @nerrad! In that case, there are a few things I'd recommend doing.

Either way, the payment button(s) should be disabled so the payment process can't be disrupted. We can grey out the UI (how it is when the modal opens) and show the spinner over the buttons like in the Apple pay example or we can do a full overlay like on the old checkout when the cart is updated as demonstrated in @ricardo 's video above.

Ideally you'd have more of an indication something is happening, ie "Your payment is being processed, please don't hit back or refresh until it is complete" on some sort of intermediary screen. Not sure if we have any existing patterns on this to reuse - a modal, overlay, or a view?

Do we currently show anything if there's an error?

[ricardo]

Ideally you'd have more of an indication something is happening, ie "Your payment is being processed, please don't hit back or refresh until it is complete" on some sort of intermediary screen. Not sure if we have any existing patterns on this to reuse - a modal, overlay, or a view?

I think we don't have any existing pattern like that to reuse.

Do we currently show anything if there's an error?

Yes. We display an error notice.

[nerrad]

Either way, the payment button(s) should be disabled so the payment process can't be disrupted.

Agreed.

We can grey out the UI (how it is when the modal opens) and show the spinner over the buttons like in the Apple pay example or we can do a full overlay like on the old checkout when the cart is updated as demonstrated in @ricardo 's video above.

Showing a spinner over the buttons would likely require payment methods to do themselves (which would hand over control for this state to payment methods). However I think it'd be better to keep control in the main checkout flow so doing an overlay might be the way to go here. For reference, the overlay you were seeing is something Stripe itself adds as a part of the 3DS flow (not something blocks does).

Not sure if we have any existing patterns on this to reuse - a modal, overlay, or a view?

Besides what's in the current shortcode flow behaviour we don't (I'm not sure we should be preserving that specific style though).

---

Re @ricardo :

As a side note, I think the button should also be blocked while the cart is being updated, like in the shortcode cart.

At one point there was more of an indicator that something was happening (the "Proceed to Checkout" button would be disabled). There might be a regression here.

There's also a bit of overlap with #3751 and some of the design discussion around improving loading state for express payment methods.

[vivialice]

Besides what's in the current shortcode flow behaviour we don't (I'm not sure we should be preserving that specific style though).

I'm not sure this is a C&C decision or something the Payments team wants to consider as part of their overall flow? I'm not opposed to implementing this but we do have a solution that works for now potentially (overlay option).

[nerrad]

Okay we'll go with implementing an overlay solution for cart and checkout blocks and see how that works.