WooCommerce Conditional Shipping and Payments

Not every shipping method or payment gateway makes sense for every order. A store shipping heavy furniture does not want local pickup showing up for a customer three states away. A store selling both digital downloads and physical goods does not want a shipping calculator running on an order with nothing to ship. WooCommerce Conditional Shipping and Payments, the official extension from WooCommerce.com, solves this by letting you write rules that hide or show specific shipping methods and payment gateways based on what is actually in the cart.

Most stores discover the need for this the hard way, after a customer places an order with a shipping method that cannot physically handle the product, or after a fraud review flags a high-value order that should never have had Cash on Delivery as an option in the first place. Fixing it reactively costs a refund and a support ticket. Fixing it with a rule costs five minutes.

What the Extension Actually Controls

Two separate rule engines live inside this one extension: shipping method restrictions and payment gateway restrictions. Both work the same way structurally, you define a condition (cart total, product category, shipping destination, customer role, and several others), then attach an action to it (hide this shipping method, disable this payment gateway) that only applies when the condition is true. Rules stack, so a store can run several independent restrictions at once without them interfering, as long as the conditions do not directly contradict each other.

This is different from WooCommerce’s native shipping zones, which restrict shipping methods by geography alone. Conditional Shipping and Payments adds cart contents, order value, product attributes, and customer account status as additional conditions layered on top of zones, giving you rules that zones cannot express by themselves.

When Native WooCommerce Settings Are Enough (And When They Are Not)

Before installing anything, it is worth knowing what core WooCommerce already handles without an extension. Shipping zones restrict methods by destination. Payment gateway settings can restrict a gateway to specific countries under that gateway’s own configuration. Product shipping classes let you set different shipping costs for different product types within the same zone.

What core cannot do on its own: hide a payment gateway based on cart total (Cash on Delivery for orders under $50 but not above), restrict a shipping method to a specific product category regardless of destination (in-store pickup only available for a furniture line, not accessories), or gate a payment method by customer role (a bank transfer option available only to logged-in wholesale accounts, hidden from retail customers). Any rule involving cart contents, order value thresholds, or account type rather than pure geography is where the extension becomes necessary rather than optional.

If your need is genuinely limited to one narrow rule, a simple free shipping minimum, for instance, WooCommerce’s built-in free shipping method already supports a minimum order amount without any extension at all, configured directly in the shipping zone’s method settings. Reach for the full extension once you need more than one condition type, or conditions that reference something other than order value and destination.

The Conditions You Can Combine

Each rule can chain several condition types together with AND/OR logic rather than relying on a single check. The condition categories worth knowing before you start building rules:

Condition Category	What It Checks	Typical Use
Cart value	Subtotal or total, above or below a threshold	Free shipping unlocks, minimum order for wholesale terms
Cart contents	Specific products, categories, or tags present in cart	Freight-only shipping for oversized categories
Product attributes	Weight, dimensions, or custom attribute values	Blocking standard shipping on overweight items
Shipping or billing location	Country, state, or postcode	Region-specific payment methods beyond what gateway settings alone allow
Customer account	User role, logged in vs guest, specific user	Wholesale-only payment terms, guest checkout restrictions
Order history	Whether the customer has ordered before	First-order incentives or restrictions on repeat customers
Coupon applied	Whether a specific coupon code is active on the cart	Unlocking a payment method tied to a promotional campaign

Building Shipping Restriction Rules

Rules live under WooCommerce > Settings > Shipping > Restrictions once the extension is active. Each rule is built from a set of conditions joined by AND/OR logic, plus the shipping method it restricts.

Example: Free Shipping Above a Threshold

Condition: cart subtotal is greater than or equal to $100. Action: hide the standard flat-rate shipping method, leaving only free shipping visible once the threshold is met. This is a cleaner implementation than manually configuring WooCommerce’s built-in free shipping minimum in some setups, particularly when you want the flat-rate option to disappear entirely rather than simply showing both options side by side.

Example: Restricting Local Pickup by Product Category

Condition: cart contains a product from the “Large Furniture” category. Action: hide the standard shipping methods, show only local pickup or freight shipping. This prevents a customer from selecting standard parcel shipping on an item that genuinely requires freight, which avoids a shipping cost mismatch discovered only after the order is placed.

