Answers.Body: <p>This is really more of a Craft general thing than Commerce per se, if you're content to simply 'restrict' them by only showing them the appropriate options depends on their group.</p>
  <p>If so, then it's as simple as some twig code to test the user group and show/not show things accordingly.</p>
  <pre><code>{% if currentUser.isInGroup('groupHandle') %}
     ... show something
  {% else %}
     ... show something else
  {% endif %}
  </code></pre>
  <p>(Of course that requires a logged in user and the bigger questions here is whether user groups is the right way to handle this scenario...)</p>
  <p>If you want to take things further, you could listen to various Commerce events in a custom module and take action there if they should/shouldn't be allowed to do what they arte doing.  You might look at:</p>
  <p><a href="https://craftcms.com/docs/commerce/3.x/events.html#beforeprocesspaymentevent" rel="nofollow noreferrer">https://craftcms.com/docs/commerce/3.x/events.html#beforeprocesspaymentevent</a></p>
  <p><a href="https://craftcms.com/docs/commerce/3.x/events.html#beforecompleteorder" rel="nofollow noreferrer">https://craftcms.com/docs/commerce/3.x/events.html#beforecompleteorder</a></p>
  <p>...or others - they are listed here:</p>
  <p><a href="https://craftcms.com/docs/commerce/3.x/events.html" rel="nofollow noreferrer">https://craftcms.com/docs/commerce/3.x/events.html</a></p>
  <p>In reality, as usual, probably some combination of front end logic and back end verification would be the way to go.</p>
  <p>Hopefully that is enough to get you started!</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-17T15:50:21.080Z
Answers.Text: I think the event listeners are the only sensible way to approach it, anybody can bypass some HTML on a page, only a server-side solution is really reliable. Thanks :)
Answers.UserDisplayName: owenmelbz
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-17T22:40:28.413Z
Answers.Text: Well, technically, twig IS server side.  But as far as messing with websites go, I just don't see people creating and submitting fake/alternate payment forms to send me money as a big, or realistic, problem!  There are much easier ways to mess with websites and shop owners... but more generally, almost everything in e-commerce tends to end up being a bit of both how/what is presented to the client, AND appropriate verification & validation at the server, for sure.
Answers.UserDisplayName: Jeremy Daalder
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-18T14:44:32.203Z
Answers.Text: One of our payment methods is "Paid via phone" :D so thats why we do not want anybody to be able to submit it :) as then it's definitely free!
Answers.UserDisplayName: owenmelbz
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-18T23:28:09.570Z
Answers.Text: (...of course your store operators would see the order's unpaid status (assuming you're using the manual gateway) - and then have to explicitly and manually confirm the order by capturing the payment, before this was _actually_ processed, right?! ... otherwise I'd say you have a significant problem in your processing flow!!)
Answers.UserDisplayName: Jeremy Daalder
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-21T13:38:04.183Z
Answers.Text: So if you're using "manual gateway" it always goes in as unpaid?
Answers.UserDisplayName: owenmelbz
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-21T21:30:42.260Z
Answers.Text: Yep. In our case we have module code that listens for these, and automatically flips then to a 'waiting on payment' status to make it even more explicit, but they will be marked as unpaid in the backend until the payment is manually 'captured'.
Answers.UserDisplayName: Jeremy Daalder
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-22T10:36:30.520Z
Answers.Text: Ah okay, thats useful to know, thanks for that :)
Answers.UserDisplayName: owenmelbz
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-09-16T02:56:23.113Z
Answers.LastActivityDate: 2020-09-16T02:56:23.113Z
Answers.UserDisplayName: Jeremy Daalder
Body: <p>Is it possible to restrict payment gateways on a per user group basis?</p>
  <p>e.g. Say you want a user group to assign users into from a certain country that cannot use PayPal, so you can offer them a different gateway instead?</p>
  <p>Thanks</p>
  
Tags: <plugin-craftcommerce>
Title: Restricting Payment Gatways by User Group using Commerce Pro?
ThreadText: # Restricting Payment Gatways by User Group using Commerce Pro?
  
  (Asked by: username_0 on 2020-08-26)
  
  Is it possible to restrict payment gateways on a per user group basis?
  
  e.g. Say you want a user group to assign users into from a certain country that cannot use PayPal, so you can offer them a different gateway instead?
  
  Thanks
  
  **Tags:** plugin-craftcommerce
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-09-16. Score: 1
  
  This is really more of a Craft general thing than Commerce per se, if you're content to simply 'restrict' them by only showing them the appropriate options depends on their group.
  
  If so, then it's as simple as some twig code to test the user group and show/not show things accordingly.
  
  ```
  {% if currentUser.isInGroup('groupHandle') %}
     ... show something
  {% else %}
     ... show something else
  {% endif %}
  
  ```
  
  (Of course that requires a logged in user and the bigger questions here is whether user groups is the right way to handle this scenario...)
  
  If you want to take things further, you could listen to various Commerce events in a custom module and take action there if they should/shouldn't be allowed to do what they arte doing. You might look at:
  
  <https://craftcms.com/docs/commerce/3.x/events.html#beforeprocesspaymentevent>
  
  <https://craftcms.com/docs/commerce/3.x/events.html#beforecompleteorder>
  
  ...or others - they are listed here:
  
  <https://craftcms.com/docs/commerce/3.x/events.html>
  
  In reality, as usual, probably some combination of front end logic and back end verification would be the way to go.
  
  Hopefully that is enough to get you started!
  
  > **Comments:**
  > **username_0**: I think the event listeners are the only sensible way to approach it, anybody can bypass some HTML on a page, only a server-side solution is really reliable. Thanks :)  
  > **username_1**: Well, technically, twig IS server side.  But as far as messing with websites go, I just don't see people creating and submitting fake/alternate payment forms to send me money as a big, or realistic, problem!  There are much easier ways to mess with websites and shop owners... but more generally, almost everything in e-commerce tends to end up being a bit of both how/what is presented to the client, AND appropriate verification & validation at the server, for sure.  
  > **username_0**: One of our payment methods is "Paid via phone" :D so thats why we do not want anybody to be able to submit it :) as then it's definitely free!  
  > **username_1**: (...of course your store operators would see the order's unpaid status (assuming you're using the manual gateway) - and then have to explicitly and manually confirm the order by capturing the payment, before this was _actually_ processed, right?! ... otherwise I'd say you have a significant problem in your processing flow!!)  
  > **username_0**: So if you're using "manual gateway" it always goes in as unpaid?  
  > **username_1**: Yep. In our case we have module code that listens for these, and automatically flips then to a 'waiting on payment' status to make it even more explicit, but they will be marked as unpaid in the backend until the payment is manually 'captured'.  
  > **username_0**: Ah okay, thats useful to know, thanks for that :)  
  
  ---
  
  