News:

Looking for documentation? Take a look on our wiki

Main Menu

Getting single error at the end: Error: Failure in Processing the Payment

Started by conticreative, September 23, 2008, 05:05:14 AM

Previous topic - Next topic

conticreative

I am just about to give up on this one, after reading this entire forum, trying all possible combination in VM and AN (I even created a spreadsheet to make sure not to miss any combos and keep track of them)
I am positive that my ID and transaction keys are correct and I generated multiples
I have used my own credit card as well as text credit cards
I checked the CC types
I did it in test and production mode (making sure to change it respectively)

I am still getting this error:
Error: Failure in Processing the Payment (ps_authorize)
no matter what. No others, just this one but it's enough.

This i not the first time I encounter issues with making AN work, but it's the one time I have run out of options. Anyone that may have a solution out there?

Thank you

conticreative

I have been working on this issue for a day now and I am still lost in space. However, I now know a bit more about what is going on:

1) Apparently, transactions in production mode are being processed by AN. When I login into the AN account I can find the transactions listed and pending.

2) The error message: Error: Failure in Processing the Payment (ps_authorize) is not an AN message but a VM message.

3) I have tried every possible combination of values but I still get the same result. Debug is not helping either. It seems that the transaction indeed goes through, but VM rejects it and won;t give me a confirmation. I have no idea why but I pretty much excluded any obvious setting on the cart that could be creating this issue.

I'll keep testing and I'll post updates. If anyone has a possible solution I would be very grateful.

aristotlejones

I could really use some help on this as well.  Payments are going through, but the users are getting this error.  Please help!


aristotlejones

I've had no luck with this as of yet.  My suspicions are that the error is generated due to the way Authorize.net sends its response, but I'm not sure.  All of my transactions are processed by Authorize.net despite Virtuemart telling me otherwise.

mccomb

Hi,
I encountered these exact symptoms as well.  It was in fact the response that was the problem.  To be clear it was the way virtuemart was processing the response text.  I printed out the response from merchant plus navigate (which is compatible with authorize.net).  The problem was that the http header information was not being filtered out by the VM code.  So the response looked like this:
---------------------------------------------------------------------
HTTP/1.1 200 OK
Date: Sun, 09 Nov 2008 03:52:23 GMT
Server: Apache
Content-Length: 354
Connection: close
Content-Type: text/html; charset=UTF-8

1||1|This transaction has been approved.||N|20592|58_8b5e17b4ea8fb7a88|Purchase Order|1445||AUTH_CAPTURE|58...  and the rest...

---------------------------------------------------------------------
When the ps_authorize.php file tries to parse the response it gets gummed up by those header lines.  This header text should be filtered out.
I wrote some code to filter out the headers and it seems to work.  Here is the code:


$c_mccomb = '|';
$foundmm = 0;
$iimm = 0;
for($imm=0;$imm<strlen($result);$imm++) {
        if (!$foundmm) {
                if($result[$imm] == $c_mccomb) {
                        $foundmm = 1;
                        $resultmm .= $result[$imm - 1];
                        $iimm++;
                }
        }
        if ($foundmm) {
                $resultmm .= $result[$imm];
                $iimm++;
        }
}


Sorry for the lame variable names.  This is actually the first php code I have ever written.

I put this code right above the following line in the ps_authorize.php file:

$response = explode("|", $result);

Then changed that line to:

$response = explode("|", $resultmm);

That line occurs twice in this file.  I put the code only in the  "function process_payment" section.

So it looks like the function  vmConnector::handleCommunication  does not filter out the http headers correctly.

-McComb



lochraven

McComb,

Thank you for this solution. I've been searching for a few days trying to figure this out and I finally found this post.

Again, many thanks!
Joomla 1.5.2  VM 1.1.0

dotlizard

I had this same error, using VM 1.1.3 with Joomla 1.59. I am not sure if the above linked fix will work for the problem, because the cause of the problem, in my case, may be different.

We have Fraud Detection Suite enabled on Authorize.net, and this error occurs when FDS flags the transaction for an AVS mismatch -- I have had five orders error out like this, and what happens is that the order does NOT get recorded in VM, but it does post to Authorize.net, with a status of FDS Authorized/Pending review.

This ONLY happens when there is a fraud alert -- which is why I feel the above linked solution is incorrect, at least in my case. I believe the error originates in the ps_authorize module not properly handling it when AN returns "FDS Authorized/Pending review", which is how it treats an AVS mismatch. So, the answer in our case was to disable the default behavior in VM where the customer is allowed to put in different bill-to/ship-to information.

Allowing for customers to have one person billed and ship to another name in another state (the default VM permits this) is inadvisable to say the least, and can result in all sorts of chargebacks with no recourse to get the merchandise back. If for some reason we were to determine that we wanted to allow multiple-address transactions, I would want to implement code that would handle the Pending Review status differently from the "accepted/success" status (by informing the customer that their transaction would have to be verified and their order was on hold), but I doubt we'll be doing that.

Anyway, just my $0.02, since this error (in our case) the error was not something we just wanted to make go away.

dotlizard

SOLUTION (applies to VM 1.1.3 and Joomla 1.59, ymmv on other versions)

confirmed that the error code (in my case) with no further information was caused by an unknown transaction status code being returned by Authorize.net. Status codes are listed here: http://www.authorize.net/support/merchant/

in ps_authorize.php, there are only three statements set up, and they are for response codes 1, 2, and 3 -- there's no statement for response 4. Since these statements are what return the information about the error, it explains why there was a just an error and no explanation.

So, to solve, added an additional set of instructions to handle status code 4. You will want to copy the instructions for "Success - Approved" (see below) because you do want the order to be recorded, and the transaction ID captured, in case you decide to process the transaction. Just change the if ($response[0] == '1') to if ($response[0] == '4').

