Default shipping rate selection

We have an app which uses delivery customisations to re-order shipping rates, this appears to be working correctly when testing but many merchants are complaining this morning that the first rate is no longer the default selection. I note on this recent thread: [Delivery Customization Function] The system does not automatically select the cheapest option by default when the shipping methods are reordered - #2 by Alan_G that this should be the correct behaviour.

My observations are for customers who have made a selection previously, this is now saved in a more persistent manner and made the default selection. However, merchants also note that customers that always checkout with say an express option (which is normally ordered to the top) is now checking out with a standard option because it is cheaper and selected as default.

I also note that for new customers, all shipping rates show at the checkout, but for a returning customer the rates are hidden and only the default selection is shown with the rest hidden in a dropdown.

Can anyone confirm what exactly has changed here and if these observations are correct? Is there a bug with the checkout where the default selection isn’t applying correctly?

Merchant Impact:

Merchants want to control which shipping rate is selected by default, even if a customer has already made a previous selection or purchase using another option.

2 Likes

The same bug on our side
The merchants are reporting this as a bug, and the re-ordering feature has become kind of useless at this point

The same issue is happening on our app. A LOT of merchants are complaining at the moment about this sudden breakage and saying the same that this reordering feature is useless without the top shipping method being preselected on the checkout, as most of the customer don’t bother to change the default shipping option and then merchants has to chase them trying to correct shipping option for their order. Imagine doing that for each of thousands of orders.

Hi folks - thanks for flagging this, the behavior described does appear to be caused by a change on our side. We made a recent update in the last few hours which should have reverted this. Can you confirm if you are seeing the expected ordering appearing now?

1 Like

Thank you
Yes, now it’s working as expected

Thank you, working our end too now.

Thank you, it is working as expected now.