Using Shopware 6 Rule Builder to Show/Hide Payment Methods Without Code

The problem: hard‑coded checkout logic

When a store needs to hide a payment method for certain customers, developers often add a conditional check in a controller or a template. That approach ties the logic to code, makes it harder for non‑developers to adjust, and risks breaking after a Shopware update.

Thesis: declarative rules let administrators control visibility without touching PHP

Shopware 6’s Rule Builder evaluates conditions such as customer group, cart contents, shipping country, or date range. By assigning a rule to a payment or shipping method per sales channel, the storefront automatically filters eligible options during checkout.

How Rule Builder works

A rule consists of one or more conditions. Each condition implements the Shopware\Core\Framework\Rule\RuleConditionInterface. The administration provides a UI to combine conditions with AND/OR logic. When checkout starts, the rule service resolves the active sales channel and customer context, evaluates the rule, and returns a boolean that determines whether the method is shown.

Creating a rule for payment visibility

1. Log in to the Shopware administration with a user that has the Administrator role (required to manage rules and payment methods).
2. Navigate to Marketing > Rule Builder and click Add rule.
3. Give the rule a name, e.g., Show Invoice for Wholesale.
4. Add a condition: Customer group is Wholesale. (If the group does not exist, create it first under Customers > Groups.)
5. Save the rule.
6. Go to Settings > Payment > Payment methods, open the method you want to control (e.g., Invoice), and switch to the Availability tab.
7. Select the sales channel(s) where the rule should apply, then choose the rule you just created from the Rule dropdown.
8. Save the payment method.

At this point, the Invoice method will only appear in the checkout for customers belonging to the Wholesale group in the selected sales channel.

Worked example: verifying the rule

To confirm the rule works as expected:

1. Open a private/incognito browser window.
2. Log in with a customer account that is not assigned to the Wholesale group.
3. Add a product to the cart and proceed to checkout.
4. Observe the payment method list: the Invoice option should be hidden.
5. Log out, then log in with a customer that is in the Wholesale group.
6. Repeat the checkout steps; the Invoice method should now be visible.

No code changes are required; the behavior is driven entirely by the rule configuration.

Trade‑off and limitation

Rule Builder is ideal for simple visibility checks, but it is not suited for complex calculations such as dynamic pricing, tax overrides, or inventory reservations. Those scenarios should remain in dedicated services or event listeners to keep the rule set maintainable and testable. Additionally, rule definitions are stored per sales channel; a rule created for the storefront channel will not automatically affect a headless API client unless the same channel identifier and customer context are supplied in the request.

Practical way to check the result

After assigning a rule, you can inspect the checkout request in the browser’s developer tools:

1. Open the Network tab.
2. Look for the request to /storefront/checkout/cart (or the equivalent API endpoint).
3. In the response, examine the paymentMethods array; it should contain only the methods whose rules evaluated to true for the current context.

If the array matches expectations, the rule is being applied correctly.

Closing: start with rules, refactor to code only when needed

Begin by using the Rule Builder for any visibility logic you can express with the built‑in conditions. When a requirement outgrows what a rule can express, extract the logic into a custom condition service or a dedicated domain service, keeping the checkout layer clean and administrable.