Cash on Delivery risk isn't evenly spread across your customers — it concentrates in the orders you have the least information about. A first-time buyer with no order history is a bigger unknown than someone who's completed three orders with you already, but Shopify's checkout treats them identically unless something tells it otherwise — and, as it turns out, order history is not something any rule can read while a buyer is checking out.
The native way
Shopify's payment customizations can hide a payment method based on a handful of built-in conditions — cart contents, shipping destination, cart total. On eligible plans, that's the correct native tool for a checkout-level payment restriction.
Where it breaks
None of the native conditions read a customer's order history — whether this is their first purchase or their fifteenth simply isn't one of the available conditions, no matter which plan you're on.
Why no app can read order count at checkout either
This is the part most articles on this topic get wrong, so it is worth being precise.
Shopify caps how much data a rule may read while a buyer is actually checking out. Everything a checkout rule looks at has to fit inside one input query, and that query has a hard complexity budget. A customer's past order count does not fit — not because apps are lazy about it, but because the budget is already spent on the cart, the address and the customer's identity.
So if you find an app promising to hide a payment method based on order history at checkout, be sceptical, and test it on a real order before you trust it. A rule built on a condition Shopify will not evaluate does not error — it simply never fires, which looks identical to a rule that is working and finding no matches.
Ruleproof states this on the rule itself rather than letting you discover it in production: a condition that cannot run at checkout is labelled as such while you are writing it.
The proxy that does work: guest versus signed-in
Whether the buyer is checking out as a guest is available at checkout, and it is the closest usable signal:
If the customer is checking out as a guest → hide Cash on Delivery.
Because it's a rule:
- Signed-in customers keep COD. A customer with an account who signs in is recognised at checkout and keeps COD — no manual list to maintain.
- Combine with cart total. Restrict COD only above a value where the risk is actually worth avoiding, and leave small orders unaffected.
- Preview and monitor. Test it as a guest and as a signed-in shopper before it's live, then run it in monitor mode to see exactly how many real orders it would have restricted.
It is not the same predicate, and it is worth being honest about the difference: a returning customer who does not sign in looks like a guest, and a first-time buyer who creates an account does not. What it captures is "we know nothing about this person right now", which is the risk you were actually trying to price.
Sizing it with the data you can see
Order count is unavailable at checkout, but it is not unavailable everywhere. Two things you can still do:
- Monitor mode will tell you how many real orders the guest rule would have affected, before you switch it on, so you are not guessing at the trade.
- Tagging happens after the order, through the Admin API, where the order-count limit does not apply. Rules2Tag can tag customers by their real order count for segments and email flows — just not in time to change a checkout that is already happening.
Which should you use?
If your store's COD risk is genuinely spread evenly across every customer, a simple cart-total restriction may be enough. If it concentrates in buyers you know nothing about, the guest rule is the honest version of what you were reaching for — and Ruleproof lets you write it as a sentence, preview it on a guest and a signed-in shopper, and monitor it before it changes a real checkout.