Answers.Body: <p>This is a bug and I have opened a <a href="https://issues.civicrm.org/jira/browse/CRM-20166" rel="nofollow noreferrer">JIRA</a> ticket and will update when something comes of that.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-24T01:28:53.863Z
Answers.Text: As this is being fixed - it may be good to add a warning bubble that some payment processors require CVV codes - or you'll not be able to payment process at all. It's essentially an additional security check. So turning off CVV codes is not unlike: "would you like to scale down your Fraud prevention strategies". Come to think of it - perhaps no-one should be presented with that option!
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-24T01:53:01.923Z
Answers.Text: You mean 'no-one' at front end? or either?
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-24T02:41:07.987Z
Answers.Text: I'm thinking best to not let anyone disable it anywhere. CVV is a good thing - from a security/fraud prevention point of view. It also helps to prevent accidental charges. For example AMEX does not care about expiry date (you can type in any date in future - and card will process) - so you're left with 15 digits - any typo in those digits - any you're charging someone else. Requiring CVV will help prevent such accidental charges as well.
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-24T19:43:44.107Z
Answers.Text: but if the payment processor allows an admin to enter a payment without cvv (eg a recurring one), but if civicrm does not allow this, then we end up with recurring payments being set up via the PP, rather than via Civi and hence get bad reporting of transactions in civi
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-24T23:16:59.413Z
Answers.Text: Requiring CVV is a good one from a fraud prevention viewpoint - even if a payment processor does not require it.
Answers.UserDisplayName: KarinG - Semper IT
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-25T00:55:48.020Z
Answers.Text: But if we are just allowing it at Back End because the Admins request that, should it not be allowed? The functionality has been added to civi, but imo incorrectly as it is also affecting front end forms
Answers.UserDisplayName: petednz - fuzion
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2017-02-23T06:16:01.967Z
Answers.LastActivityDate: 2017-02-23T06:16:01.967Z
Answers.UserDisplayName: petednz - fuzion
Body: <p>I just ran in to this issue on a site - namely setting "CVV required for backoffice" to 'no' results in it CVV fields showing as 'not required' site wide, ie on all public facing contribution pages. </p>
  
  <p>I found a question about this here <a href="https://forum.civicrm.org/index.php?topic=34624.0" rel="nofollow noreferrer">https://forum.civicrm.org/index.php?topic=34624.0</a></p>
  
  <p>If this was the intended and desired outcome then at least the help text and label should be updated.</p>
  
  <p>Noting that on 4.6 this is at civicrm/admin/setting/url?reset=1</p>
  
  <p>At 4.7 it is at civicrm/admin/setting/preferences/contribute?reset=1</p>
  
  <p>What should next step be? Have it perform as described, or describe how it performs?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2017-02-23T03:02:51.287Z
Comments.Text: That sounds like a bug to me. I'm pretty sure the intent was to just provide the option to disable it in the backend.
Comments.UserDisplayName: lcdservices
Tags: <payment-processor><contribution-page>
Title: Why does setting "CVV required for backoffice" to 'NO' also unrequire it on front facing forms
ThreadText: # Why does setting "CVV required for backoffice" to 'NO' also unrequire it on front facing forms
  
  (Asked by: username_0 on 2017-02-23)
  
  I just ran in to this issue on a site - namely setting "CVV required for backoffice" to 'no' results in it CVV fields showing as 'not required' site wide, ie on all public facing contribution pages.
  
  I found a question about this here <https://forum.civicrm.org/index.php?topic=34624.0>
  
  If this was the intended and desired outcome then at least the help text and label should be updated.
  
  Noting that on 4.6 this is at civicrm/admin/setting/url?reset=1
  
  At 4.7 it is at civicrm/admin/setting/preferences/contribute?reset=1
  
  What should next step be? Have it perform as described, or describe how it performs?
  
  **Tags:** payment-processor, contribution-page
  
  > **Comments:**
  > **username_1**: That sounds like a bug to me. I'm pretty sure the intent was to just provide the option to disable it in the backend.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2017-02-23. Score: 1
  
  This is a bug and I have opened a [JIRA](https://issues.civicrm.org/jira/browse/CRM-20166) ticket and will update when something comes of that.
  
  > **Comments:**
  > **username_2**: As this is being fixed - it may be good to add a warning bubble that some payment processors require CVV codes - or you'll not be able to payment process at all. It's essentially an additional security check. So turning off CVV codes is not unlike: "would you like to scale down your Fraud prevention strategies". Come to think of it - perhaps no-one should be presented with that option!  
  > **username_0**: You mean 'no-one' at front end? or either?  
  > **username_2**: I'm thinking best to not let anyone disable it anywhere. CVV is a good thing - from a security/fraud prevention point of view. It also helps to prevent accidental charges. For example AMEX does not care about expiry date (you can type in any date in future - and card will process) - so you're left with 15 digits - any typo in those digits - any you're charging someone else. Requiring CVV will help prevent such accidental charges as well.  
  > **username_0**: but if the payment processor allows an admin to enter a payment without cvv (eg a recurring one), but if civicrm does not allow this, then we end up with recurring payments being set up via the PP, rather than via Civi and hence get bad reporting of transactions in civi  
  > **username_2**: Requiring CVV is a good one from a fraud prevention viewpoint - even if a payment processor does not require it.  
  > **username_0**: But if we are just allowing it at Back End because the Admins request that, should it not be allowed? The functionality has been added to civi, but imo incorrectly as it is also affecting front end forms  
  
  ---
  
  