Help Needed: Better Handling of Failed / Declined Authorize.net Transactions

[Daniel Wagner]

Soeren and all,

I would like to try and improve the handling of declined Authorize.net transactions. Currently if a transaction is declined the shopper gets kicked back to the checkout.index page and receives a minimal error message: Error: Failure in Processing the Payment (ps_authorize). I would like to return more detailed error information (which I think that I can do with a little bit of work), but I would also like the customer to be returned to the payment part of the checkout process so they may correct the problem or use another form of payment. I tried looking through the code, but couldn't easily see how / where this could be done. Any help or pointer in the right direction would be much appreciated.

Thanks,

Dan

[simbo1905]

Error: Failure in Processing the Payment (ps_authorize).

i get two error messages. both "this transaction has been declined" and "error: failure in processing the payment (ps_authorize)".

on the newest version of virtuemart the page that shows the message is the show card page but without the checkout link. just a next button which goes no where. on older versions of virtuemart it used to be the last page that the user saw (the comment page) where at least they could try again.

is the page where you are shown the error functional? i.e. does it give you some sort of second chance?

[Daniel Wagner]

Yes I get both of those messages as well:

Error: This transaction has been declined.
Error: Failure in Processing the Payment (ps_authorize)

The customer gets thrown to the checkout.index page and the Checkout Status indicates Shipping Address, but just shows the cart contents and a next button (see attached image). When the customer clicks on next they get thrown to the main store page.



[attachment cleanup by admin]

[simbo1905]

yep that is what i get also. this suprised me as on the mambo+phpshop version you were thrown back to the previous page which made a bit more sense (although if i remember that did not have a 'previous button' so that you could go back up the cart and change the card details). i have rasied 'Task #634 — card payment declined workflow' about this matter. see 'support+development > BugTracker'.

[Daniel Wagner]

Thanks for opening the BugTracker Task! I have found the following fix to the problem:

Just update the Add function in ps_checkout.php:

At approximately line 775 after:

Code Select Expand

