Re: [ic] AuthorizeNet Problems - Charges Without Orders

[Ron Phipps <suppressed>]

Russell Mann wrote:
> 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

Hello Russ,

Are you also seeing errors about sendmail being unable to send?

Try setting Interchange to high traffic mode and also make sure in the high traffic section that "MaxServers 0" is set.  Lastly set the environment variable "PERL_SIGNALS=unsafe" before IC is started.

--
Ron Phipps
End Point Corporation
suppressed
_______________________________________________
interchange-users mailing list
suppressed
http://www.icdevgroup.org/mailman/listinfo/interchange-users