Example: Blocking a Shipping Method for International Orders Over a Certain Weight

Condition: shipping destination is outside your primary country AND cart weight exceeds a set threshold. Action: hide standard international shipping, forcing the customer toward a freight quote request instead. This catches an edge case that shipping zones alone cannot express, since zones only know about destination, not weight.

Building Payment Gateway Restriction Rules

Payment rules live under WooCommerce > Settings > Payments > Restrictions, structured the same way as shipping rules.

Example: Disabling Cash on Delivery for High-Value Orders

Condition: cart total exceeds $500. Action: hide Cash on Delivery, leaving only card and bank transfer options. This is a common fraud-prevention pattern, since COD on large orders carries more risk of a failed or refused delivery than smaller transactions.

Example: Wholesale-Only Payment Methods

Condition: customer has the “wholesale_customer” role (assigned through a membership or B2B plugin). Action: show a bank transfer or purchase-order payment option that stays hidden from standard retail customers. This lets a single storefront serve two different customer segments with genuinely different checkout expectations without building a separate site.

Example: Restricting Digital-Only Orders From Certain Gateways

Condition: cart contains only downloadable products (no physical shipping required). Action: hide payment methods that only make sense for larger, shippable purchases, like invoice-based net-30 terms, reserving those slower payment flows for orders that already involve fulfillment lead time.

Example: Seasonal Payment Method Availability

Condition: order falls within a specific date range configured for a promotional financing partner. Action: show a buy-now-pay-later gateway only during the window that partner’s promotional terms are actually valid, then automatically revert to the standard gateway list once the promotion ends without needing to remember to manually disable it. This is a smaller but genuinely useful case for stores running seasonal financing offers tied to a fixed campaign window.

Walking Through a Multi-Condition Rule

A single rule combining several conditions handles most of the real scenarios stores actually run into. Take a wholesale storefront that wants to offer net-30 invoicing, but only to verified wholesale accounts, only on orders above a $250 minimum, and only within the country the warehouse ships from domestically. Building this as one rule rather than three separate ones keeps the logic in a single place to review and update later.

1. Add a new payment restriction rule and give it a clear internal name, something like “Net-30 wholesale eligibility,” not a generic label you will not recognize in six months.
2. Add the first condition: customer role equals wholesale_customer.
3. Set the logic connector to AND, then add the second condition: cart total greater than or equal to $250.
4. Add a third condition with AND logic: shipping country equals your domestic country code.
5. Set the action to show the net-30 invoicing gateway (which should otherwise be hidden from all customers by default in the gateway’s own settings, so this rule is the only path that reveals it).
6. Save, then test as a wholesale test account below the threshold (gateway should stay hidden), above the threshold (gateway should appear), and as a retail account above the threshold (gateway should stay hidden regardless of cart value).

Compatibility With Block Checkout

WooCommerce’s shift to the block-based Cart and Checkout blocks changed how some legacy extensions render their restrictions, since the block checkout uses the Store API rather than the older shortcode-based checkout template. Conditional Shipping and Payments has been updated to support the block checkout in current versions, but if you are running an older release alongside a block-based checkout page, verify your rules actually hide gateways and shipping methods correctly rather than assuming compatibility. Test by adding a qualifying product to the cart and confirming the restricted option is genuinely absent from the block checkout’s payment and shipping panels, not just from the legacy shortcode checkout if you happen to still have one active for testing.

Testing Rules Before Going Live

A rule that looks correct in the settings screen can behave unexpectedly once real cart combinations hit it, particularly when multiple rules are active simultaneously. Before publishing any new restriction, build a small test matrix: a cart that should trigger the rule, a cart that should sit just under the threshold and not trigger it, and a cart combining this rule’s condition with any other active rule to confirm they do not conflict. Use a test customer account matching each role your rules reference, since role-based restrictions cannot be verified from an admin account alone.

Auditing Rules as Your Catalog Grows

