Shopify 货到付款智能规则：按国家、邮编、购物车金额与客户标签控制 COD

对许多 Shopify 商家来说，货到付款一开始往往只是一个简单的开关：要么对所有人显示，要么彻底关闭。但这也是最快导致两种结果的做法：要么把优质客户拒之门外，要么承担本可避免的风险。

真正的解决办法不是取消 COD，而是控制它在什么情况下出现。比如，某位客户在配送记录良好的地区购买低价商品，与一位首次下单的客户在曾多次派送失败的邮编区域购买高价商品，显然不是同一种情况。如果一律显示 COD，或一律不显示 COD，本质上都是忽略了这种差异。

这正是 COD 可见性规则存在的意义。它不再是单一的开关，而是让店铺根据国家、邮编或邮政编码、购物车金额以及客户标签，决定哪些人一开始就能看到货到付款选项。本文将带你了解如何在 Progus COD Form & OTP SMS 中设置这些规则。

开始之前，最好先区分两个很容易混淆的概念。可见性规则决定客户是否能看到货到付款这一支付方式：如果某条规则针对某个国家、购物车金额或某类客户隐藏了 COD，那么该客户从一开始就不会进入 COD 结账流程。OTP 验证则是另一层机制，它发生在客户已经选择 COD 之后，用于验证其手机号是否真实；它不决定谁能看到 COD，而是验证已经看到该选项的人是否可信。这两者是按顺序配合使用的：先用可见性规则缩小范围，再用 OTP 验证筛查剩余订单。想全面了解它们如何与重复违规者黑名单配合使用，可参考 Progus 的 COD 欺诈与退货滥用指南；本文重点讲解的是可见性规则这一层的设置。

第 1 步：先启用规则功能，再开始配置

在创建规则之前，必须先启用规则构建器。在 Progus COD Form & OTP SMS 中，进入应用的 Checkout 部分，选择哪一种运费方式应被视为 COD，并开启结账中的 COD。完成这一步之前，规则页面不会显示新增规则选项，而是会提示“configuration required”。

第 2 步：先确定你真正需要哪些控制条件

在创建规则前，先想清楚这条规则要解决什么问题。这个应用不是只有一个开关，而是允许你根据国家、邮编或邮政编码、购物车金额和客户标签来显示或隐藏 COD，而且一条规则中还可以同时组合多个条件。

以下是几个常见的起点：

• 高客单价订单保护：当购物车金额超过设定阈值时隐藏 COD，让高风险订单必须使用预付结账。
• 邮编排除：在主要国内市场保留 COD，但对那些经常派送失败或退回发货地的邮编区域隐藏 COD。
• 可信客户例外：使用客户标签，让有良好签收记录的回头客即使在更严格的通用规则下，仍然可以继续使用 COD。

下面第 3 到第 5 步会分别介绍这些控制条件。你不必全部使用，只需选择与你当前问题最匹配的条件即可。如果你的套餐一次只允许启用一条规则，也可以把多个条件合并到同一条规则中（第 7 步会详细说明）。

在编写任何规则之前，请先基于数据，而不是凭感觉判断：查看究竟是哪些国家、邮编区域或购物车金额区间，真正存在 COD 派送失败或欺诈的模式。靠猜测制定规则，很可能既拦住坏客户，也误伤好客户。确认问题所在后，优先采用小范围排除，而不是大面积限制：排除确实有问题的具体邮编，通常比限制整个地区更安全；对超过明确阈值的订单金额区间做限制，也比因为少数坏单就关闭整个国家的 COD 更合理。

规则构建器还支持更多条件，例如是否使用折扣、订单重量、客户注册状态、下单次数、客户邮箱、商品集合、购物车中是否包含礼品卡，以及用于定时或季节性规则的日期范围。即使本文不展开讲解，这些条件也值得了解。例如，日期范围条件可以只在某个促销期间限制 COD；订单重量条件则可以根据物流复杂度，而不只是价格，来控制 COD 的可用性。

第 3 步：设置国家和邮编条件

国家。这是最基础的控制条件。有些店铺只在国内提供 COD，因为本地配送网络更可靠、退货也更容易处理，而国际订单则默认使用预付。也有些店铺正好相反：在预付信任度低、转化率低的市场启用 COD，而在不需要 COD 的市场关闭它。

邮编或邮政编码。仅按国家控制通常过于粗放。即使在同一个国家，不同地区的配送可靠性、退回发货地比例以及快递覆盖情况也可能差异很大。如果一家店铺的 COD 问题只集中在少数几个邮编区域，就没必要限制整个国家，只需针对这些具体区域处理即可：要么排除已知高风险邮编，要么只在有成功派送记录的邮编中开放 COD。

国家和邮编都属于同一个 Location 条件类别。这意味着你可以在一条规则中实现：先允许某个国家使用 COD，再排除其中那些多次派送失败的特定邮编，而不需要拆成两条规则。