eval( "\$_PAYMENT = new $payment_class();" );
if (!$_PAYMENT->process_payment($order_number,$order_total, $d)) {
$vmLogger->err( $VM_LANG->_PHPSHOP_PAYMENT_ERROR." ($payment_class)" );

Add the following line:

Code Select Expand

$_REQUEST["checkout_next_step"] = CHECK_OUT_GET_PAYMENT_METHOD;

This properly returns the customer to the Payment Method section of checkout!

I have also updated the BugTracker Task.

[simbo1905]

Thanks for opening the BugTracker Task! I have found the following fix to the problem:
[::snip::]
I have also updated the BugTracker Task.

awesome Dan. nice one.

could you create a patch file for us? patch and it's brother diff are two programming tools that allow you to extract just the changes in source code files in a manner that makes it easy to apply them to source code that may have had other updates applied. typically with open source security fixes are issued as patch files. then folks can apply the patches that they want and the patch tool will search for the exact lines to edit.

diff and patch are standard on unix (linux, solaris, freebsd, et al) but you can get them from http://unxutils.sourceforge.net/UnxUtils.zip for windows (patch.exe and diff.exe are in their zip put them in your \windows\system32).

you will need to dig out the original version of the file and put it into the same folder as your modified file. call it something like ps_checkout.104.php

to create a patch open a shell (or command prompt on windows Start > Run... > cmd.exe) then

unix:

cd /path/to/your/changed/file
diff -NaurbB ps_checkout.104.php ps_checkout.php > ps_checkout.task634.diff

windows:

cd \path\to\your\changed\file
diff -NaurbB ps_checkout.104.php ps_checkout.php > ps_checkout.task634.diff

then attached your diff file to the task within the BugTracker itself. this will make it easy for The Man to apply your change to his current version of the code for testing. also anyone that wants to apply that change straight away (e.g. me) can simply do so with the following one liner

unix:

cd /path/to/vm/classes/
patch < ps_checkout.task634.diff

windows:

cd \path\to\vm\classes\
patch < ps_checkout.task634.diff

you can test your diff file works by backing up your new file, renaming the orginal file to be ps_checkout.php, and then run the above command.



p.s. see http://www.cpqlinux.com/patch.html for a bigger explaination of how to get patch and diff to work on whole folders not just individual files which is discussed at http://virtuemart.net/index.php?option=com_smf&Itemid=71&topic=16280.msg36716#msg36716

[Daniel Wagner]

Thanks for the quick diff & patch tutorial simbo1905!

I have updated the Task in BugTracker: http://virtuemart.net/index.php?option=com_flyspray&do=details&id=634&tasks=all&Itemid=91.

This fixes the issue with returning the customer to the Payment Method page, but I still don't seem to be able to return good error messages to the customer from Authorize.net. I see where this is supposed to happen in ps_authorize.php at the end of the file (lines 689 & 697), but I still only get the generic error message: Error: This transaction has been declined.

I have checked the Transaction Detail on the Authorize.net site and it properly shows various errors like: Transaction Status: Declined (Card Code Mismatch) so I'm not sure what's going on...

[simbo1905]

i have applied your patch and it worked a treat. i have updated the BugTracker with this info.

Error: This transaction has been declined.

I have checked the Transaction Detail on the Authorize.net site and it properly shows various errors like: Transaction Status: Declined (Card Code Mismatch) so I'm not sure what's going on...

the msg "This transaction has been declined" is what authorize.net returns. it is good security policy for them *not* to be helpful to what is possible and attempted unauthorized use of a card. saying "bad CVV2 number, guess again" is simply being too helpful from a security point of view!

[simbo1905]

[::snip::]
ps_authorize.php at the end of the file (lines 689 & 697), but I still only get the generic error message: Error: This transaction has been declined.

I have checked the Transaction Detail on the Authorize.net site and it properly shows various errors like: Transaction Status: Declined (Card Code Mismatch) so I'm not sure what's going on...
[::snip::]

i have seen a different error message back from authorize.net. if i put in some totally made up billing address and then try go order i can get back a message like "failed ABC check as zip code does not match card holder address". i cannot remember what the ABC was. this says to me that vm is echoing what authorize.net says.

N.B. by default authorize.net does not check that the billing address matches the card address. you have to go into their console and turn on those options. also be default it does not even check the CVV2 number (!!!). if you dont turn on all the extra checks you *really* are asking to be ripped off....

[Daniel Wagner]

I have added additional configuration options to the Authorize.net payment module. You can now select in the Payment Configuration to show additional transaction error codes to the customer upon a declined / failed transaction. Additional fields are:

• Response Code
• Response Subcode
• Response Reason Code
• AVS Result Code
• Card Code (CVV2/CVC2/CID) Response Code
• Cardholder Authentication Verification Value (CAVV) Response Code

Description: If set to YES then the customer will see the Authorize.net Transaction Response Reason Codes (Response Code - Response Subcode - Response Reason Code - AVS Result Code - Card Code (CVV2/CVC2/CID) Response Code - Cardholder Authentication Verification Value (CAVV) Response Code - in a format like: 2-2-65-Y-N–) along with the Response Reason Text. This can be useful for troubleshooting failed or declined transactions. For further details see the Authorize.net Advanced Integration Method (AIM) Implementation Guide: http://www.authorize.net/support/AIM_guide.pdf

[attachment cleanup by admin]

[guilliam]

hi daniel,

any notes what "Error: 3-1-103-P---This transaction cannot be accepted.
" means?

- g

[Daniel Wagner]

Reference the fields as listed in my post above and the Authorize.net Advanced Integration Method (AIM) Implementation Guide: http://www.authorize.net/support/AIM_guide.pdf for detailed descriptions of the response codes. Your response of 3-1-103-P-- breaks down like this:

• Response Code = 3 = Error
• Response Subcode = 1 = Internal code
• Response Reason Code = 103 = A valid fingerprint, transaction key, or password is required for this transaction.
• AVS Result Code = P = AVS not applicable for this transaction
• Card Code (CVV2/CVC2/CID) Response Code = no data returned
• Cardholder Authentication Verification Value (CAVV) Response Code = no data returned

So, I would guess that your transaction key or password is wrong.

If you haven't already, I recommend that you follow simbo1905's instructions in this post: http://virtuemart.net/index.php?option=com_smf&Itemid=71&topic=15869.msg35141#msg35141 for testing the Authorize.net AIM interface using the sample code they provide.

Hope this helps.

[guilliam]

thanks dan!

it was "transaction key" which is wrong in this case.

site is up and running now. thanks to all the names involved!

- g

[snazzyperry]

I know that this might sound stupid but...

do I have to register first with Authorizenet before using this feature, do they give me a code???

[Daniel Wagner]

Yes you must sign up for a merchant account with Authorize.net: http://www.authorize.net/solutions/merchantsolutions/onlinemerchantaccount/