Restrict WooCommerce Payments by Category

Not every product in a WooCommerce store should be payable in every way. Gift cards and digital downloads have no business being sold cash on delivery. High-margin categories can absorb a 3% wallet fee that a low-margin category cannot. Wholesale-only categories should usually go on invoice and nothing else. The mechanism behind all three cases is the same: restrict payment method by product category so the checkout only shows what makes sense for what is actually in the cart.

This guide covers when the rule is worth setting, the two ways to build it, and the mixed-cart edge case that quietly breaks most first attempts.

When a category-level payment rule is the right tool

Category rules pay off when the restriction is a property of the product, not of the customer. Typical cases from real stores:

• Cash on delivery on fragile or high-value categories. The refusal rate on delivery makes COD expensive on anything you cannot easily resell.
• Invoice or purchase order on a trade category. Retail customers should never see it; the category is the cleanest signal when the products themselves are trade-only.
• Low-margin categories versus expensive gateways. If a wallet or buy-now-pay-later provider costs 3–4% plus a fixed fee, a €7 accessory category can lose money on every sale.
• Regulated or age-restricted goods where a specific provider's terms forbid the merchandise. Leaving the gateway enabled risks the whole merchant account, not just the order.

If the restriction depends on *who* is buying rather than *what* they buy, use a role rule instead — that is a different filter with different pitfalls, covered in our guide on payment gateways by user role.

How WooCommerce decides which gateways to show

Every gateway registers itself with WooCommerce, and just before checkout renders, WooCommerce passes the list of enabled gateways through the `woocommerce_available_payment_gateways` filter. Anything you remove from that array disappears from the checkout — classic and block-based alike, and from the pay-for-order page too.

That single filter is the correct place for every conditional payment gateway rule in WooCommerce. Hiding a radio button with CSS is not: the gateway stays available server-side, so an order can still be placed through it.

Option 1: the code route

For one rule on one category, a snippet in a site-specific plugin is enough:

```php add_filter( 'woocommerce_available_payment_gateways', function ( $gateways ) { if ( is_admin() || ! WC()->cart ) { return $gateways; }

$blocked_category = 'gift-cards';

foreach ( WC()->cart->get_cart() as $item ) { if ( has_term( $blocked_category, 'product_cat', $item['product_id'] ) ) { unset( $gateways['cod'] ); break; } }

return $gateways; } ); ```

Three details matter here. The `is_admin()` guard keeps the rule out of the admin order screens. The `WC()->cart` check avoids fatals on the pay-for-order endpoint where the cart may not exist. And `has_term()` on `product_cat` respects child categories only if you list them, so a parent category with sub-categories needs the child slugs too.

Add a second category, a second gateway and a role exception, and this snippet turns into a nested block nobody wants to touch six months later.

Option 2: manage the rules in wp-admin

The maintainable version stores the rules as data instead of code. Our WooCommerce Payment Gateway Per Product plugin runs on the same filter, but you pick the categories, products and gateways in wp-admin, and shop managers can change a rule without a deploy.

The practical difference shows up on stores with more than a handful of rules:

The mixed-cart problem

A cart containing one restricted product and one unrestricted product has no obviously correct answer, and this is where most implementations quietly misbehave.

Strictest wins is the safe default: if any line item forbids a gateway, that gateway is unavailable for the entire order. It never lets a forbidden payment through, and it is what the snippet above does.

Split the order is stricter still: block the combination in the cart with a notice asking the customer to order the restricted category separately. Use it when the constraint is a fulfilment one — for example a trade category that must be invoiced and shipped from a different warehouse.

Most permissive wins — allowing the gateway if any item permits it — is almost always wrong. It is the rule that lets a COD order through for the exact product you were trying to protect.

Whichever you pick, verify that at least one gateway survives every combination. A cart that removes every payment method leaves the customer at a checkout with no way to pay and no explanation.

Testing the rule before it goes live

Run these five carts on staging, in this order:

1. Restricted product alone — the gateway must be gone.
2. Unrestricted product alone — the gateway must be back.
3. Both together — matches the mixed-cart rule you chose.
4. A variation of a restricted product — variations inherit the parent's category, so this must behave like case 1.
5. A restricted product on the pay-for-order page from an admin-created order — the rule must apply there too.

Then check the block-based checkout as well as the classic one, and place one real order through a surviving gateway to confirm nothing else broke.

Reporting: know what the rule costs you

Every restriction removes an option somebody wanted. Before and after go-live, compare checkout completion rate for the affected categories in your analytics. If completion drops more than a point or two, the restriction may be costing more than the fraud or fees it prevents — in which case narrow it to fewer products rather than removing it entirely.

Next step Write down the categories that genuinely need a restriction and the reason for each. If the list is one line long, ship the snippet. If it is five lines long and likely to grow, move it into [Payment Gateway Per Product](/plugins/woocommerce-payment-gateway-per-product) before it becomes someone's inherited PHP problem.