Hide COD Payment Method on Shopify (Functions Guide for High-Risk Orders)

For a long time, the only fraud control at checkout was "accept or reject the order." Binary choice: take the chargeback risk, or lose the sale entirely. Stores in COD-heavy markets faced this acutely — the most lucrative payment method (cash on delivery) was also the riskiest, and there was no graceful way to say "we'll serve this customer but only on prepaid options."

The introduction of Shopify Functions — specifically Payment Customization — changed the math. You can now hide specific payment methods from specific customers based on rules you define. The customer doesn't see the option that would have been risky for you; they're guided toward options that work for both sides.

This guide covers what payment-method hiding actually does, the COD-specific use cases, the rule patterns that work, and implementation on Shopify.

What payment-method hiding does

Shopify's Payment Customization API lets a Shopify Function evaluate the checkout context and conditionally hide payment methods. The customer doesn't see the hidden option; they choose from whatever remains.

The mechanics:

1. Customer reaches the payment step of checkout
2. Your Payment Customization function runs, with access to customer identity, cart contents, addresses, and order context
3. The function decides which payment methods (if any) to hide
4. Customer sees only remaining options and proceeds

The customer doesn't see an error or rejection. They just see a slightly narrower set of choices. From their perspective, COD might not have been available — but the rest of the store works normally.

This is the critical UX difference from blocking. Blocking generates support tickets ("why was my order rejected?"). Hiding generates almost no friction — the customer doesn't know what they didn't see.

Why this is the smart middle path for COD

The two extremes both have costs:

Accept all COD orders. You take non-acceptance, refused-delivery losses on the specific orders that go bad. Legitimate orders pay your costs back, but margin drains.

Block COD entirely. You eliminate the non-acceptance problem but lose every legitimate customer who only pays cash (60-80% of orders in SEA markets).

Payment-method hiding splits the difference. Risky customers are still allowed to buy — just on payment methods that don't expose you to non-acceptance. If they're legitimate, they use another method. If they're fraudsters or impulse-buyers who specifically needed COD, they probably abandon.

The conversion math works because most COD-preferring customers have alternative options. Fraudsters and impulse-refusers often don't — that's why they were trying to use COD.

The five COD-specific use cases

1. Hide COD for high-risk profiles

The biggest use case in COD markets. Hide COD for:

• Customers with prior non-acceptance history
• Orders shipping to addresses with prior non-acceptance
• First-time customers in high-non-acceptance districts
• Orders above a value threshold (typically $50-$80, varies by market)
• Customers placing orders without browsing (straight from social ad to checkout — impulse pattern)

2. Hide COD by district / postal code

Some districts have sustained 30%+ non-acceptance rates while others have <5%. Don't block the district — hide COD specifically for that district. Legitimate customers can still buy prepaid.

3. Hide COD by product category

High-value products (electronics, branded goods) have higher non-acceptance than essentials. Restricting COD to lower-value categories cuts loss.

4. Hide COD for high-velocity addresses

Multiple COD orders from the same address in a short window suggests coordinated abuse. Hide subsequent COD attempts; show prepaid only.

5. Reveal COD progressively

A new customer's first 1-3 orders might be prepaid-only. After successful deliveries, COD becomes available. Tiering builds the customer relationship while limiting risk.

Practical rule patterns

The rules that earn their keep cluster around customer-history, order-context, and risk-signal evaluation:

Customer-history rules

Use the customer's prior order history:

• "Hide COD if this customer has 1+ prior non-accepted COD orders"
• "Hide COD if this customer has had a chargeback in past 12 months"
• "Show COD if this customer has 3+ successfully delivered prior orders"

High-precision rules. A customer's own history is almost always a stronger signal than aggregate population statistics.

Order-context rules

Use specifics of the current order:

• "Hide COD if cart total above $80"
• "Hide COD if shipping address in known high-non-acceptance ZIP"
• "Hide COD if order velocity from this email above threshold"

These combine well with customer-history rules.

Risk-signal rules

Use signals from fraud-detection:

• "Hide COD if order risk score is medium or above"
• "Hide COD if IP geolocation differs from billing country"
• "Hide COD if email is from a flagged disposable-email domain"

Combined rules

The strongest patterns combine multiple signals:

