WooPay button appears on zero total orders

[peterwilsoncc]

Describe the bug

On zero total orders (eg 100% Off discount code) the Apple and Google Express Pay buttons are removed from both the Cart and Checkout pages.

The WooPay button remains in place on Checkout pages in an enabled state. Following the WooPay flow prevents payment as the place order button is disabled on the pay.woo.com

To Reproduce

1. Create Simple Product
2. Create 100% Discount Coupon
3. Enable WooPay express pay button
4. Purchase product
5. On the cart apply the discount code (cart total will be zero)
6. On the cart (shortcode) page the woopay button is present but disabled (expected)
7. Continue to the checkout (shortcode) page
8. On the checkout (shortcode) page the woopay button is enabled
9. Click WooPay
10. Complete WooPay flow until it comes time to palce the order
11. Observe the Place Order button is disabled

When using checkout (blocks)

6. On the cart (blocks) page the woopay button is not present (expected)
7. Continue to the checkout (blocks) page
8. On the checkout (blocks) page the woopay button is not shown (expected)
9. Remove coupon code
10. On checkout (blocks) page the woopay button is shown (expected)
11. Purchase the product via WooPay
12. Return to the Sample Product, add to cart
13. On the cart (blocks) page apply the 100% discount coupon
14. Click through to the checkout (blocks) page
15. As the cookies have been set, the WooPay popover will show and an SMS be triggered

Actual behavior

WooPay is enabled and leads to a dead end, unable to place order of zero total cart.

Screenshots

(Don't worry about the street address in these screen shots, it's the Automattic office address)

WooPay button on Checkout (shortcode) page

WooPay Payment screen showing disabled "Place order" button

Zero total order upon return to checkout (block) page

Expected behavior

Either:

• The WooPay button should be disabled for zero total orders
• The WooPay popover should not show for zero total orders if the cookies are set

Or:

• pay.woo.com allows for the placing of zero total orders

Desktop (please complete the following information):

• OS: macOs
• Browser Chrome 120

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context

[RadoslavGeorgiev]

This issue impacts WooPay's express checkout buttons, so assigning to Heisenberg (based on team responsibilities Pc2DNy-3z-p2) @Automattic/heisenberg

Assigning as part of Gamma Triage process PcreKM-yM-p2.

[pierorocca]

Curious why express payment methods can't be used on $0 purchases. Contact and address information is still required and an express payment button can be the faster, higher converting choice for signed in users.

[pierorocca]

@nikkivias we don't think there's a technical limitation here. I'm thinking that all express payment buttons should be available for use, even for $0 transactions to facilitate rapid contact and address info. Coupon codes, gift cards, etc. can be applied or removed at any time and hiding and unhiding buttons would be quite awkward. What are your thoughts?

[peterwilsoncc]

@pierorocca The issue I'm seeing is that the WooPay button disables the place order button for zero total orders so there is no way for the user to make a purchase once redirected. Refer to the first screen shot above.

[pierorocca]

Missed that one, thank you.

[pierorocca]

@frosso let's check if there's a $0 limitation for Apple and Google Pay and to your point the cost associated with transacting a $0 transaction may not make sense which is why it may have been removed.

@nikkivias if WooPay is the only one technically capable of handling a $0 transaction, should WooPay behave differently than the other PRBs?

[csmcneill]

This is similar to #5406, which was opened as a result of this conversation. This was resolved in #6334.

Per the merchant, rendering PRBs on $0 products/carts caused confusion for customers because a $0.00 order paid via an EPM still shows the payment method used, so customers believed they were being charged for something that they thought was free:

I did test and all works fine if you checkout with GPAY and a balance of 0.00, but lots of users question it... why make me give a credit card when its free? why use google pay for free item?? guess they feel its only used when they owe... need to make the checkout as smooth as possible with no 'hiccups' :-) make em happy!

To me, this makes sense. Why use Google Pay if nothing is being paid for — but I also understand the increased conversion aspect, too.

[frosso]

@pierorocca Samir helped me test this out - I need to revisit what I said: it is indeed technically possible to make a $0 transaction in test mode with GPay with the shortcode checkout, if we clean up some checks made in the backend.

Does @csmcneill 's insight change the approach we'd want to take with $0 orders & wallets?

[pierorocca]

Thanks @csmcneill. Good info. I've checked Stripe and Google's docs and even messed about with Google's jsfiddle implementation and I don't see a way to suppress the credit card or the word "Pay". So for Google and Apple, yes these are best removed from view for $0 transactions. I also see that Google has dialed back their plans on GPay as a sort of budgeting/purchase tracking tool like Mint.

@nikkivias for WooPay and $0 transactions, do you have a perspective? I think WooPay can do better and differentiate over PRBs. Bear with me as I lay out a case that WooPay is not a wallet and thus can deal with $0 in an elegant and desired way.

There are two paths to get into hosted checkout: 1) clicking the WooPay button and 2) once we implement Direct Checkout, clicking "Proceed to Checkout" will send authenticated WooPay shoppers to hosted checkout, which is a superior converting checkout.

Scenario 1: Landing on WooPay Checkout with amount already totaling $0 - shopper has applied discounts or gift cards on store
Here contact and shipping address are pre-populated, payment method would be hidden, shipping options would still be available, and total would be $0. "Place Order" even for $0 transactions is appropriate copy. We would not call Stripe but would create the order in the store AND WooPay would record the order/have access to the order data. Very important.

