By default, the first shipping method is selected when the list of shipping methods is displayed. However, if the shipping methods are reordered by shipping delivery function, the system does not automatically update the selection to reflect the cheapest option. This may result in a higher-cost option remaining selected by default.
Hi @Chi_n_Nguy_n_Van 
- generally, we display the least expensive shipping rate by default at checkout:
Could you let us know where youâre seeing this behaviour pop up? Is this in a output from a Function run or within an Extension UI? Happy to dig into this further to see if we can confirm expected behaviour.
Hope to hear from you soon!
Thank you for your response Alan_G.
As mentioned above, this behavior occurs when merchants use the Delivery Customization function to reorder their shipping options.
You can take a look at my record: https://youtu.be/jjvXRXy1FKw
In my record, when a buyer navigates to the checkout page, the first shipping option is automatically selected, which is why this behavior appears.
Thanks @Chi_n_Nguy_n_Van , that does definitely look odd, appreciate you sending that my way. Would you be open to sharing your extension code with me? Weâd just need the basics in order to replicate what youâre seeing (so you can remove any non-essential code if needed there).
If youâd prefer to share that info with me via a private message, thatâs cool too. I can set that up on my end if needed and reach out to you that way.
Hope to hear from you soon!
All matters should be clear based on the image provided. I am only using the payment customization function to reorder the shipping options from:
to:
As previously mentioned, Shopify selects the first shipping option by default. Therefore, in this case, the most expensive option (Shipping option 2) is automatically selected (instead of the Free shipping option)
I would simply like to confirm whether you or your team can improve this behaviorâspecifically, to ensure that the cheapest shipping option is selected by default after all delivery customization functions have been applied, or if there are any other recommendations or solutions.
Thanks for clarifying @Chi_n_Nguy_n_Van , just wanted to see if I could replicate the behaviour exactly. Iâll look into this for you on my end and share next steps once I have more info. Speak with you again as soon as I can.
Hi @Chi_n_Nguy_n_Van - just following up with some info here after confirming some things with the team. At the moment, the function doesnât override the default selection behaviour, essentially, it just renames, sorts, or hides options depending on what you set.
The default behaviour is that if a buyer hasnât yet made a selection, the selected option will be the cheapest of the options returned after your customisation has ran. However, if the buyer has made a selection, weâll attempt to retain that selection after the customisation has ran, so I wonder if thatâs potentially happening here. If not, let me know and Iâd be happy to keep digging into this (if youâre able to share any repro code that would be super helpful as well if we need to investigate further) .
Hope this helps 
For my record, I accessed the checkout page for the first time using an incognito window, ensuring no previous session or local storage interference. However, I noticed that the first shipping option was automatically selected, instead of the cheapest shipping option, which I expected.
This unexpected behavior is the reason Iâm reporting the issue to you and your team.
And here is my delivery customization function code:
function run() {
return {
operations: [
{
move: {
deliveryOptionHandle:
"65888ee8b6c7c5fe045f9b2e0e57eaf1-c3e090203786bc2e8bb3ca305acd7816",
index: 1,
},
},
{
move: {
deliveryOptionHandle:
"65888ee8b6c7c5fe045f9b2e0e57eaf1-6058796404e38ca1cabdcb4ec7f9ef8e",
index: 2,
},
},
{
move: {
deliveryOptionHandle:
"65888ee8b6c7c5fe045f9b2e0e57eaf1-0032a34caa898da7178d58bd34dfa31c",
index: 3,
},
},
],
};
}
with function input:
{
"cart": {
"attribute": null,
"cost": {
"subtotalAmount": {
"amount": "700.0",
"currencyCode": "VND"
}
},
"deliveryGroups": [
{
"deliveryAddress": {
"city": "",
"countryCode": "VN",
"provinceCode": null,
"zip": null
},
"deliveryOptions": [
{
"handle": "65888ee8b6c7c5fe045f9b2e0e57eaf1-80ec4a7496a2dd1c91ac653b79c996f6",
"title": "Free shipping",
"cost": {
"amount": "0.0"
}
},
{
"handle": "65888ee8b6c7c5fe045f9b2e0e57eaf1-0032a34caa898da7178d58bd34dfa31c",
"title": "Shipping option 1",
"cost": {
"amount": "10.0"
}
},
{
"handle": "65888ee8b6c7c5fe045f9b2e0e57eaf1-c3e090203786bc2e8bb3ca305acd7816",
"title": "Shipping option 2",
"cost": {
"amount": "12.0"
}
},
{
"handle": "65888ee8b6c7c5fe045f9b2e0e57eaf1-6058796404e38ca1cabdcb4ec7f9ef8e",
"title": "Shipping option 3",
"cost": {
"amount": "20.0"
}
}
]
}
]
}
}
Thanks @Chi_n_Nguy_n_Van , Iâll see if I can replicate this with your Function implementation there. I really appreciate you sending this our way.
Thank you for taking the time to review and follow up with me. If you need anything further, please donât hesitate to let me know.
Hey @Chi_n_Nguy_n_Van - thanks for your patience. I believe I was able to replicate the behaviour youâre seeing here on my test shop with a text extension. Iâll do some further investigation into this on my end to confirm if this is expected behaviour and loop back with you once I have more info to share though. Speak with you as soon as I have that info on my end
Thanks for your patience while I looked into this, wanted to reach out to share a confirmed answer here.
I can confirm that what youâre seeing is actually the expected behaviour. When a delivery customization function reorders shipping rates, whatever rate ends up in position 0 (the first position) becomes the default selected rate, regardless of its price.
Hereâs how the flow works: Shopify initially sorts rates by price with the cheapest option first. Then your delivery customization function runs and can reorder those rates using move operations. Whatever rate ends up in position 0 after your function runs becomes the default selection. The important part here is that no re-sorting happens after the function runs.
So in your example, if youâre reordering from Free shipping at the top to having Shipping option 2 at the top, Shipping option 2 will be selected by default even though itâs more expensive. This is working as designed.
I definitely realize this isnât ideal, but hopefully this clarifies the behaviour youâre seeing. Let me know if you have any other questions about this. More than happy to help out further.
Hi @Alan_G
Just wanted some clarification as to why app requirement #20 exists (apps cannot reorder shipping options that increases the default shipping price).
Some merchants offer options such as âship using my own accountâ where they bill shipping to the customerâs UPS/Fedex account directly and thus do not need to collect shipping whilst checking out, or deferred options such as âconsolidate my orders and ship laterâ where they again may offer a free option, but these options are certainly not the preferred option for most of their customers, as such there is a need for merchants to ensure a rate other than the cheapest is selected as default otherwise it causes a massive headache when customers do not read the shipping rate that is selected as default carefully and ends up checking out with the incorrect option (this happens a lot, especially with shopify shipping hiding the other options by default too).
This is a feature many merchants have asked for, with our Free app Shipping Rate Power Toy, we have thousands of merchants who use the re-ordering feature for this very purpose, preventing them from doing so is causing significant headaches for a lot of merchants.
Hey @Min_Liu 
- thanks for raising this, and totally get where youâre coming from here.
That requirement, from our side, essentially means apps canât reorder shipping rates in a way that causes a higher-priced shipping rate to become the default, if that makes sense.
The main reason for that requirement is to avoid buyers being defaulted into a more expensive shipping option without explicitly choosing it themselves.
That said, I definitely get the use case youâre describing here. Flows like âship using my own accountâ or âconsolidate and ship laterâ can absolutely be valid merchant-preferred options, even if they arenât the cheapest, and I can see why having the wrong option selected by default would create headaches.
If these merchant workflows are being surfaced as standard shipping rates, then I can definitely see how that creates friction with the current requirement. Iâm happy to pass this along as feedback though, since the use case you described makes sense and itâs helpful context around why merchants want more control here.
Hope that helps clarify things a bit. Please feel free to ping me here with some more details on your use case â I canât guarantee anything, but Iâm happy to advocate on my end here.
