Different Payment Methods per Product in Woo

Most WooCommerce stores start with one payment policy for the whole catalogue, and most outgrow it. A dropshipped item cannot be sold cash on delivery. A pre-order should not be charged through a gateway you cannot refund easily. A wholesale pallet should go on invoice, while the same store's consumer accessories should not. All of these are the same requirement: different payment methods for different products in one checkout.

WooCommerce core has no setting for this. Gateways are enabled store-wide, and the only per-product knob is COD's virtual-order toggle. Everything else is built on one filter.

The one mechanism behind every rule

Just before checkout renders, WooCommerce passes its enabled gateways through `woocommerce_available_payment_gateways`. Whatever survives that filter is what the customer sees, on classic checkout, on block checkout, and on the pay-for-order page. Every conditional payment gateway technique in WooCommerce — product, category, user role, cart total, shipping country — is a different set of conditions evaluated inside that one filter.

Two consequences worth internalising:

• Hiding a gateway with CSS or JavaScript is not a rule. The gateway remains available server-side and an order can still be placed through it.
• Rules compose. Product, category and role conditions all remove entries from the same array, so their combined effect is an intersection — which is exactly where empty checkouts come from.

Start with the matrix, not the code

Before touching PHP or a plugin screen, write the policy as a grid. Products or product groups down the side, gateways across the top, allow or block in each cell:

The grid does three useful things: it shows immediately that wholesale pallets and everyday accessories share no gateway (a mixed cart of the two is unpayable), it makes the rule reviewable by someone non-technical, and it becomes your test plan later.

Implementing it

For a small, static grid, a snippet works:

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

// gateway id => product ids that forbid it $rules = array( 'cod' => array( 812, 913 ), 'paypal' => array( 1044 ), );

foreach ( WC()->cart->get_cart() as $item ) { $id = (int) $item['product_id']; foreach ( $rules as $gateway_id => $blocked ) { if ( in_array( $id, $blocked, true ) ) { unset( $gateways[ $gateway_id ] ); } } }

return $gateways; } ); ```

Hard-coded product IDs are the weak point: they break the moment someone rebuilds a product, and nobody in wp-admin can see the policy. Once the grid has more than a few rows, move it into WooCommerce Payment Gateway Per Product, where each row of the matrix is a rule a shop manager can edit, and product, category, role and cart conditions live in one place.

Handling the mixed cart

Three defensible strategies, in the order most stores should consider them:

1. Strictest wins. A gateway survives only if every item allows it. Predictable and safe; the default choice.
2. Block the combination. When two products share no gateway, stop it in the cart with a message: "Wholesale pallets must be ordered separately from retail items." Better than a checkout with no options.
3. Split into two orders. The best customer experience and the most work, since it needs a cart-level split flow. Worth it only for stores where mixed carts are common.

Whatever you choose, add the empty-list guard: if the filter is about to return zero gateways, restore a designated fallback or show the cart notice. A checkout with no payment methods and no explanation is the single worst outcome of this whole feature.

Rules that quietly conflict with other features

• Subscriptions require a gateway that supports recurring payments. Exclude subscription products from restrictive rules or the renewal will fail, not just the first order.
• Deposits and part-payment plugins register their own gateways; check the gateway ID they use before writing a rule that removes "everything except cards".
• Multi-currency setups sometimes register per-currency gateway IDs, so a rule matching one ID may miss its sibling.
• Free orders. When a coupon takes the total to zero, WooCommerce swaps in its no-payment flow; make sure your rule does not fight it.

Test checklist

Turn the matrix into carts and walk them all: each product group alone, each pair of groups together, one variation from each group, a cart that should be unpayable, a subscription product if you sell one, and one real order through a surviving gateway. Repeat on block checkout, and on the pay-for-order page for an admin-created order.

Where this fits in a wider setup

Payment rules are one of three levers stores usually pull together — payment, shipping method restrictions and checkout field rules. If you are building the whole picture, the WooCommerce plugins hub shows how the rule-based extensions fit next to each other.

Worked example: a store with three product groups

Take a store selling digital downloads, regular physical goods and made-to-order items. A sensible grid looks like this: digital downloads accept card and a wallet but never bank transfer or cash on delivery; regular goods accept everything; made-to-order items accept only prepaid methods, because a refused delivery is a total write-off. Each row is one rule, and the rows meet in the mixed cart, where only methods allowed by every item remain.

In Payment Gateway Per Product that is three product or category rules plus a fallback. Per-product selection is available in the free version on WordPress.org, while category and tag rules, include/exclude logic and fallback options are Premium.

Specific rules to build next

Once the basic grid works, the most requested single-gateway rules are covered in their own guides: disable cash on delivery for specific products and, on the shipping side, hiding local pickup for specific products.

Next step

Draw your grid, count the blocked cells, and check every pair of product groups for a shared gateway. Then build it — snippet for a two-row grid, Payment Gateway Per Product for anything that will keep changing.