IF the shopper changes the shipping speed and now the order is no longer $0, the payment method can be made visible and the shopper can choose from their selection of stored cards. This will convert higher than standard checkout.

IF the shopper decides to remove the discount, gift card, or points redemption, and the total is now >$0, Pay With can be made visible and the shopper can choose from their selection of stored cards. This will convert higher than standard checkout.

Scenario 2: Landing on WooPay Checkout with amount not yet totaling $0 - shopper has not yet applied discounts or gift cards on store

It is a very likely scenario that a consumer waits until checkout to apply all gift cards or coupon codes. Here a shopper lands on hosted checkout with a $100 total and applies at 10% discount and then applies $90 in gift card balance. WooPay can support the WooCommerce Gift Card extension, better than standard checkout can. At that point, the total is updated to $0, the pay with section is hidden, and "Place Order" as above is good copy for $0. Should the shopper decide to remove some or all of the gift card balance, Pay With reappears. Once order is placed, WooPay as above has access to the order data to populate the order history in one central place and data we want in the future to drive "merchants you might like" or "products you might like" recommendations. It's also helpful to have that purchase history centralized even for free - but not really free because a prepaid gift card was applied - in cases where a shopper wants to return the item for a refund. I want WooPay to be the first place a shopper goes to find that order history.

Thoughts?

[pierorocca]

cc @bborman22

[pierorocca]

FYI I actually think we support scenario 2 already @alefesouza?

[pierorocca]

Yes, we support scenario 2 today, thus I'd expect scenario 1 to work too.

[pierorocca]

And if I use a 100% off coupon, I have no problem placing a $0 order.

What's weird to me is that we hide, rather than disable the Google or Apple Pay buttons. It's a bit too much visual change but that's my personal preference. Per the reasons given above and since WooPay can without problem handle a $0 transaction, the WooPay button should be visible.

Ideally the Google Pay and Apple Pay buttons disable on $0. WooPay remained enabled. No visual shifting on the screen because a shopper can change options to render a non $0 total, at which point the buttons would then render and could push the screen down/up.

@nikkivias what's your perspective?

https://d.pr/v/yrv9zJ

[nikkivias]

Hey @pierorocca sorry for taking a while to chime in here. I appreciate you laying out possible scenarios at play here. Given that scenario 2 already exists, I don't see a reason why Scenario 1 shouldn't either because they would both be creating the same transaction in the end— just the means of getting there is different.

When reading this whole thread, the only thing that was on my mind is trying to figure out is if there's any legal complications here (IDK I'm just trying to challenge assumptions here, and that's the only thing I could come up with hehe)

What's weird to me is that we hide, rather than disable the Google or Apple Pay buttons.

It's usually best practice to hide an element that can't be used unless displaying it disabled serves some purpose.

It would be a bit weird for the Google & Apple to disable/hide but the WooPay not, but I'm making the assumption here that the shopper wouldn't think too much of it if it doesn't prevent them from checking out anyway. The Direct checkout scenario is most ideal once that is available.

[pierorocca]

It's usually best practice to hide an element that can't be used unless displaying it disabled serves some purpose.

@nikkivias 100% agree for elements that can never be used. Is this true for conditional scenarios? For example we don't hide Continue buttons, rather disable them until the condition is met. For variable products, the PRBs are visible and not disabled and trigger an alert if the conditions are not met. I'm not opposed to hiding Gpay and Apple Pay buttons. Pointing out that the buttons could show, disappear, and re-appear depending on the sequence of events and if a shopper applies and removes points, gift cards, etc.

[pierorocca]

To summarize the various threads:

1. WooPay can and should support $0 transactions. We want to be in the data flow and want the order history in the WooPay Shopper Homepage order history.

2. Currently, the WooPay button and GPay or Apple Pay are hidden on the Cart, but visible on Checkout for a brief moment during the WooPay auto-redirect. Checking out as a guest and going back to the store, all the buttons are hidden.

3. WooPay must be visible on the Cart and Checkout at all times even for $0. Apple Pay and Google Pay must be hidden for $0 on the cart and checkout. If the dollar value is >$0 at any time the buttons should become visible.

[nikkivias]

Is this true for conditional scenarios? For example we don't hide Continue buttons, rather disable them until the condition is met.

Generally, it's good practice to hide elements that are not usable. The disabled continue button is a nuanced exception because it plays the key role of providing the current system status, an important usability heuristic. It indicates that while the action (continuing) is recognized, certain prerequisites have not been met. This is more informative than if the button were missing entirely.

[pierorocca]

Bumped this up to high priority as it's appearing in support tickets and since this is now a year old.

@a-danae could we get some urgency on this issue please?

[pierorocca]

Per @malithsen:

For zero-dollar orders:
In NUX flow the place order button doesn't show up at all.
In returning user flow, place order button shows up but it's disabled.

[pierorocca]

Noting that we DO want to support WooPay on all $0 orders including free trial simple and variable subscriptions (must be signed in for subscriptions for button to render).

[alefesouza]

Closing as we will continue to display WooPay button for $0 total orders ( #9846 (comment) ).

[pierorocca]

@alefesouza I think the bug here where the place order button is not functional though isn't captured anywhere unless it's solved by https://github.com/Automattic/woopay/issues/2224 but I think that's slightly different.

This original reported was suggesting either to not display the button, or if it is displayed that checkout is functional.