[ic] Vend/Payment sometimes fails to get response from Authorize.Net
Dan Browning
interchange-users@icdevgroup.org
Wed Jun 25 15:47:00 2003
* 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?
--
Dan Browning, Kavod Technologies, <db@kavod.com> 360.843.4074x217
6700 NE 162nd Ave, Ste 611-210, Vancouver, WA. Random Fortune:
If pro is the opposite of con, what is the opposite of progress?