• "Hide COD if [order value > $50] AND [first-time customer] AND [shipping address in high-non-acceptance district]"
• "Hide all payment methods except prepaid bank-transfer if [order flagged high risk] AND [no order history]"

Implementation on Shopify

Two main paths:

Option A: Use a fraud app (recommended)

Most fraud apps that support Payment Customization bundle a no-code rule builder. You configure rules through a UI; the app deploys the Shopify Function automatically.

Shieldy Fraud Filter includes payment-method hiding:

1. Hide Payment Methods → Add rule
2. Condition: select trigger (customer history, address match, risk score, district, cart value)
3. Action: hide specific payment method (Cash on Delivery, Credit Card, Gift Card, etc.)
4. Save

Rule fires immediately. Configurable per-region, per-product, per-customer-tag.

Option B: Write a custom Shopify Function

For engineering teams with specific requirements:

1. npm install -g @shopify/cli
2. shopify app generate extension --type=payment_customization
3. Write your function logic in Rust or JavaScript
4. Deploy via shopify app deploy

Heavier path. Worth it only if you need logic the no-code apps don't support — for example, integration with internal customer-risk databases.

Implementation considerations

Shopify Functions have specific constraints:

Performance. Functions run synchronously at checkout. Heavy logic or external API calls degrade performance. Pre-compute risk classifications outside the function and reference them inside.

Determinism. Same inputs should produce same outputs. Don't introduce randomness that could lead to different customers seeing different options for similar orders.

Information available. Cart, customer info, shipping/billing addresses, order context — yes. Arbitrary external state — no. Anything you want the function to use needs to be available as part of the order or pre-computed in metafields.

Rate limits. Like all Shopify Functions, Payment Customization has performance budgets. Exceeded functions are skipped — rules silently don't fire.

Common mistakes

A few patterns appear when stores first deploy:

Hiding too aggressively. Setting rules that hide COD for too broad a population — for example, hiding for all customers above $30 in a market where $30 is normal AOV. Result: most COD-preferring customers can't use their preferred method, conversion drops, merchant rolls back the rule entirely.

Hiding without measurement. Deploying without tracking what happens. Right setup involves measuring: how many orders had COD hidden? How did those proceed? What was conversion rate? Without metrics, rules can't be tuned.

Hiding without communication. A customer expecting COD who doesn't see it might assume your store is broken. A small note on checkout — "alternative payment methods may be available based on your order" — keeps them oriented.

Hiding without exception paths. Sometimes the legitimate customer genuinely needs the hidden method. Have a path — contact support, alternative checkout — to preserve the relationship.

Measuring impact

Three metrics tell you whether your setup is working:

Hide-rate. What percentage of orders had a payment method hidden? Compare to your overall risk-classification rate. If hide-rate is significantly higher than risk-flagged rate, rules are over-broad.

Conversion-rate-when-hidden. Among orders with a payment method hidden, what conversion rate completed? High rate suggests legitimate customers route successfully to other methods. Low rate suggests fraudsters who abandoned or legitimate customers who couldn't proceed.

Risk-rate-on-completed-orders. For orders that completed after a payment method was hidden, what was the eventual fraud or non-acceptance rate? Should be substantially lower than orders where nothing was hidden — that's the point.

Track all three monthly. Iterate the rules toward higher precision over time.

A practical first-month setup

If you're deploying payment-method hiding for the first time:

1. Identify your biggest payment-method-related loss. For COD markets: COD non-acceptance.
2. Configure a conservative rule addressing that specific loss. Don't try to cover all use cases day one.
3. Run for 30 days. Measure the three metrics above.
4. Tune the rule based on data. Tighten if hide-rate is too low; loosen if conversion degrades.
5. Add a second rule for next-biggest loss.

That sequence builds payment-method hiding into a working control over a quarter, each rule validated against actual data.

A practical close

For COD-heavy markets, payment-method hiding is the highest-leverage single fraud-prevention investment. It lets you keep COD available for the customers it works for, while routing the customers it doesn't work for to safer methods.

Shieldy handles this via Shopify Functions with a no-code rule builder. Setup is 15 minutes; the margin recovery in COD markets is typically 30-60% of prior non-acceptance loss within 60 days.