So, I ran across something interesting today involving Verisign's Payflow Link system. For those of you who don't know, this is a cheap system that allows you to add e-commerce to your site. It works by allowing you to post data to their servers (and you have a choice of how much you ask on your server compared to theirs), have Verisign handle the CC checking, and then it will return a result. One of the features is the ability to post back to your server so that you can have a response from the transaction attempt. This allows you to build a "responder" that sits and waits for Verisign pings. On a good response, you could update a flag in your database marking a particular order as being processed.
Anyway, one of my employers clients is using this service. They recently decided to add AVS checking to their cart. This system basically checks to see if the address and zip code match that of the credit card number. This in itself was easy to configure at Verisign's Manager portal. I rechecked the docs to make sure I wasn't missing something when I ran across a doozy hidden way in the back...
Apparently, if the CC# is valid, and the AVS check fails, Verisign will still return a "Status Ok" type response! Even though they properly return an error to the user, their ping back to your site makes it seem as if the transaction was alright.
To make your responder code work properly, you have to check an AVS response field. Now, this seems incredibly crazy to me. I did some more reading, and apparently, you have to contact customer service to make their response code show an error in case of AVS failures.
So, as we all know, RTFM, but it certainly bears repeating.
I'm not using the "Link" version of Payflow Pro, but rather the Java component version. However, if I remember the documentation correctly it states that the returned success flag strictly refers to the validtity of the credit card number and date (maybe the 3-digit code on the back, too). The docs state something that the results of the AVS check is for your system to decide upon. In other words, the Verisign gateway will still process the transaction with the minimum "correct" attributes. Based on the result codes, your own system must make a decision.
Heh, you should see the docs for Payflow Link. :) I double checked thismorning and I don't believe it was that obvious. Certainly I would have made it much more blatant in the doc.
I agree. The docs should make it obvious. Especially since if someone is using the AVS, most likely they are going to reject a transaction that returns a negative on the AVS but a positive on the match.
I wrote a CFC layer over the java layer that contains my logic based on the results. With the Link version, it appears that creating a logic layer may be a bit more difficult because the process makes a round trip from client to Verisign then to your server. Possible though.
So the deal here is that their old server would return a special RESPMSG field of AVSDECLINED if the transaction failed an AVS check. BUT BE WARNED!!!!!! They are transitioning to a new server and they have changed the functionality to the worst possible case!! Now the RESPMSG shows "Approved" even when the AVS check fails!!
This is a total distaster. I'm already looking for a new payment processor. The new server goes up on March 15 (forced on us merchants) even though it is obviously far from ready.