Impossible order due to order shipping method

[Cecilia-Hn]

A client try to order on an OFN shop (2236), when he arrived at the validation, the order is not finalised because of shipping method error :

[Cecilia-Hn]

We've got exactly the same behaviour for shop 1265

• The client go te the shop
• Select products
• Go to checkout
• Place order and the following message appeared

[filipefurtad0]

This might be occurring because those hubs have all shipping methods set to backoffice only, as an example:

The workaround could be to visit /admin/shipping_methods/<shipping_method_id>/editand set at least one shipping method as :

Another reason could be tags are being used and those customers don't see any options in the UI and click checkout.

It seems related to #6137

Bugsnag
https://app.bugsnag.com/open-food-france/coopcircuits/errors/61422936acb0e600075e8cf5?event_id=614a09750080d77bf5150000&i=sk&m=fq

If the workaround is confirmed I think we can then downgrade to S2.

[filipefurtad0]

This is confirmed in staging:
https://app.bugsnag.com/yaycode/openfoodnetwork-uk/errors/614a0e96f3fa8e0008cd2936?event_id=614a0e960080dd9956940000&i=sk&m=nw

The workaround of hubs setting at least one visible shipping method should work, downgrading to s2.

[Cecilia-Hn]

Thanks a lot @filipefurtad0, this is it, I panicked !

[filipefurtad0]

Thank you for reporting! 🙏

[RachL]

I don't think we want to fix this as an s2, there is a clear workaround. I'm downgrading 👍

[filipefurtad0]

It seems that if the customer tries to checkout, on a hub with shipping methods set to backoffice only and uses Stripe as a payment method:

• that user will see the snail / error 500
• the payment goes through -> seen on Stripe Dashboard as authorized and captured (!)
• if the user then navigates back (using the back button of the browser) a new payment for that order can be submitted
• again, it appears in Stripe as completed
• the order remains in state payment

This pic is taken from staging-UK. But it could explain issue #8218, and that order with 13 payments... What do you think?

[lin-d-hop]

Note that this can also happen when shipping methods are set to have specific shipping categories and items in the order do not align with the categories (eg a shipping method that does not accept refrigerated produce but the order contains refrigerated items.)

Just posting in case someone searches for this in the future.

[filipefurtad0]

I've investigated this a bit further: So far I see three potential scenarios in which shipping methods can be hidden from checkout. I had another look to see how each scenario is impacted by different payment methods:

1. non-matching shipping categories

when shipping methods are set to have specific shipping categories and items in the order do not align with the categories

I've tried to reproduce that scenario @lin-d-hop , but could not hide shipping methods from the checkout screen in this way. Is this expected? If so I can open an issue on it. Checkout proceeded as usual despite non-matching categories between products and shipping methods. Maybe I'm missing something here...

2. setting as backoffice only (as mentioned here)

With both Stripe and Paypal, the payments seem go through, but the user sees an error. We can see the successful payments on the respective dashboards (below Paypal):

Paypal however, prevents adding additional payments to orders, it displays this warning:

Stripe seems to allow adding more payments (dashboard below); So if a user re-attempts to checkout with a different or same card chances are, these attempts are charged. The type of card used with Stripe seems to make a difference on whether the payment is captured or not:

card x-3184 -> generates a captured payment
card x-3155 -> generates an uncaptured payment

I have no explanation for this; I think these test-cards should only differ in terms of how often you are prompted about authentication.

This is seen here:

With a cash payment method, the payment does not go through and the order remains in state cart, with no payments added:

3. hiding shipping methods with tags

pick up shipping method seems to be assigned by default - although not displayed to the user - and checkout proceeds with all payment methods: the user gets redirected to the order confirmation screen, no error is displayed. Random assignment of shipping methods seems to be reported in this issue.

[filipefurtad0]

I think we just had another occurrence here: https://openfoodnetwork.slack.com/archives/CEF14NU3V/p1632759072058900, scenario 2) with cash/check.

[filipefurtad0]

Additional data, from the feedback from CA here:

Different card types generate slightly different outcomes (card x-3184, card x-3155 described above):

• x-4242 - valid no 3D-auth required -> checkout fails for the customer, payments go through on Stripe and OFN:

[filipefurtad0]

Closed in favor of #9614.