Invoice payment is convenient for established B2B buyers and risky when offered indiscriminately. The Magento configuration is only one part of the decision. A durable setup separates customer approval, checkout visibility, credit ownership, and collection after the order.
Short answer: Keep credit approval outside the checkout rule, mark approved buyers through a customer group or explicit account assignment, and use a payment profile to expose invoice only to that audience. Always leave a tested prepaid fallback and revoke access promptly when account status changes.
1. Define what “approved” means
Write down who owns the decision. It may be finance, an ERP credit process, or an account manager following a documented limit. Approval should not mean “someone happened to move the customer into a group.” Record the review date, responsible team, and revocation trigger in the appropriate system of record.
SoftwareSilo Payment Profiles does not calculate credit or check overdue invoices. It uses the Magento customer and quote context it receives. Feed it a reliable status.
2. Choose group or customer assignment
A customer group works well for a stable shared policy such as “approved wholesale.” Individual assignment is useful for exceptions or a gradual rollout. Avoid creating dozens of nearly identical groups only to represent one payment choice.
A typical profile might be:
- Name: Approved B2B invoice
- Website: relevant sales website
- Customer groups: Approved Wholesale
- Individual customers: approved exceptions, if any
- Allowed methods: invoice and bank transfer
- Conditions: optional order or product constraints
- Priority: ahead of broader fallback profiles
3. Decide the fallback before launch
What should a buyer see when the invoice profile does not match? Usually at least one prepaid method should remain viable. SoftwareSilo includes a configurable no-match behavior, so treat that switch as a policy choice rather than an installation detail.
Failing closed can be appropriate for tightly controlled portals, but it can also create a checkout with no payment option. Failing open protects conversion but may expose a method you meant to limit. Test both the intended rule and the absence of a rule.
4. Add cart conditions only when justified
Conditions can restrict invoice availability by cart or product context. For example, finance may disallow invoice for unusually high totals or a special category. Keep the tree understandable. If the rule requires a page of nested conditions, consider whether the decision belongs in an external credit service instead.
Remember that gateway, currency, country, and method configuration still apply. A profile cannot force Magento to offer a method that is unavailable for another valid reason.
5. Test identities and channels
Build a small matrix:
| Scenario | Expected result |
|---|---|
| Approved account, ordinary cart | Invoice visible |
| Approved account, excluded cart condition | Invoice hidden; fallback visible |
| New wholesale account | Prepaid methods only |
| Guest | Public payment policy only |
| Wrong website | That website's policy applies |
| Admin order | Same approved methods expected for the quote |
| REST/headless cart | Same payment availability expected through Magento's pipeline |
Also test virtual products, zero totals, address changes, coupons, and a disabled gateway. Record screenshots or automated checks for the final list of methods.
6. Plan revocation and support
Invoice access must disappear when an account becomes overdue, changes legal entity, or fails review. Decide whether that update happens in Magento, through an integration, or manually. Give support a simple diagnostic: customer identity, group, website, cart, matching profile, priority, and gateway status.
The best rule is not the cleverest one. It is the one finance can audit, support can explain, and buyers experience consistently.
Last reviewed: August 9, 2026.