Cybersource & CVV #

[Holgate]

2 month anniversary from my contact with CS support - I've requested it be 'escalated' to engineers every time... I think it's about 6 or 7 times now.

"Engineering is working on it"

[stagebrace]

Sounds like there not interested in zen-cart solutions. Its not on there Certified Shopping Carts list.

[Holgate]

Today's call prompted a response along the lines of "should be implemented in the next code-push - they are usually released every month or so"....

I guess I'll "endeavor to persevere."

[romanus]

Keep hounding them. Although Authorize.net is coming out with some attractive sign up offers.

[Holgate]

Todays call:

"Trying to get this worked into the roadmap"... "engineers are working on it"...

[Holgate]

...I have also found that on the page where you enter your credit card there is some javascript that gets put into the page to check things like the length of the name or credit card number and length of the ccv code. In my copy of all the code I have the names of the fields in the javascript that are referenced are not the same as the actual fields on the page. I am looking into making a change and testing it.

I am also trying to figure out from the page you enter your credit card on what all gets called and when does the info get posted to cybersource etc so I can see if there is anything I can change in the code to get it to behave the way I think it should.

If you have any insight on any of this let me know otherwise I will continue to let you know what I find out....

Spoke with CyberSource and BOA in a 3-way yesterday.. not much hope for assistance from their end. CyberSource says that in the return from the HOP, the code is either 'true' for an accepted sale or 'false' for a decline. But included with the information they return, for example in the case of a mismatched CVV which is in 'review' status at the gateway, would be a '520' code.

I agree with you jclegg, they should absolutely notify merchants with an e-mail when orders go into review - but they say that the code data included in the return from the HOP has this information built-in, and it's up to the cart(s) to interpret it.

There are probably also other codes too that would be functionally beneficial if properly parsed. Unfortunately, the current CyberSource/Zen module does not interpret this data - it just accepts the sale, because it piggybacks on the 'true' return instead of 'false'. This seems illogical to me, and I asked why in a security/banking environment the default is to return the sale positively rather than declined for a mismatch of information - they say they'd have too many complaints about declines sales doing it the other way.

So, has anyone been able to make any headway on this? I've broadcasted requests for assistance to original module authors, Zen Help Wanted, and here too now. I wonder also though - if I switched to Authorize.net for my gateway - would the same situation occur? How does a mismatched CVV return from the Authorize.net system?... or for that matter, any other gateway module? How would it identify which 'status' category the order falls into?

[adod]

I see this topic has been dead for a few years? I am running into this problem now. Is it fixed? Is there an option like jclegg suggested? What would happen if you set the smartAuth settings in cybersource to not flag anything for review? Would a mismatched order go strait to fail then? Would that mess anything else up?
Thanks!!

[prosam]

You and me both adod. I just ran into this myself.

Any help with this would be greatly appreciated.

[deBeaujeu]

Please refer to the following thread for more information on this subject:
http://www.zen-cart.com/forum/showthread.php?t=120242

deBeaujeu