new Authorize.net AIM setup not working

[spoma]

I am setting up a new website on OSCommerce and the last piece is to get the credit card processing working.  This website is replacing a current webstie that I already have so I am already working with a payment gateway.  This gateway (plugnpay) supports Authorize.net AIM so I have configured this in my OSCommerce website.  

 

I am using the authorize.net (AIM) API version 3.1

 

My payment gateway has a test credit card that I can use for setting up and debugging.  This is the credit card that I am currently using.  When I process the credit card through the new website, the payment Gateway sees it as a success and charges the credit card.  However, the website displays:

ERROR PROCESSING - Please try again and if problem persist, please try another payment method.  I see the url is bringing me to ? payment_error=authorizenet_cc_aim&error=general

 

I can't find any errors in logs that I have looked in.  I am not sure where to go to start trouble shooting and try to get to the bottom of this.  Please let me know if anyone has any information that might help me get further.  

 

Thanks. 

[spoma]

As a little more information, I wanted to see what the response code was coming back from the payment gateway.  In the case of error=general I added $response['x_response_code'] to also be displayed in the URL.  so it appears that the response code coming back is a -1 which doesn't seem correct.  

 

I am jus going off the possible values in the case statement and they all seem to be positive numbers.  Does anyone know what a -1 might represent?

[spoma]

I think the -1 in the response code is because the gateway is returning a U and the field can't store a U.  Is U a valid entry for the response_code?

[spoma]

OK.  So, I have found that $raw[0] is equal to 1 (which is the response code but $response['x_response_code'] is equal to -1.  The fact that it is equal to -1 is why I am getting a general error.  But, it seems to be coming over as a 1 from the gateway vendor.

 

I am by far not a PHP expert but I notice this code:

$response = array('x_response_code' => '-1',
                        'x_response_subcode' => '-1',                        
'x_response_reason_code' => '-1');

it almost appears to me that it is setting $response['x_response_code'] to be -1 and immediately following is the error validation on this field.  Since it is -1 it goes to the else which is a general error.

 

Any thoughts or direction would be greatly appreciated.  Thanks.

[spoma]

I have done a little more debugging and because count($raw) in my example only hits 39 it is taking the -1 from above and using that is the value of x_response_code.  It appears that the code is expecting there to be 54 fields or more in the reply.  Is this correct?  Should the gateway service be returning 54 fields?

 

Thanks.

[Bob Terveuren]

Hi

 

You could just change that section of the code to remove any mention of $raw[50] to [54]

        if ( count($raw) > 39 ) {//I'd even consider just making this if(count($raw){
          $response = array('x_response_code' => $raw[0],
                            'x_response_subcode' => $raw[1],
                            'x_response_reason_code' => $raw[2],
                            'x_response_reason_text' => $raw[3],
                            'x_auth_code' => $raw[4],
                            'x_avs_code' => $raw[5],
                            'x_trans_id' => $raw[6],
                            'x_invoice_num' => $raw[7],
                            'x_description' => $raw[8],
                            'x_amount' => $raw[9],
                            'x_method' => $raw[10],
                            'x_type' => $raw[11],
                            'x_cust_id' => $raw[12],
                            'x_first_name' => $raw[13],
                            'x_last_name' => $raw[14],
                            'x_company' => $raw[15],
                            'x_address' => $raw[16],
                            'x_city' => $raw[17],
                            'x_state' => $raw[18],
                            'x_zip' => $raw[19],
                            'x_country' => $raw[20],
                            'x_phone' => $raw[21],
                            'x_fax' => $raw[22],
                            'x_email' => $raw[23],
                            'x_ship_to_first_name' => $raw[24],
                            'x_ship_to_last_name' => $raw[25],
                            'x_ship_to_company' => $raw[26],
                            'x_ship_to_address' => $raw[27],
                            'x_ship_to_city' => $raw[28],
                            'x_ship_to_state' => $raw[29],
                            'x_ship_to_zip' => $raw[30],
                            'x_ship_to_country' => $raw[31],
                            'x_tax' => $raw[32],
                            'x_duty' => $raw[33],
                            'x_freight' => $raw[34],
                            'x_tax_exempt' => $raw[35],
                            'x_po_num' => $raw[36],
                            'x_MD5_Hash' => $raw[37],
                            'x_cvv2_resp_code' => $raw[38],
                            'x_cavv_response' => $raw[39];


          unset($raw);
        }
      }

Reading this http://www.authorize.net/support/AIM_apiupdates.pdf mentions that you can force a partial authorisation - see if there's someplace in the AIM merchant dashboard that you can do so?

[spoma]

Bob

 

Thanks for the response.  I had thought of that but I wasn't positive that it was the first 39 values they were giving me so I was concerned that I would end up with things in the wrong field.  Usually I am more than willing to play around but I was a little nervous since this is part of the payment area.  I will take a look and see if I can find an area to force a partial authorization.

 

I'll let you know what I find.

 

Thanks.

[Bob Terveuren]

Hi

 

I've had another look at the code and these variables:

 

                            'x_account_number' => $raw[50],

                            'x_card_type' => $raw[51],

                            'x_split_tender_id' => $raw[52],

                            'x_prepaid_requested_amount' => $raw[53],

                            'x_prepaid_balance_on_card' => $raw[54]);

 

that are taken from $raw[50] - $raw[54] are not actually used anywhere within the payment module (or, indeed anywhere else in a stock osCommerce) so removing them should not cause any problem