[ic] Vend/Payment sometimes fails to get response from Authorize.Net

Philip S. Hempel interchange-users@icdevgroup.org
Wed Jun 25 16:01:59 2003


On Wed, 2003-06-25 at 15:46, Dan Browning wrote:
> * Philip S. Hempel <pshempel@linuxhardcore.com> [2003-06-25 11:39]:
> > On Wed, 2003-06-25 at 14:04, Chris Wenham wrote:
> > >  I'm having a problem with false negatives on credit card transactions.
> > >  I have a site (http://www.thelpa.com) that uses Authorize.Net to process 
> > > credit cards, but some transactions fail because Vend/Payment.pm doesn't get 
> > > the response from Authorize.Net indicating success. Interchange reports a 
> > > failure to the user, who tries again.
> > >  Meanwhile, Authorize.Net believes it completed the transaction successfully 
> > > on the fist try, and when it sees the customer's second try it fails with a 
> > > "duplicate transaction" error. 
> > > 
> > >  The success of the transaction from Authorize.Net's point of view indicates 
> > > there are no problems with the customer's data entry, so I looked at 
> > > debugging traces from Payment.pm and Authorizenet.pm. Here's what comes back 
> > > on the false negatives.
> > > 
> > > 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:
> > > 
> > >  A normal response--even for a denied transaction--should be chock full of 
> > > header and document data, but all the variables are blank
> > > 
> > >  I don't know how to tell if the problem is mine or Authorize.Net. Can someone 
> > > help me figure out what's going on, or how to fix it?
> > > 
> > > Regards,
> > > 
> > > Chris Wenham
> > 
> > I had the exact error and situation occur the other day. The customer
> > called in and stated that the system (IC) actually told them the
> > transaction was denied and wondered why. In 4.9.7 IC actually produced a
> > new order number when the user submitted a second time it went through
> > (no dupe order but should have been).
> > 
> > I am not even sure my self what caused the error, but for some reason at
> > the same time this occurred the logs had errors in it stating it could
> > not speak with the sql server. After a restart on IC all was well. 
> > 
> > This was weird and thought it to be a isolated incident, like one of
> > those problems the only way to produce is if your hair was suddenly
> > orange, you have to stand on one toe and put your finger into a light
> > socket and finally your name has to be Velcarcha Domanta. OH Well I was
> > wrong.
> 
> I've had this occur on one of my clients' sites as well (4.9.7).  Thinking 
> it might have been a problem relating to PreFork mode, we moved back to HIGH 
> mode and enabled some debugging code (to alert us when IC gets a blank 
> response).  However, we haven't been able to get it to occur ever since.  
> What traffic modes are you two running?

I am running in low.
-- 
Philip S. Hempel

Give a man a fish and he will feed himself for a day.
Teach a man to fish and he will feed himself for a lifetime.

http://linuxhardcore.com/