Hide, rename and reorder payment methods on Shopify (the supported way)

Merchants ask for this constantly: “Hide cash on delivery for prepaid customers,” “Put Shop Pay first,” “Rename ‘Credit card’ to something clearer.” For years the only way to do it was fragile checkout hacks that broke on every platform update. That is no longer the case — payment customization is now a supported, native capability.

Here is what is actually possible, and how it works.

What you can control

Shopify exposes payment methods as an extension point, which means you can change how they behave at checkout with supported logic rather than workarounds. Specifically, you can:

• Hide a payment method based on conditions
• Rename a payment method so it reads the way you want
• Reorder methods to put your preferred option first

The important word is conditions. The real value is not hiding a method for everyone — it is hiding, renaming or reordering based on the cart, the customer, or the shipping address.

The conditions that make it useful

A few patterns we build again and again:

• Hide cash on delivery above a cart value, for certain products, or for customers who have a history of refused deliveries.
• Reorder by margin or preference — surface the method that costs you least in fees, or the one customers convert best on, at the top.
• Rename for clarity — “Credit / Debit card” instead of a vaguer label, or localised names per market.
• Restrict a method by region using the shipping address, so an option only appears where it actually works.

Each of these is a rule: if [condition], then hide / rename / reorder [method]. That maps directly onto how payment customization is built as a Shopify Function.

How it is built

Under the hood this is a payment customization Function — a small piece of code running at Shopify’s payment extension point. Because it runs on Shopify’s infrastructure, it is fast and it does not break when Shopify updates the checkout. This is the same class of technology that replaced Checkout Scripts, so if you built payment rules in the old Script Editor, this is where they move.

You can configure simple cases in the Shopify admin, but anything with real conditional logic — multiple rules, thresholds, customer or address checks — is code, and it is worth having it written to handle the edge cases cleanly.

The limits worth knowing

A few honest constraints:

• Payment customization changes how methods are presented and gated. It does not invent new payment providers or move money differently.
• Some methods (like accelerated wallets) have their own display rules that interact with your customization — worth testing rather than assuming.
• Rules run at checkout, so they see checkout-time data. If your condition depends on information Shopify does not have at that moment, the rule cannot use it. Knowing where that line sits is half the job.

Why do it properly

The reason this matters is not cosmetic. The wrong payment method in front of the wrong customer is friction — an option that will not work for their region, a confusing label, or a method that costs you margin sitting at the top of the list. Payment customization removes that friction with rules that run natively and reliably.

If you want a specific set of payment rules built and tested against real carts, that is exactly what we do — and it usually sits alongside broader checkout customization work.