To hide payment methods on Shopify based on the cart, you use a payment customization — a Shopify Function that Shopify runs server-side at checkout. Instead of editing theme code (which never controlled the payment step anyway), the Function reads the checkout against your cart rules and then hides, reorders or renames the available payment methods. Want cash on delivery gone above €500, your preferred card surfaced first, or a B2B-only method shown to company accounts? Those are all conditions the Function evaluates every time a shopper reaches checkout, so the rule holds consistently rather than depending on client-side JavaScript that the checkout ignores.
What you can actually do
A payment customization gives you three levers over the payment methods a shopper sees, all driven by conditions you define:
- Hide a method when the cart matches (or doesn’t match) a rule — remove cash on delivery above a threshold, hide a slow bank-transfer option for express orders, or drop a method in regions where it isn’t supported.
- Reorder methods so the ones you want used appear first. Payment order nudges behaviour; putting your lowest-fee or highest-trust option at the top is a quiet lever on cost and conversion.
- Rename a method’s label to something clearer than the default — for example clarifying terms, currency or a company-billing note.
The key word is conditionally. These aren’t global on/off switches (Shopify already has settings for that). A Function lets the decision depend on the specific cart in front of the shopper.
How it works: a payment customization Function
Shopify exposes a payment_customization Function target. Your Function receives the
checkout — cart lines, total, buyer identity, shipping address, and the list of available
payment methods — and returns a set of operations: hide, move (reorder) or rename. It
runs server-side at checkout, which is the whole point. The payment step of Shopify
checkout is controlled by Shopify, not your theme, so this is the supported layer to change
what appears there.
Mechanically, the Function is deployed inside a Shopify app (a custom or private app you build, or one a developer builds for you), and then activated as a payment customization in Settings → Payments. Once active, it applies to every checkout automatically — no per-order work, no snippet to maintain. If you’re new to this model, our primer on what Shopify Functions are covers the mechanics, and Shopify app vs Shopify Function explains how the Function lives inside an app.
Use cases and examples
| Rule condition | Example | What the Function does |
|---|---|---|
| Cart total | Order over €500 | Hide cash on delivery to cut chargeback / refusal risk on high-value orders |
| Region / address | Shipping to a remote area | Hide COD or a method unsupported in that region |
| Delivery choice | Express shipping selected | Hide slow offline payment methods that would delay dispatch |
| Preferred method | Any cart | Reorder so your lowest-fee card or wallet appears first |
| Low-margin cart | Cart is mostly clearance items | Restrict an expensive payment method to protect margin |
| Customer / company | Logged-in B2B company account | Show net-terms / invoice-style options, hide consumer-only methods |
| Product type | Cart contains a pre-order item | Hide methods you don’t want charged before fulfilment |
A few of these deserve a note. Cash on delivery above a value is the single most common request — COD carries refusal and handling cost, so many merchants cap it. Reordering to surface a preferred method is underrated: it costs nothing and steers shoppers toward your cheapest or most reliable option. B2B / company-specific options rely on buyer identity being available at checkout, which fits Shopify’s B2B model where customers belong to a company; the Function can branch on whether a company is attached.
Why a Function is the right layer
Payment methods live in Shopify’s checkout, and checkout is controlled by Shopify — not by your Liquid theme. That’s why theme edits and storefront scripts can’t reliably hide or reorder them: any DOM hack either doesn’t reach the payment step or gets wiped when Shopify re-renders checkout. A payment customization Function, by contrast, is evaluated by Shopify itself at the moment of checkout, so the rule is enforced, not decorated.
This mirrors the pattern for the delivery step. If you also need to control shipping options, the same server-side logic applies — see how to hide Shopify shipping methods, which uses the sibling delivery-customization Function. And if your rules are really about whether the cart is allowed to check out at all (minimums, combinations, restricted items), that’s a validation concern covered in Shopify minimum order and checkout validation.
Implementation notes (read these before you scope it)
- You need a Function inside an app. A payment customization isn’t a theme setting or a no-code toggle in the box — it’s code deployed as a Shopify app and activated in Payments. That usually means a custom/private app or a developer build.
- Check your plan. Payment customization Functions run on standard Shopify plans, but some deeper checkout customizations — particularly editing checkout UI via checkout extensibility / Checkout Blocks — are gated to Shopify Plus. Hiding, reordering and renaming payment methods via a Function is broadly available; anything that also restructures the checkout page itself is where Plus tends to matter. Confirm the exact scope against your plan before you commit.
- Test across scenarios. The failure mode is a rule that hides too much — for example hiding every method for some cart and leaving the shopper unable to pay. Test each condition and, critically, the combinations: high-value + COD region, express + offline method, B2B + guest. Always guarantee at least one payable method remains.
- Method names and IDs change. Reference payment methods by their stable identifiers where possible, and re-verify after you add, remove or rename a gateway, so a renamed provider doesn’t silently slip past your rule.
Common mistakes
- Trying to do it in the theme. Liquid and cart-page JavaScript don’t govern the payment step. If you “hid” a method with CSS, it’s still selectable at checkout.
- Hiding all methods for an edge-case cart. Every rule needs a fallback that leaves a valid way to pay. Miss this and you block the sale entirely.
- Confusing hide-payment with block-checkout. If the goal is to stop an unqualified cart, that’s a validation Function, not a payment customization. Different target, different job.
- Assuming it’s plan-free at every depth. Basic payment customization is widely available; full checkout UI extensibility can require Plus. Scope first.
- Not re-testing after gateway changes. Adding or renaming a provider can move it out of your rule’s reach.
When to build it
Reach for a payment customization Function when a static payments setting can’t express your rule — when the right set of methods depends on the cart’s value, contents, destination, delivery choice or who the customer is. If you simply want a method off for everyone, Shopify’s native settings already do that; you don’t need code. But “COD only under €300,” “preferred wallet first,” or “net terms for company accounts only” are exactly the conditional cases Functions exist for.
Building one is a focused engineering task: a Function, deployed in an app, tested across your real cart scenarios. That’s the work our Custom Apps & Shopify Functions service does — and if you’re not sure which rules are worth enforcing, a free profit audit is a fast way to find the cost and risk leaks worth closing at checkout.
Want payment methods that follow your rules? Tell us the conditions — cart value, region, customer or margin — and we’ll build a payment customization Function that hides, reorders or renames methods at checkout. See Custom Apps & Shopify Functions or get a free profit audit.