另外，应用的防欺诈模块也提供独立的邮编屏蔽功能，同时还支持按邮箱、手机号和 IP 地址屏蔽，并限制同一客户在一定时间内可下单的次数。这个工具更偏向于拦截已知的恶意用户，而不是调整整体 COD 可见性。因此，同一家店铺可能会在两个地方都用到邮编：在这里的规则构建器中用于更广义的可见性控制，在防护设置中用于更精准的欺诈拦截。

第 4 步：添加购物车金额限制

高金额订单一旦 COD 派送失败或被拒收，带来的绝对风险更高：商品成本暴露更多，运费损失更大，利润空间也更容易被吞噬。因此，常见做法是为 COD 设置一个购物车金额上限，超过阈值后必须使用预付结账。这样，风险最高的订单就能在发货前先确认付款。

如果你的套餐可用规则数量有限，可以把这个条件作为 Order Details 条件，与位置条件放在同一条规则里；如果套餐支持无限规则，也可以单独为它创建一条规则。

第 5 步：用客户标签区分可信买家与高风险买家

国家、邮编和购物车金额这些条件，都是在店铺尚未真正识别买家之前就生效的。客户标签则不同，它让规则能够根据“这个买家是谁”来做判断：例如，为有良好 COD 签收记录的客户打上标签后，即使其他条件较严格，也可以继续向他们开放 COD；而对曾经拒收或派送失败的客户打上标签后，也可以在后续限制其使用 COD，而不会影响其他正常客户。

客户标签位于同一个规则构建器的 Customers 类别下，与注册状态、下单次数和客户邮箱等条件并列。标签不只是用来限制，也很适合用来做例外放行：即使某条更宽泛的规则本来会限制 COD，可信的老客户仍然可以通过标签继续使用 COD，这样忠诚客户就不会因为针对陌生买家的规则而被误伤。

第 6 步：测试“显示”和“隐藏”条件如何一起生效

如果一条规则同时包含“show”和“hide”条件，应用会给出警告，因为这里有一个必须提前了解的固定优先级：show 永远高于 hide。只要“show”条件匹配成功，它就会覆盖“hide”条件。

例如，一条规则可能对某个特定邮编隐藏 COD，但同时又对带有 [trusted-cod] 标签的客户显示 COD。那么，带有该标签的客户即使位于隐藏邮编中，仍然可能看到 COD。这种设置有时很有用，但前提是你是有意这样设计的。因此，在默认认为“hide”一定会生效之前，务必先测试这种组合。

第 7 步：上线后持续复查规则效果

六个月前存在配送问题的邮编，现在未必仍然有问题。规则一旦长期不复查，就很容易从“精准解决真实问题”慢慢变成“在没有现实原因的情况下限制客户”。因此，最好提前设置提醒，定期检查规则表现，而不是只在初次配置时看一遍。

该功能在应用中显示为 Smart checkout rules。你能查看或新增多少条规则，取决于所用套餐：Free 和 Basic 只允许 1 条启用中的规则，因此复查的重点是确认这唯一一条规则是否仍然组合了正确的条件；Standard 和 Premium 支持无限规则，因此复查时要看是否有规则已经过时，或在多条规则并行后变得重复。

常见错误

1. 为几乎没有销量的市场写规则。 如果某个国家一年只有寥寥几单，把大量配置精力花在限制它上面，通常不如先把国内市场或主要市场的规则做好。
2. 在一条规则里堆太多条件。 条件一多，规则就会变得难以理解，也更难在出现异常时排查问题。对于支持无限规则的套餐，拆成多条更简单的规则通常更容易维护。对于 Free 或 Basic 这种只能启用一条规则的套餐，重点应放在一条聚焦明确、只组合最高影响条件的规则上。
3. 忘记测试移动端。 无论规则是显示还是隐藏了什么，都要确认最终的结账页面在手机上显示正常，因为大多数依赖 COD 的流量，往往都是在移动端完成转化或流失。
4. 从不检查规则到底拦住了什么。 如果一条规则在较宽泛的条件下悄悄隐藏了 COD，而团队又没人去看受影响的订单，它就可能在无人察觉的情况下压低真实转化。

配置检查清单

当智能 COD 规则运行良好时，通常会符合以下几点：

• 规则基于店铺真实的配送与欺诈数据，而不是凭印象判断哪些市场或地区风险高
• 邮编排除足够具体，而不是变相排除整个地区
• 针对高风险订单金额设置了购物车阈值，并且这个阈值是根据真实订单数据复核过的，而不是拍脑袋决定
• 客户标签不仅用于限制高风险客户，也用于保护可信的回头客
• 有人会按固定周期复查规则效果，而不是只在初次设置时查看

最后总结

货到付款并不一定只能“全开”或“全关”。通过可见性规则，店铺可以在真正能带来价值的场景中保留 COD，把犹豫中的买家转化为已完成订单；同时，也能在那些更容易产生风险的国家、邮编、购物车金额区间和客户历史中，有针对性地收紧 COD。

目标不是让 COD 变得稀有，而是让它只出现在真正有效的场景里，并在已经证明效果不佳的场景中不再出现。如果货到付款是你 Shopify 结账流程的一部分，Progus COD Form & OTP SMS 可以帮助你在一个地方完成整套配置，从 COD 可见性规则到仍需确认订单的 OTP 验证。