[ic] AuthorizeNet Problems - Charges Without Orders

Russell Mann tech at khouse.org
Thu Feb 8 13:13:10 EST 2007


Hello,

I've been running Interchange since Minivend 3.  Recently I upgraded a 
bunch of stuff:

1.  Operating System from Fedora Core 1 to CentOS 4.4
2.  Perl from "v5.8.4 built for i686-linux" to "v5.8.8 built for 
i686-linux" specifically compiled without threads.
3.  IC from 5.2 to 5.4.1.
4.  Running in a Plesk 8.1 environment, using permissions based on some 
post somewhere on the mailing list.  Basically group control and files 
set to interch group, user is domain owner.

I did a makecat to get the newest vlink file for my cgi-bin, but then 
just copied over the whole "catalog" directory for the rest.  I had to 
re-edit lib/Vend/AuthorizeNet.pm to get the Transaction Key to function 
so we don't have to store our AuthorizeNet password on the server in 
plain text.

It works, but with caveats.  There are two major issue's we're seeing, 
and it affects about 25% of total orders.

1.  Charges in AuthorizeNet, with no corresponding order.
2.  Double-charges in AuthorizeNet, with one corresponding order.

I turned on debugging in the AuthorizeNet.pm  and this is what I see on 
the ones that double charge, followed by a successful version of the same:

Vend::Payment:debug: received Net::SSLeay header: 
Vend::Payment:debug: returning thing: {
  'result_page' => undef,
  'header_string' => '',
  'status_line' => undef
}

Vend::Payment:debug: 
authorizenet page:  response: 

Vend::Payment:debug: authorizenet response_reason_text= response_code: 
Vend::Payment:debug: authorizenet result={
  'x_address' => undef,
  'x_city' => undef,
  'x_avs_code' => undef,
  'x_first_name' => undef,
  'x_response_reason_code' => undef,
  'x_response_reason_text' => undef,
  'x_MD5_hash' => undef,
  'x_trans_id' => undef,
  'x_description' => undef,
  'x_ship_to_country' => undef,
  'x_ship_to_first_name' => undef,
  'x_email' => undef,
  'x_cvv2_resp_code' => undef,
  'x_ship_to_zip' => undef,
  'x_ship_to_company' => undef,
  'x_last_name' => undef,
  'x_ship_to_city' => undef,
  'x_method' => undef,
  'x_country' => undef,
  'x_fax' => undef,
  'x_ship_to_address' => undef,
  'MStatus' => 'failure',
  'x_state' => undef,
  'x_type' => undef,
  'x_tax' => undef,
  'x_zip' => undef,
  'MErrMsg' => 'Authorizenet error:  Please call in your order or try again.',
  'x_freight' => undef,
  'x_duty' => undef,
  'x_ship_to_last_name' => undef,
  'x_auth_code' => undef,
  'x_company' => undef,
  'x_phone' => undef,
  'x_invoice_num' => undef,
  'x_ship_to_state' => undef,
  'x_response_code' => undef,
  'x_amount' => undef,
  'x_po_num' => undef,
  'x_cust_id' => undef,
  'x_response_subcode' => undef,
  'x_tax_exempt' => undef
}

Has anyone else encountered anything like this?  Any pointers or can someone point me in the right direction?

Thank you,

Russell Mann



More information about the interchange-users mailing list