Make Cvv required (backoffice) configurable at the site level

per discussions with Dave G - cvv are not always gathered & are more often than not discarded by the processor. Request is to make then not-required at a site-wide config level

(10:25:51 AM) eileen: dgg - we get a lot of requests to make the security code (cvv) optional on the back office forms - why is it compulsory for backoffice users?
(10:30:15 AM) dgg: eileen: assumption is that some (or) processors require it
(10:30:35 AM) dgg: if that's not the case, i guess we should look at making it conditionally required
(10:30:47 AM) eileen: hmm - there are certainly quite a few that don't
(10:31:15 AM) eileen: so, that would need to be an attribute of the processor_type table then I guess
(10:31:48 AM) dgg: assuming that some do require it - not sure of that either
(10:32:26 AM) dgg: is it submitted to processor in the cases you're looking at?
(10:32:30 AM) eileen: hmm - no I suspect that all allow bypass - because normally backoffice users don't have it
(10:32:49 AM) eileen: We tell our customers just to enter 000 but they think that's dumb
(10:33:07 AM) dgg: hmm - in use - if i give card over the phone they almost always ask for the cvv2 # as well
(10:33:23 AM) dgg: so not sure about "normally back office users don't have it"
(10:33:47 AM) eileen: OK - if I send in a form -e.g to Oxfam & put my credit card number on it I don't addit
(10:33:55 AM) dgg: i thought part of the reason for that verification code was for "card not present" transctions
(10:34:30 AM) eileen: Generally the payment processors allow you to configure your sensitivity on the cvv
(10:34:49 AM) eileen: for example eWay you can set whether cvv or Avv fails will generate a decline
(10:35:20 AM) eileen: For some others (I think Paypal) it will send you a success but with extra information about cvv matching & avs matching - which CiviCRM discards
(10:36:07 AM) eileen: mostly that is important for people who ship goods -e.g. correct credit card & cvv but avs match failure = no, don't post that $1000 part & expect to keep the $
(10:38:12 AM) eileen: Looks like Payflow Pro - that I'm looking at - http://forum.cs-cart.com/topic/25482-payflow-pro-cvv-and-avs-security-settings/ will pass any cvs & avv by default but provides an add-on service like eWay
(10:41:52 AM) eileen: OK - Paypal is the same as payflow pro - by default it ignores cvv - unless you pay for an add-on service
(10:43:58 AM) eileen: & Authorize.net seems to provide it in the same way as eWay
(10:47:34 AM) dgg: eileen: trying to get a sense of best practices for card not present transactions - esp "order by mail" which is the equivalent of the "put your card on a form and give it to oxfam or mail it to them"
(10:48:08 AM) dgg: seems like best practice is to collect the cvv2 - but not completely clear based on what i've found so far
(10:48:20 AM) eileen: dgg - can you really get an international best practice on that?
(10:48:38 AM) dgg: just checked by local museum membership renewal by mail - and it's asking for cvv2 (as an example)
(10:48:43 AM) dgg: eileen: probably not
(10:48:59 AM) eileen: I don't think it makes sense for it to be compulsory - the 4 processors I've checked all disregard the cvv unless configured (possibly for extra $) to do otherwise. If we made it optional & passed in '000' if not set then the processors would work as they do now
(10:49:26 AM) dgg: yes - but then orgs that want best practice enforced wouldn't have tht
(10:49:27 AM) eileen: I suspect that I would never give out my cvv
(10:49:50 AM) eileen: they can enforce the best practice @ their payment processor end
(10:50:25 AM) eileen: ie. by paying for the fraud protection services which allow them to say that if the cvv is incorrect it should be declined
(10:50:50 AM) dgg: eileen: can you check what similar systems to ours do? eg. salesforce, blackbaud
(10:51:00 AM) dgg: etapestry
(10:51:34 AM) dgg: if the common practice is to make it optional - then i'm ok to move that way (or at least make it configurable at site level)
(10:54:02 AM) eileen: dgg - I don't think we should necessarily change any front end forms. But my customers tell me if they get a credit card they enter it (and it's far enough from common practice in NZ in Australia to request it on postal forms that I think most people would not fill it in - I've never seen it on a postal form)
(10:54:33 AM) eileen: however, I read that "In some countries in Western Europe, card processors require the merchant to provide this code when the cardholder is not present in person."
(10:55:26 AM) dgg: eileen: back office forms can be used for fraudulent purposes btw
(10:56:05 AM) dgg: if an employee has a stolen list of credit card numbers - they could potentially "test them out" until they found one that works and then go shopping
(10:56:44 AM) dgg: that said, i can see why making this requirement configurable in some manner would be good - assuming that your clients are telling u that they can't use this feature w/o the change
(10:57:27 AM) eileen: well, my client is asking me to implement a hook to turn the requiredness of it off - but we've had the request before & Matt C wrote a small hook for it
(10:57:41 AM) eileen: but, I think it should be a site level config option
(10:58:36 AM) eileen: (since my initial thought about it being by processor now doesn't seem righ)
(10:58:36 AM) dgg: i'm ok w/ that if default is required
(10:58:55 AM) dgg: would be the 1st CiviContribute Component Settings field
(10:59:22 AM) dgg: using the settings table and same generic approach as CiviEvent and CiviMember component settings
(10:59:45 AM) eileen: Ah - OK - I get that.
(11:00:41 AM) eileen: so, for example group_name = 'Contribute Preferences', name ='cvv_required'
(11:03:33 AM) eileen: actually dgg - I should make it 'cvv_backoffice_required' - so that we can later offer the ability to turn off cvv for (specific) front end forms if need be (one of our customers has asked for that so although I'm not chomping at the bit to do it it might happen)
(11:05:05 AM) dgg: makes sense (backoffice)