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

[Legacy Checkout] No shipping method option on checkout prevents completing the order and leads to Stripe charges #9614

Closed
filipefurtad0 opened this issue Aug 31, 2022 · 6 comments
Labels
bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround.

Comments

@filipefurtad0
Copy link
Contributor

filipefurtad0 commented Aug 31, 2022

Description

Aggregates #8219 and #9610.
Relates to #8974.

A shipping methods can be hidden from by:

  • setting as back-office only
  • using tags

If no shipping method is eligible for a given customer, then:

Legacy checkout - If a customer reaches the final stage of checkout and places the order without having an active checkout method then the checkout will fail. The user will see a first generic error messages: The checkout failed. Please let us know so that we can process your order, and then, when reattempting, another generic error message: Payment could not be processed, please check the details you entered.

If Stripe is used as a payment method this will lead to charges, although the order is not completed.

Split-checkout - the user cannot proceed to further steps, and can't really place the order - this is a good thing 💪

Expected Behavior

Under discussion, see below.

Actual Behaviour

Legacy checkout: Even if a user does not see any shipping method available, it is able to proceed to checkout, and place the order, which will lead to error unclear error messages and Stripe cards being charged.

Split checkout: Even if a user does not see any shipping method available, it is able to proceed to checkout, but cannot proceed to the next step in the checkout flow.

Steps to Reproduce

  1. As a hub, set up a order cycle/shop, making it ready to order.
  2. As a hub, set all shipping methods to back-office only, or set the appropriate tags to hide shipping methods from a given customer.
  3. Legacy checkout: As the customer, place some items in the cart, and proceed to checkout.
  4. Repeat step 3 for split-checkout.
  5. See the scenarios described in the Actual behavior and the respective screenshots below.

Animated Gif/Screenshot

image

Workaround

None, for the customer.

Severity

bug-s3: a feature is broken but there is a workaround
Keeping the severity from the most recent issue #8219.

Your Environment

  • Version used: v4.2.9
  • Browser name and version: Firefox 103
  • Operating System and version (desktop or mobile): Ubuntu 22.04

Possible Fix

@filipefurtad0 filipefurtad0 added the bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround. label Aug 31, 2022
@audez
Copy link
Collaborator

audez commented Sep 1, 2022

Hi, thank you for this @filipefurtad0 ✨ A small feedback: it looks like paying with bank card didn't automatically lead to charges: I tested to pay twice with bank card (I think it was with two separate carts, so two different requests), but only one payment made it through Stripe. On the day of testing, there were two pending payments on my bank account, but only one payment appeared in Stripe. Weird!

We told the producer to make refunds on Stripe - which is not easy because for most of the payments there were no emails associated..

Details on how refund works on Stripe:

  • Stripe’s fees on the original payment will not be returned in case of a refund
  • The client always receive a total refund. It's the recipient - in this case, the producer - who will pay the Stripe's fees (according to Stripe support it will be immediately taken from its balance, or debited from next payout).
  • If the refund is issued shortly after the original charge, it will appear in the form of a reversal instead of a refund. That means that nothing will appear on the client's bank account (that was my case, in the beginning I could see two pending payments on my bank account, but now I see nothing - as if nothing happened)
  • Stripe support indicated that even in the case of a reversal, the Stripe's fees will be paid by the recipient, but that's not what we observe on our producer's account (as for now the fees weren't debited)

@RachL RachL added bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround. and removed bug-s2 The bug is affecting any of the non-critical features described in S1 and there is no workaround. labels Sep 1, 2022
@RachL
Copy link
Contributor

RachL commented Sep 1, 2022

Thank you @filipefurtad0 ! I think we have a clear documentation ❤️ . I don't think we can make the shop appear as closed because you can also end up with no shipping methods using tags... #9536 will add a proper message. I'm not sure we can do much more. Or do we have other ideas? So I think we can close here?

@audez there are some delays before you can see everything appearing on Stripe and / or each stakeholders bankaccount. These delays also occurs in order for Stripe to only take the final correct action and not handle too many bank movement. That's why also payouts do not appear right away.

@audez
Copy link
Collaborator

audez commented Sep 1, 2022

IMO this could be split in 3 issues:

What do you think?

@filipefurtad0
Copy link
Contributor Author

Thanks for all the feedback! I've updated the issue (Expected behavior = open; Severity = s3).

Or do we have other ideas? So I think we can close here?

Maybe adding a clear message on the legacy checkout (similar to #9145) + disabling the checkout button? I'm not sure we are still investing time fixing issues on legacy checkout. If not, agree to close - please feel free to 👍

I don't think we can make the shop appear as closed because you can also end up with no shipping methods using tags

Right, I keep forgetting this is used by some hubs to display products, as you've mentioned here. It feels clunky to me, but no strong opinion on this.

Prevent the shop manager to put all shipping methods in "backoffice only"

I'm not sure we'd really prevent that, but perhaps add a warning? Would be a new feature, but seems useful to me.

PS:

that was my case, in the beginning I could see two pending payments on my bank account, but now I see nothing - as if nothing happened

@audez let's not test the app with real payments ☣️ moving the discussion into #testing

@audez
Copy link
Collaborator

audez commented Sep 4, 2022

Yes true, I think I lost a piece of thinking brain in the emergency stress... 😬☠️

After more research and according to comments on this and other issues ( #5423, #5559, #8219, #9145, #5950, #1343), I tried to summarized and was stroke with a writing fever.. Please feel free to comment or edit!

———————————
There are 4 cases when the admin config will not allow the users to checkout:
Case 1: no payment methods available as they're all set to “back-office only”
Case 2: no shipping methods available as they're all set to “back-office only”
Case 3: no shipping methods available as they're hidden for users with certain tags (but available for others)
Case 4: the shipping method category doesn't match the product category
———————————
The case of not being able to checkout because all payment or shipping methods have been deactivated doesn't seem possible anymore: I tried to uncheck the last active payment or shipping method, without success..but maybe i'm missing something?
———————————
CASES 1 & 2
For consistency reasons, it would be great having the same behavior for cases 1 and 2.

Warning the user
It corresponds to “Display only shopfront” described in the user guide and in #5559: the shop shows as closed but products are displayed. Customers can't checkout.

Warning the shop manager
Wishlist:
#272 Display a warning message to shop managers when they choose a config that will prevent checkout

———————————
CASE 3 & 4
It seems different than the 2 previous ones, as the orders are available for some but not for all. So it doesn't sound good to display the shop as closed..I'd say: display a warning message to users as soon as they land on the shop, for ex:
“Orders on this shop are currently not possible due to this shop configuration. You won’t be able to access checkout page.” + don't allow access to checkout page (same as for cases 1 & 2)

But for now these 2 options don't seem to work:
Case 3: to be written
Case 4: #9629

@RachL
Copy link
Contributor

RachL commented Dec 7, 2022

I'm closing the original isse: we won't fix legacy checkout now, let's focus on getting split checkout out 👍

@RachL RachL closed this as completed Dec 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug-s3 The bug is stopping a critical or non-critical feature but there is a usable workaround.
Projects
None yet
Development

No branches or pull requests

3 participants