Payment rules often fail at the edges: a guest uses a different group, an address changes late in checkout, two profiles overlap, or the gateway independently hides itself. Reliable configuration starts with expected outcomes, not with clicking through a condition builder.
Short answer: Write a payment-policy matrix before creating rules. Keep profiles small, give priorities a documented meaning, choose no-match behavior deliberately, and test the final method list for every identity, website, cart type, and checkout channel. A saved Admin form is not proof that the policy works.
Start with final outcomes
List what the buyer should see:
| Buyer | Website | Cart context | Allowed methods |
|---|---|---|---|
| Approved dealer | EU | Standard products, under €5,000 | Invoice, bank transfer |
| Approved dealer | EU | Controlled category | Bank transfer |
| New dealer | EU | Any | Card, bank transfer |
| Guest | EU | Any | Card, PayPal |
| Dealer | US | Any | US website methods only |
This table is more useful than a list of rule names because it exposes gaps and contradictions.
Use profiles as readable policies
Name profiles after the business outcome: “Approved EU trade payment” is clearer than “Rule 7.” Put only the relevant methods in the allow list. Assign the intended customer groups or accounts, select the correct website, and add conditions only where the outcome table requires them.
SoftwareSilo evaluates assigned profiles in website scope. Lower priority numbers come first for the primary matching rule. Use a simple convention such as 10 for narrow exceptions, 100 for normal account policies, and 900 for broad fallbacks. Leave gaps so a new rule does not force a full renumbering.
Understand intersections
Payment availability is the intersection of several systems:
- Magento enables the method for the store and order context.
- The gateway checks currency, country, totals, credentials, and its own conditions.
- Payment Profiles evaluates the customer, group, website, and quote.
- Other custom modules may also observe payment availability.
A profile can remove an available method. It should not revive a method another legitimate check has disabled. When a method is missing, inspect the whole pipeline.
Test no-match behavior
No-match behavior deserves its own test cases. Try a customer with no assignment, a group that was recently created, a profile from another website, and a cart that fails every condition. Confirm whether the store should retain Magento's normal methods or deny them.
Do not discover the answer from a customer ticket after deployment.
Cover every checkout channel
Many B2B stores create quotes through more than the standard storefront. Test:
- Luma or the actual custom checkout;
- admin-created orders;
- guest and logged-in carts;
- REST or headless checkout if used;
- virtual and physical carts;
- address changes and shipping-method changes;
- coupons, zero totals, taxes, and multiple currencies;
- disabled or temporarily failing gateways.
The extension uses Magento's payment-method availability event and has integration coverage for storefront, admin-order, REST, and headless pipeline contexts. Your custom checkout and gateways still need project-specific verification.
Roll out with evidence
Start with a pilot group. Capture the customer, group, website, cart conditions, matching profile, priority, and visible methods for each acceptance case. Ask finance and support to approve the matrix, not just the configuration screen.
After launch, monitor payment-method usage and “no payment methods available” errors. Review profiles whenever groups, websites, gateways, or finance policy change. Payment rules are living operational controls.
Last reviewed: August 9, 2026.