DISCLAIMER: this is not a refined solution. In order to really handle these 'held for review', there should be a new order status code set up and custom messages shown to the customer to inform them there was a problem so their transaction is on hold.

But, this at least keeps you from having orders disappear while the held transactions still show up in AN.


      // Approved - Success!
      if ($response[0] == '1') {
         $d["order_payment_log"] = $VM_LANG->_('PHPSHOP_PAYMENT_TRANSACTION_SUCCESS').": ";
         $d["order_payment_log"] .= $response[3];

         $vmLogger->debug( $d['order_payment_log']);

         // Catch Transaction ID
         $d["order_payment_trans_id"] = $response[6];

         return True;
      }


I will post the more refined solution when I figure it out.

dotlizard

note: also need to duplicate this code and make a version for status code 4:
      // Approved - Success!
      if ($response[0] == '1') {
         $d["order_payment_log"] = $VM_LANG->_('PHPSHOP_PAYMENT_TRANSACTION_SUCCESS').": ";
         $d["order_payment_log"] .= $response[3];
         // Catch Transaction ID
         $d["order_payment_trans_id"] = $response[6];

         $q = "UPDATE #__{vm}_order_payment SET ";
         $q .="order_payment_log='".$d["order_payment_log"]."',";
         $q .="order_payment_trans_id='".$d["order_payment_trans_id"]."' ";
         $q .="WHERE order_id='".$db->f("order_id")."' ";
         $db->query( $q );

         return True;
      }


... so that it updates the database properly. Still working on this :)

David Richmond

Thanks for the help finding out the root of this problem.  I made all the corrections to the ps_authorize.php, but Unfortunately the "Error: Failure in Processing the Payment (ps_authorize)" error messages are persisting but auth.net is capturing the transaction for sure and the the transaction status reported in auth.net is: "Captured/Pending Settlement"

Auth.net says that status is the standard accepted success  

So its weird what am i missing i added an


 elseif ($response[0] == '4') {
                       $d["order_payment_log"] = $VM_LANG->_('PHPSHOP_PAYMENT_TRANSACTION_SUCCES$
                       $d["order_payment_log"] .= $response[3];

                       $vmLogger->debug( $d['order_payment_log']);

                       // Catch Transaction ID
                       $d["order_payment_trans_id"] = $response[6];

                       return True;
               }


and an:

          elseif ($response[0] == '4') {
                       $d["order_payment_log"] = $VM_LANG->_('PHPSHOP_PAYMENT_TRANSACTION_SUCCES$
                       $d["order_payment_log"] .= $response[3];
                       // Catch Transaction ID
                       $d["order_payment_trans_id"] = $response[6];

                       $q = "UPDATE #__{vm}_order_payment SET ";
                       $q .="order_payment_log='".$d["order_payment_log"]."',";
                       $q .="order_payment_trans_id='".$d["order_payment_trans_id"]."' ";
                       $q .="WHERE order_id='".$db->f("order_id")."' ";
                       $db->query( $q );

                       return True;
               }


But still getting my generic vm error message all the while Auth.net charges the card and VM never records the order....  :'(

This is my 2nd Virtuemart site but this is very sadening to have such a silly error holding up my whole operation :(  Joomla 1.5.10 VM 1.1.3

==Update Solved

Ok my problem wasn't related to the response == 4 but the headers apparently was the problem so adding the above code to the ps


$c_mccomb = '|';
$foundmm = 0;
$iimm = 0;
for($imm=0;$imm<strlen($result);$imm++) {
        if (!$foundmm) {
                if($result[$imm] == $c_mccomb) {
                        $foundmm = 1;
                        $resultmm .= $result[$imm - 1];
                        $iimm++;
                }
        }
        if ($foundmm) {
                $resultmm .= $result[$imm];
                $iimm++;
        }
}


and replaced
$response = explode("|", $result);
with
$response = explode("|", $resultmm);

in function process_payment of ps_authorize.php

Moral: DO all the above steps that are in each post of the thread.


cwk

I'm getting the same error as David Richmond, but it does not appear that my error transactions are hitting Auth.Net as his did, and so I'm leery of hacking the code.  I've turned on logging at the TIP level, which still doesn't show the entire dialog, as I'd expect from a debug level with that name, and I get the following result for my test user:

10:37:52 23/06/09 VirtueMart [DEBUG] [xx.xx.xx.xx] [testuser] Beginning to analyse the response from secure.authorize.net
10:37:52 23/06/09 VirtueMart [ERR] [xx.xx.xx.xx] [testuser] Failure in Processing the Payment (ps_authorize)


Unfortunately, the debug setting doesn't show me the result coming from secure.authorize.net.  I turned off test mode for authorize.net and ran a live card, but it did not hit them.

I've confirmed and reconfirmed the Auth.net username/authcode.  Any other obvious things to change or verify?

What to do?  I really want to get away from PayPal, but I'm locked in until I get this fixed.  

cwk

Two steps forward, two steps back.  Got on the phone with Authorize.Net and had an RTFM moment.  I did not have the correct information in the API entry -- no, it's not the login and password.  So that part is done.  But now transactions are going through yet the exact same set of error messages are appearing.  The screen has the red X ball and the same

Error: Failure in Processing the Payment (ps_authorize)


and the log file has the same messages.  Debugging this is like listening to one side of a very terse phone call.  Still looking for a solution.  I have a funny feeling I'll be going through David Richmond's hacks, although I'm still nervous about hacking code that moves money.

cwk

To David Richmond and McComb:  Would you guys post copies of your ps_authorize here?  The developers seem busy with their day jobs (perfectly understandable).  Let's work with the system and create a patch.  As Open Source projects go, this one seems a bit loose in its patch discipline.