paul at gishnetwork
Jun 21, 2011, 12:00 AM
Post #1 of 4
(268 views)
Permalink
|
|
Authnet charges without orders
|
|
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'
> ........
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
_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users
|
