[ic] AuthorizeNet sometimes works, sometimes doesn't. Can someone please help me?

Ed LaFrance (New Media E.M.S.) ic_users at newmediaems.com
Sat Aug 21 19:25:23 EDT 2004


At 02:21 PM 8/21/2004, you wrote:

>Greetings,
>I am currently hosting a customer who is using Interchange. We started off 
>with CPanel (I know, I know) using Interchange 4.9. I have since moved 
>everything to a new server, and ditched CPanel. I installed Interchange 
>5.2 from RPMs (RHEL 3.0) after compiling my own non-threaded PERL. We 
>finally got everything working rather well, except for one constant 
>problem. For whatever reason, IC sometimes does not seem to receive 
>notifications from AuthorizeNet that an order was approved or declined. In 
>each case, AuthorizeNet successfully charged the customer's card, but IC 
>reports that an error occurred. This is intermittent and is hard to 
>duplicate. Some days, the customer receives several orders with no 
>problems, and the last 3 days he has received four that have resulted in 
>this problem. I ensured we had the proper modules 
>(Business::OnlinePayment, along with the ::AuthorizeNet module).
>
>I turned debugging on, and uncommented the debugging statements. It 
>appears all the variables being passed to AuthorizeNet are correct, but it 
>seems a proper response is not being sent back. The version in the 
>customer's AuthorizeNet Control Panel has been set to "3.1", as I had him 
>verify this for me.
>
>Pasted below are the debugging output of where things seem to go wrong. 
>First is a transaction that executed properly. The second paste is of a 
>transaction that failed. I am thinking IC might not be waiting long enough 
>for an AuthorizeNet response. Is there any way to increase the wait time?
>
>Good transaction:
>-----------------------( snip )-------------------
>Vend::Payment:debug: placing Net::SSLeay request: 
>host=secure.authorize.net, port=443, script=/gateway/transact.dll
>Vend::Payment:debug: values: {
>... all the values passed to A.net. I have excluded them for the sake of 
>brevity and customer privacy...
>}
>Vend::Payment:debug: received Net::SSLeay header: CONTENT-TYPE: text/html
>DATE: Sat, 21 Aug 2004 18:20:12 GMT
>SERVER: Microsoft-IIS/5.0
>CONTENT-LENGTH: 322
>IISEXPORT: This web site was exported using IIS Export v3.0
>
>Vend::Payment:debug: returning thing: {'result_page' => "1^_1^_1^_This 
>transaction has been approved.^.....
>-------------------------( /snip )------------------
>I chopped off the rest of the response, as I am sure everyone has seen a 
>proper response.
>
>Now for the "failed" transaction:
>-----------------------( snip )---------------------
>Vend::Payment:debug: placing Net::SSLeay request: 
>host=secure.authorize.net, port=443, script=/gateway/transact.dll
>Vend::Payment:debug: values: {
>  ... again, the actual values have been removed for brevity and privacy....
>}
>Vend::Payment:debug: received Net::SSLeay header:
>Vend::Payment:debug: returning thing: {'result_page' => "",'header_string' 
>=> "",'status_line' => "",}
>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,
>------------------------( /snip )------------------
>
>I included some of the return values here so you can see what the debug 
>log is showing.
>
>It seems that AuthorizeNet is either not responding, or is taking too 
>long. AuthorizeNet of course denies the problem is on their end (I tend to 
>agree, my billing software has never had a single problem with their interface)
>
>Can someone *please* offer any insight as to how I might remedy this 
>problem? I am really at my wits end, and it's very frustrating for both me 
>the host, and our customer who keeps getting failed orders, but charged 
>credit cards.

Sean -

Last time I checked, CPanel maintains the system's Perl installation, and 
said Perl was subject to the signalling issue which is known to break some 
functionality in Interchange. The suggestions in the following post should 
help you:
http://www.icdevgroup.org/pipermail/interchange-users/2003-November/036191.html

- Ed




===============================================================
New Media E.M.S.              Technology Solutions for Business
11630 Fair Oaks Blvd., #250   eCommerce | Consulting | Hosting
Fair Oaks, CA  95628          Ed.LaFrance at newmediaems.com
(916) 961-0446                http://www.newmediaems.com
(866) 519-4680 Toll-Free      (916) 961-0447 Fax
=============================================================== 



More information about the interchange-users mailing list