Printable View
Hi ,
I just got an order from a customer that was cleared through Zencart but actually failed through Cybersource for an invalid CVV. So I tried a sale myself with a false CVV and I never got an error telling me I had a bad cvv number. I would have been allowed to check out.
I am going to try and trace it through cybersource, but I was wondering if anyone else has had this problem with them?
Thanks - zen 1.2.7d
Did you try to complete the sale with the client's CVV manually through Cybersource?, and did it work then?
it was stopped at cybersource for a failed cvv code. That is the problem. I think there is something about the payment module that doesn't check to see if the cvv code is filled out.
As I indicated, in my first post. I can place an order without the cvv code entered.
I ran a check with no CVV...Zen would not move forward without something in the data field... so that's good.Quote:
Originally Posted by romanus
But then I put a bogus CVV number in to see what would happen - Zen sent it to CS, CS did nothing except to send it back, and Zen showed a completed sale... so Cybersource didn't process the order properly and Zen just responded naturally (which, for me is a problem because my distributor will receive automatic notice to ship the order).
In Cybersource, there are settings to require the CVV info for each card (HOP Settings), but this didn't result in a 'false' return for some reason. It didn't record anything at Cybersource for my test.
Let us know what you find out from Cybersource... it sounds like it might be an issue that can be resolved from their end.
Yeah, and I bet when you get your statement at the end of the month you will find that you have been charged an additional 1% and 1.3% for "Non and Mid" qualified transactions.
I have been on hold with cybersource for about 30 minutes so far
There is something wrong with the payment module. It isn't parsing the data properly and allowing orders to be placed.
I will let you know what the fix is. In the meantime I have switched back to the zencart CC module.
After goint through the cybersource contribution, it looks like there is no AVS or CVV validation built into it. I can actually put any name into the name fields and put any address or cvv into it and as long as I have the right credit card number and the right expiration date, it will capture the funds.
Kind of a bummer. Is this what you find to be true as well?
Isn't this series of validations a function of the gateway operation? I mean, ok- maybe Zen allows anything to be sent through, but should'nt Cybersource know better and return a 'false' response if the information isn't verified?Quote:
Originally Posted by romanus
From Zen checkout - using a valid name and CC#, but a bogus CVV, Cybersource accepts the sale for 'review' with the following information listed:
Authorization Status Failed
# Failure Reason(s) The order failed for the following reasons: CVN declined
So it's doing it's job there...but it is sending back the wrong message to Zen ('true' for Receipt instead of 'false' for a Decline). This must be a problem that Cybersource can address. I'll see what headway I can make with their tech support.
The logic to the CVV number has not and will not be made public. Thats why Zen Cart does not have a logic check for it. Often customers cant read the CVV after years of where and tare on the card. A simple call to the customer usually resolves the issue.
This has nothing to do with zencart. It has to do with the contribution. The javascript in the contribution is a mess, there are few if any validations. There are specific calls that need to be made to the payment gateway of which as far as I can see none are built into the script for the current set of requirements.
It is amazing anything gets processed at all.
Whats the latest on this CVV issue?
I just read another one of you posts re- canadian addresses, so i updated that.
I am about to open my store in the next week or so and want to make sure everything works good.
I've got a support ticket running with CyberSource. Basically, I'm asking them to establish merchant notification (auto e-mail) if a CVN/CVV puts the charges in 'review' status. This way, if the order is automatically returned for Zen processing, at least the merchant is notified that the charges aren't being applied and he/she might catch the order before product is shipped.
I've also requested that CyberSource consider changing the HOPscript default return from 'true' to 'false' for CVN/CVVs that don't match CC name & number and end up in 'review'. This gives the customer an option to match the card info properly with another checkout attempt, and also (with the auto e-mail) notifies the merchant that a charge was put in 'review' status.
I also suggested that another (possibly more complex) solution might be a third return option (neither 'true' or 'false') that puts the order on hold within the cart and at the gateway. I suspect this would require some heavy coding on both cs.php/etc and CyberSource's system - but I felt it was worth considering.
In case anyone is wondering:
part of holgates issue :"I've got a support ticket running with CyberSource. Basically, I'm asking them to establish merchant notification (auto e-mail) if a CVN/CVV puts the charges in 'review' status. This way, if the order is automatically returned for Zen processing, at least the merchant is notified that the charges aren't being applied and he/she might catch the order before product is shipped."
If you go to the HOP Setting in Cybersource business center and go to the notification section and put your email in the Merchant POST email box (i also had to put it in the Senders Email box), cybersource will email you all the data about the POSTed transaction including the ReviewCode and the Decsion which is ACCEPT or REVIEW (the ones i tested sent these back).
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.
Thanks for your efforts jclegg. I should have noticed the 'Notifications' section on the HOP page at CyberSource - but even on my second support ticket and having talked with two associates there recently, it was never mentioned when discussing this whole topic :blink:. But the return for mismatched info should still be coming back to Zen as 'false' if they are put in 'Review' status IMO.
Can anyone offer a brief description of what would be required to use CyberSource with API? Would it be a preferable interface? Would it require core coding in Zen? I've browsed through the CyberSource Info on this, but it's beyond my current level... however I'm sure the coding can be achieved - when I signed up with UltraCart a couple years back, they modified their code to accomodate the CyberSource gateway. Looks like maintenance would be an issue as Zen and CS are improved over time too.
Here is the reply I got from a question I asked cybersource:
"Thank you for your Knowledgebase question regarding the HOP receipt and decline pages. The customer will get directed to your decline page when the decision returned is REJECT, meaning, there was no authorization code returned. Orders with a decision of ACCEPT or REVIEW get directed to your Receipt page, as a successful authorization has taken place. At this point, it is up to each merchant to decide how to handle the orders that are placed in Review.
If you would like your customers get a more specific message for their orders placed in review, then I would recommend parsing for the decision and reason code. Reason code 520 get returned for orders placed in review for Smart Auth. You can use these reply fields to give these customers are more customized receipt page."
So it looks like if you wanted to not let the order process if it was put into review status based on how you set the smartAuth setting then the code in the cybersource module needs to know it came back in review status and deal with. Either not let the order go through or whatever. This would be a good feature to have in this module so you could either allow REVIEW orders to be successful or not.
I guess that is kinda like my 3rd recommendation - although I don't fully understand what is necessary to make it happen, how it should be setup, and/or what is required from Zen code + Cybersource.
I presume that I will receive a similar response to the CS ticket I have, but I was told "engineers are working on it". So I submitted the CS contrib-module for their review hoping they'd step up with more intimate assistance.
Sounds good. I would like to hear what they do if anything. Currently I am working on making some modifications that even though cybersource passes back a successful order, even though it is in review status, I am going to check to see if it is in review status and get a message to the screen. I figured out where it all needs to be done. Also maybe add a parameter on the setup of the module so you can check a box to say orders in REVIEW are not valid orders or are valid orders depending on what you want to do. If / when I get this working I will let you know also. I have emails in to all the guys who have contributed to creating this module but haven' heard back from any of them.....
so that is what i got at this point.
Have been calling back to CyberSource every 6-10 days (a few time now) to check on the update of my service ticket - I usually get the same tech, who informs me that the "engineers are still working on it". I expect to be incredibly satisfied with some new code that resolves the CVV/CVN problem completely, or to be quite dissapointed in the time taken to get blown off. In either case, I'm patiently pursuing this and will update as appropriate. :mellow:
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"
:bangin:
Sounds like there not interested in zen-cart solutions. Its not on there Certified Shopping Carts list.
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."
Keep hounding them. Although Authorize.net is coming out with some attractive sign up offers.
Todays call:
"Trying to get this worked into the roadmap"... "engineers are working on it"...
:sleep:
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.Quote:
Originally Posted by jclegg
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?
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!!
You and me both adod. I just ran into this myself.
Any help with this would be greatly appreciated.
Please refer to the following thread for more information on this subject:
http://www.zen-cart.com/forum/showthread.php?t=120242
deBeaujeu