[ic] Authnet charges without orders

Paul Jordan paul at gishnetwork.com
Tue Jun 21 07:00:28 UTC 2011


Hi Guys, IC: 5.6.3

After 5 years of flawless service, a few days ago one of our IC's started 
consistently failing to create orders that were charging successfully at 
Authnet:

==========
Safe: Real-time charge failed. Reason: Authorizenet error: . Please call in 
your order or try again.
>       for(qw/
>               charge_total_message
>               pay_cert_total
>       /)
>       {
>           delete $Scratch->{$_};
>       }
>       die errmsg(
>               "Real-time charge failed. Reason: %s\n",
>               errmsg($Session->{payment_error}),
>           );
==========

Paypal and Offline orders were working fine so I did some research to see 
what had changed on the serve to cause such an abrupt and consistent 
problem. I realized the sites perl was updated 10 minutes before the 
problems started to occur. The update was a minor one and remained in the 
5.8.8 family I think - I didn't personally do it, and from what I 
understand, it was not a yum style update.

This seemed like the most logical culprit so a consultant and I opted to 
potentially bypass the whole issue and upgrade the whole shebang to 5.14.1. 
The problems still occurred. At the time I was using LWP for transacting 
with AuthNet. Both him and I had remembered the issues posted to the mail 
list regarding potential problems, and since I was not between and rock and 
a hard place, we opted to use wget.

Wget seemed to solve the issue. However, over the last 3 days, 2 more (out 
of many good) transactions have been affected - where Authnet charges the 
customer and IC errors and does not save anything. A vast improvement, but 
still not the  blissful worry free days of years past.

I believe IC is running in LOW, because I have not specific TRAFFIC. I have 
been reading fiddling with TRAFFIC might help as well - for example, RPC 
mode appears to have helped others. I notice no similarities with the failed 
transactions.

My questions are does any of this sound familiar to someone? Why do the 
traffic modes exist, and what constitutes needing High, or RPC? I'm willing 
to throw switches and monitor things, I'd just like to understand a little 
better what it is I am throwing. I am looking through the archives now, but 
hopefully someone can chime in with some advice.

Does high traffic mean - amazon.com like? Is there some way to gauge what 
settings I might need to use for TRAFFIC based on session or tmp size 
increase? I suppose my main question would be are there any pitfalls with 
setting the TRAFFIC too high, or are low traffic sites just fine under High 
or RPC? Also, is TRAFFIC affected by the literal traffic for the physical 
server (all sites), or just this instance of IC?

Anyone know if there has been any major improvements from 5.6.3 to the 
current dev version that might resolve this issue, or at least handle 
failure more gracefully? I'm thinking if someone tried solving similar 
issues lately in Payment.pm or Order.pm, that would be nice to know - I feel 
as if I don't want to upgrade to a dev version to try and solve such a 
pronounced quick-onset problem. I really wish I was able to roll back to the 
original perl I was using last week - but I don't know if that is still an 
option at this point.

I feel as if I should mention this as well. Sometimes I see this:

  Unable to send mail using /usr/sbin/sendmail
  > To 'XXX at yahoo.com'
  > ........

However, I believe the emails are in fact still sent. It doesn't happen too 
often, but it does happen. I mention this because someone said RPC helped 
with that too - and maybe that is another symptom saying that I am in need 
of fiddling with TRAFFIC.

The only other thing I can think to mention is that most orders are going 
through, and it looks as if I can still get valid Authnet errors in the logs 
(AVS mismatch, etc). The only time I know it fails is when I see the brick 
wall error: "Authorizenet error: . Please call in your order or try again."


Thank you very much for for your help

Paul




More information about the interchange-users mailing list