A store may need to hide cash on delivery for a digital product, limit bank transfer to approved orders or restrict a gateway for a particular product category. Turning that gateway off everywhere is a different decision. Product-based restrictions should apply only when their conditions are met, and they should leave eligible customers with a workable checkout.
The difficult cases usually involve mixed carts, changing addresses and more than one checkout interface. This guide explains how to define a rule and test those cases before customers encounter them. For a simple store-wide switch, use our guide to disabling a WooCommerce payment method.
Write the rule as a customer scenario
Start with a sentence that describes the intended outcome. For example: when a cart contains a downloadable course, cash on delivery must not be offered. Then describe what should happen when that course is combined with a physical book. Without that second sentence, two people may configure different rules while believing they followed the same brief.
Record the affected product IDs or categories, the gateway, the reason for the restriction and the acceptable alternatives. Decide whether the condition means any matching item or every item in the cart. Specify whether variations inherit the parent product’s rule. Keep the wording independent of a plugin’s interface until the business decision is clear.
Identify the checkout your customers use
Check whether the store uses the Checkout block, a shortcode checkout or another checkout extension. Also list express-payment buttons that appear on product or cart screens. A rule that appears correct on one screen still needs verification on every route through which a shopper can place the affected order.
WooCommerce documents separate integration considerations for payment availability in Cart and Checkout blocks. Do not assume a PHP snippet written for an older checkout covers the installed interface. Ask the extension developer about the exact versions and checkout combination if its current documentation does not answer that question.
Prefer a supported restriction mechanism
Use the gateway’s own restriction settings when they meet the requirement. Otherwise evaluate a maintained conditional-payment extension that explicitly supports your checkout and conditions. Avoid hiding a payment option with CSS: changing what the browser displays does not establish that the underlying order rules are enforced.
The official Conditional Shipping and Payments documentation describes global and product-level restrictions. With that extension, product-level rules live in the product’s Restrictions tab, while global rules are managed under WooCommerce’s Restrictions settings. These controls belong to that extension; they are not a promise that every WooCommerce installation has them.
Its documented conditions within a restriction must all match for that restriction to activate. Multiple rules can represent alternative situations. Translate your written scenario carefully into that logic. A rule for a matching category and a particular country is narrower than two separate rules that each hide the gateway independently.
Build the smallest useful rule first
On a staging copy, configure one product and one gateway. Give the rule a descriptive internal name, such as “Exclude cash on delivery when a course is present.” Record the previous settings. Keep unrelated shipping, tax and gateway configuration unchanged so a failure has a manageable set of possible causes.
Add the restricted product to a fresh cart and check the available payment methods. Then remove it and verify that the gateway returns for an otherwise eligible cart. This reverse test matters: a restriction that activates correctly but never clears is still broken. Repeat after changing quantities or choosing another variation.
Test mixed carts and changing conditions
Use a small written matrix instead of relying on one successful order. Include a cart containing only the restricted product, one containing only an unrestricted product and one containing both. If the rule uses order value, test just below, exactly at and just above the boundary. State whether discounts, tax and shipping are included in that boundary.
For location-based conditions, begin with an empty address and then enter each relevant destination. Switch the address again after selecting a gateway. For shipping-based conditions, switch between delivery and collection where available. The available payment methods should reflect the final cart and checkout state, not a choice made earlier in the session.
Include guest and signed-in customers if account status matters. Test a returning customer with a saved payment method as well as a new customer. Subscription renewals and payment for existing orders may follow different paths from a new purchase, so treat them as separate requirements when the store offers them.
Make the restricted state understandable
If hiding a gateway leaves no payment route, decide whether the cart should be prevented earlier or whether another permitted method should be offered. Do not silently leave the buyer at a dead end. Explain the actionable next step without exposing internal fraud rules or unnecessary operational details.
Notice behaviour can differ between checkout types. For example, the official extension documentation identifies a limitation for static notices beneath excluded gateways in the Checkout block. Check the current documented behaviour and the actual output. A message configured in an administration screen is not proof that customers can see it.
Verify orders before releasing the change
Use the relevant gateway’s supported test mode on staging. Check more than the payment selector: place an eligible test order, confirm the order status and inspect the confirmation. Verify that a restricted combination cannot complete through another checkout route. Record the cart contents, customer state and result for each case.
After release, run the same essential checks on the public storefront using the store’s approved verification process. Avoid real charges unless specifically authorized. Keep a rollback path that removes the new restriction without disturbing the gateway’s credentials or unrelated settings. Monitor checkout problems after the change rather than assuming the absence of complaints proves success.
A reliable restriction expresses a clear store policy, works across the relevant purchase routes and gives eligible customers a way to finish. Keep the scenario matrix with the rule’s settings. It becomes the regression checklist when WooCommerce, the payment extension or the checkout design changes.
Frequently Asked Questions
Can I restrict WooCommerce payment methods by product?
Yes, with a conditional payment plugin or custom code that hides gateways based on product, category or cart total.
Why would I restrict payment methods?
To avoid fees on low-margin items, limit risky products to verified methods, or offer invoices only for wholesale orders.
Will restricting payments hurt conversions?
It can if buyers lose their preferred option, so explain why and keep at least one common method.
Who can configure WooCommerce payments?
Our ecommerce website team sets up and tests payment rules.