Stores that start with two or three simple rules often accumulate a dozen or more over a year or two of promotions, category launches, and shipping policy changes, and rules referencing categories or products by name rather than ID are the first ones to silently break during a catalog reorganization. Keep a running list outside the plugin itself, a simple spreadsheet is enough, documenting what each rule does, why it exists, and which category or product IDs it references. Review that list on the same cadence you review your shipping zones or tax settings, since an outdated restriction rule tends to fail quietly rather than throw a visible error, and the only symptom is a customer complaint about an option that should have been available but was not.

For stores with large catalogs and dozens of active rules, it is worth designating one person as the owner of the restrictions list, someone who reviews changes before they go live and signs off on removals. Restriction rules tend to be written once during a specific business need and then forgotten, and without a clear owner, nobody notices when a rule outlives the reason it was created.

Common Mistakes

Rules that leave zero valid payment or shipping options. If a customer’s cart satisfies a condition that hides every available shipping method, checkout breaks entirely with no path forward. Always confirm at least one method remains visible for every realistic cart combination your restrictions could produce.

Conflicting rules from different extensions. If you also run a separate shipping calculator plugin or a different payment-restriction tool, two plugins modifying the same checkout logic can produce unpredictable results depending on which one runs last. Where possible, consolidate restriction logic into this one extension rather than layering several similar tools.

Testing only as an admin. Admin accounts sometimes bypass restrictions that apply to regular customer roles, particularly with role-based rules. Always test as a logged-out guest and as a standard customer account, not just from the account you use to manage the store.

Forgetting to update rules after a product catalog change. A restriction built around a specific category ID or product will silently stop working, or worse, apply to the wrong products, if that category gets renamed, merged, or restructured later. Review active restriction rules whenever you do a significant catalog reorganization.

Writing overly broad conditions to save time. A rule scoped to “cart total over $0” instead of a genuine threshold effectively applies to every order, which defeats the purpose of a conditional rule and makes debugging harder later since a broad rule masks the more specific ones you actually intended to isolate a particular scenario.

Frequently Asked Questions

Does this work with digital and physical products in the same cart?

Yes. Conditions can check whether a cart contains only downloadable products, only shippable products, or a mix, letting you build rules specific to each scenario rather than treating every cart the same way.

Can I restrict a shipping method to specific countries and cart value at the same time?

Yes, by joining both conditions with AND logic in a single rule. This is one of the more common combined rules stores build: restricting a premium shipping method to domestic orders above a certain value, for instance.

Will restricted payment methods still appear briefly before hiding?

No, when configured correctly the restriction applies before the checkout renders, so a hidden gateway does not flash visible and then disappear. If you do see a brief flash, check for a caching plugin serving a stale checkout fragment rather than assuming the extension is misconfigured.

Does this extension replace the need for shipping zones?

No, it layers on top of zones rather than replacing them. Zones still handle the geographic restriction of which methods are available in which regions; this extension adds further conditions (cart contents, value, customer role) within whatever methods a zone already makes available.

Can rules apply differently to first-time customers versus returning ones?

Yes, order history is one of the available condition types, letting you build a rule that only triggers for accounts with no prior completed orders, or conversely, one that only applies once a customer has an established purchase history with the store.

What happens if two active rules contradict each other?

Behavior depends on rule order and how specifically each rule is scoped; broadly written rules can unintentionally override narrower ones if they both apply to the same method. Keep contradictory logic out of separate rules where possible, and if a genuine conflict is unavoidable, combine the competing conditions into one rule with explicit AND/OR logic rather than relying on rule priority to sort itself out correctly.

Is this the right tool for a store with only one or two simple restrictions?

Not necessarily. If the entire need is a single free-shipping minimum, the native shipping zone settings already cover that without any extension. The extension earns its cost once the rules involve more than order value and geography, roles, product categories, order history, or combined logic across several condition types at once.

Fewer Options, Better Fit

The value of conditional shipping and payment rules is not adding more choices at checkout, it is removing the ones that do not apply so customers see only what is genuinely relevant to their order. A shorter, more relevant checkout reduces confusion and cuts down on support requests about shipping costs or payment options that never should have applied in the first place. Start with the restriction causing the most confusion today, whether that is an oversized item showing standard shipping or a payment method that keeps getting selected on orders it cannot actually process, and build from there rather than trying to map every possible rule on day one.