Translated shipping methods break targeting in checkout extensions

Hi folks,
I wanted to flag an issue we’re running into when accessing shipping methods in checkout through checkout extensions.

As you may know, shipping method titles and descriptions can be translated using translation apps. This has an unfortunate side effect.

Say a merchant sets up a flat rate called “Home delivery” in their shipping settings, then uses a translation app to translate it to “Delivery to home”. In checkout, the customer sees “Delivery to home”, and the checkout extension also receives “Delivery to home” as the value. The problem is that once the order comes through, the Admin API reports the shipping method as “Home delivery” - the original, untranslated name.

This mismatch makes it difficult to reliably target a specific shipping method from a checkout extension, since the value we see at checkout doesn’t match what ends up on the order.

You might suggest we build a lookup table to map translated names back to their originals, but that’s hard to maintain in practice. We’d have to cross-reference each translated value we see at checkout against the table, and keep the whole thing in sync as merchants add methods, change translations, or enable new languages. That’s a lot of fragile overhead to work around something the platform already knows.

My ask: could the checkout extension receive the original (untranslated) shipping method name instead of the translated one? That would make it much easier to target specific shipping methods from checkout extensions.

Thanks!

Payment methods customizations have this exact same problem ever since it came out.

This is a great ask! I’ll forward it to our Checkout UI Extension and Functions teams :slight_smile:

By the way, the delivery API exposes a handle and a code, and neither is localized. Does matching on one of those work for your case at all?

Thanks for looking into it!

You’re right, code is in fact original, unlocalized value! But only in checkout targets. In purchase.thank-you.block.render it’s an empty string. Seems like bug?

You’re right, it shouldn’t be returning an empty string there, that definitely looks like a bug. I’ll look into it on our end and update this thread once we’ve shipped a fix.

Just a heads up that this has been classified as a lower priority task, so it may be a while before it’s resolved.

Noted! Appreciate transparency, Paige! :folded_hands: