Authorize.net Error

[shahed]

My client has been using Authorize.net for over a year with Oscommerce, now he is getting an eror from Authorize.net . Is anyone else is getting this error, I couldn't find any issues..

 

Subject: Transaction Error Notification

 

 

> **Please DO NOT REPLY to this message. E-mail [email protected] if

> you have any questions.

>

> Authorize.Net Merchant,

>

> Your script timed out while we were trying to post transaction results

> to it.

> Transaction ID: XXXXXXXXXXXXX

> Transaction Result: This transaction has been approved.

>

> The following message was displayed to the customer:

>

> ------------------------------An error occurred while trying to report

> this transaction to the Merchant. An e-mail has been sent to the

> merchant informing them of the error. The following is the result of

> the attempt to charge your credit card.

>

> This transaction has been approved.

>

> It is advisable for you to contact the merchant to verify that you

> will receive the product or service.

>

>

> ------------------------------

[Daemonj]

Have you contacted Authorize.net to see if they can determine the reason why their script timed-out and what a possible solution might be?

[Ajeh]

One of my clients is getting that same error today.

 

AuthorizeNet says it's not them.

 

Any one else figure this one out?

[Daemonj]

Check the Apache error logs on your server and see if there are any indications if the problem is on your end.

 

It may be a problem with the server time being more than an hour out of sync with the Authorize.net server. If that is the case, then your server's clock will need to be updated.

 

Let me know if that does not resolve the issue.

[jerryg]

We are having the same issue. Authorize.net told us they time-out after 10 seconds. We are using the SIM method. No solution yet.

[Daemonj]

So has anyone determined who is actually timing out - Authorize.net or your server?

 

I would imagine it is Authorize.net, regardless of what they say.

 

If they are the ones that are indeed timing out then they have to correct the problem, which may be why they do not want to admin to it. ;)

[Ajeh]

So has anyone determined who is actually timing out - Authorize.net or your server?

 

I would imagine it is Authorize.net, regardless of what they say.

 

If they are the ones that are indeed timing out then they have to correct the problem, which may be why they do not want to admin to it. ;)

 

I am kind of inclined to think it is AuthorizeNet.

 

From what my client is telling me the transaction is approved with AuthorizeNet ... The order goes through fine with osCommerce.

 

Since they are generating that error message and it is intermitant ... one would think it is them.

 

As this is Sept 11-2003 and MS2 was released a few weeks ago and this is now showing up ... I am rather inclined to think it is AuthorizeNet.

 

But just for giggles and grins ... Thomas is looking into the code as is Mark, just to see if there is anything wrong on the osCommerce side that we are not aware of.

 

Is anyone getting this error and not having the approval with AuthorizeNet and the order complete with osCommerce?

[kellymeeks]

One of my clients is having the same problem.

 

Goes thru to authorize.net and is charged, but doesn't show up in the cart.

 

They told me today they've gotten a few today that are showing up in the cart, but not making it to authorize.net.

 

They're not happy about orders getting charged, and not know what the customer purchased!

 

I've had this problem for a couple of weeks now - intermittently. To address this, I've written a chunk of code that will:

 

Take the customers name, the date and the dollar amount charged to authorize.net

 

It then goes thru the customers_basket and other relevant tables and rebuilds the last set of items that person put in their cart and didn't follow thru on to purchase.

 

It assumes that only one person with that name, on that date, put items in their cart and DIDN'T purchase them for roughly that amount.

 

There is no way to determine what address the order would have gone to, which does have sales tax implications.

 

It also forces you to 'guess' what level of shipping was used based on the difference in items charges versus what was charged. So, if $100 was charged to the card, and their estimated cart contents was $90 and no sales tax applies to any of their address book values - it's reasonably safe to assume that they selected shipping charges that amount to $10 - probably some form of ground shipping, etc.

 

While just a band aid and rather coarsely done on my part - it does allow the customer to have some idea of what the heck happened to the order.

 

If anyone wants this let me know via this forum. This is basically stand alone code, I haven't done anything to tie this into the oscommerce interface. All you should have to change is the mysql access info.

[weaseldog13]

Just installed 2.2MS1, just got an authorize.net account. I'm getting the same error. i have e-mailed authorize.net... I will post their repsonse. :stupid:

[weaseldog13]

Greetings from Authorize.Net!

 

Basically that means that your site timed out while waiting for a response from our site. In essence, the card is charged but you don't know what they ordered. This is not a common error and should not happen often.

 

Thank you for contacting our customer service group.

Please let us know if there is anything we can do to help you in the future.

 

Josiah

Authorize.Net

Customer Support

:(

[Daemonj]

Does anyone know if changing the script timeout time will have an effect on this problem since this is a standard HTML POST and we are awaiting a response which is outside of PHP.

[Guest]

One of my websites is having the same problem yesterday... the transaction actually went thru just fine but one of our loyal customers recv the error mesg from authorize.net and decided to submit another identical order again...

 

Anyways, I'm trying to figure out where exactly the "timed-out" occured..

 

1) is it more likely a timed-out during the "checkout_confirmation.php" or "checkout_process.php"?

 

I might try to use "set_time_limit(x) in one of the above scripts.. anyone?

 

and..

 

2) what's the max time authorize supposed to return with a response?

 

3) is there a AIM module authorize.net?

 

Thank you very much for your time.

 

rs.

[kagg]

I think, you may check out the problem by redirecting the approval URL to a simple script displaying the response from authorize.net.(so no script time out issue comes in between).

 

You may use the the following code in that script if you are getting response through simple POST:

 

<?php

if(count($HTTP_POST_VARS)){

    while (list($key, $val) = each($HTTP_POST_VARS)){

      $body .= $key;

    $body .= " : ";

    $body .= $val;

    $body .= "<br><br>";

    } 

}

 

echo $body;

?>

 

And if you are using ADC direct connection, then you may add the following code at the end of authorizenet_direct.php to display the output:

 

foreach($response as $key=>$value) // Testing

{  echo "$key: $value<br>"; }  // Testing echo out the result from authorizenet

exit;

 

Its just a hint.

[Juggalojess]

sorry for sounding stupid, this is my first cart and im sooo close. For the POST method, what do you add that script to and where should it live?

 

thanks so much.

 

Jesse

[kellymeeks]

Anyone making any progress with this?

 

Starting to be a huge problem - might have to move a client out of oscommerce because of this problem.

[LeeH]

I've had this problem for a couple of weeks now - intermittently.  To address this, I've written a chunk of code that will:

 

Take the customers name, the date and the dollar amount charged to authorize.net

 

It then goes thru the customers_basket and other relevant tables and rebuilds the last set of items that person put in their cart and didn't follow thru on to purchase.

 

It assumes that only one person with that name, on that date, put items in their cart and DIDN'T purchase them for roughly that amount.

 

There is no way to determine what address the order would have gone to, which does have sales tax implications.

 

It also forces you to 'guess' what level of shipping was used based on the difference in items charges versus what was charged.  So, if 0 was charged to the card, and their estimated cart contents was  and no sales tax applies to any of their address book values - it's reasonably safe to assume that they selected shipping charges that amount to  - probably some form of ground shipping, etc.

 

While just a band aid and rather coarsely done on my part - it does allow the customer to have some idea of what the heck happened to the order.

 

  If anyone wants this let me know via this forum. 

Hi,

 

Would you mind sending me that code? I'm having the same problem with eProcessingNetwork, using a transparent "AIM"-like method. My timeout occurred waiting for a reply back from ePN on an order I manually placed for a call-in customer. The credit card was charged, but the redirect URL never happened, and the OSC order-related tables didn't get updated. When I refreshed the last page of the order process, it, naturally, sent EPN a 2nd order, but also returned me to the Checkout Success page and entered the order in my db.

 

THanks

 

Lee

[kellymeeks]

Hi Lee,

 

Sorry to hear you're having similar problems with your card processor that I'm having with authorize.net .

 

Perhaps the good news here is that if it's happening with osc in general, maybe one fix will take care of all these issues.

 

Contact me privately with your email address, and I'll forward you the code I've worked up with a readme.

 

Kelly

[aspen]

I've been getting these errors too. Anyone solve it yet?

[Guest]

Just want to add that I am also seeing this

"Your script timed out while we were trying to post..." error.

The error has been happening intermittently for over 3 months now.

 

If anyone has an answer or good inkling on what's going on, please post it.

Thanks in advance!

[kellymeeks]

I'm still having this problem, and I'm trying to get to the bottom of it.

 

I've read/seen somewhere that netscape has issues with authorize.net's SIM option. I don't know if that's true, but given the fact that netscape represents a small percentage of the browsers used, that could be contributing to the intermittent aspect of the problem.

 

I'd be interested to see what vendor people are using for the ssl certificates as well.

 

I'm using geotrust.

 

It would be helpful if anyone wanted to share this kind of information, maybe we can find some trends.

[Guest]

I don't believe it's a netscape issue.

Reason being that when that error happens, i actually send an email out to my clients and tell them to just try ordering again.

 

Most of the time, they will succeed in the second try. (Sometimes, they have to try for the third time.)

And most likely, when they do try again they would probably use the same browser.

 

Regarding the SSL cert, we use Thawte.

[Paulblo]

I think I am having a simular problem, but would likr to have it confirmed.

 

When I checkout and get to the confirm order screen and click the confim order button, it does not show me the "Your Order Has Been Processed!" page, instead it goes to the login page.

 

Like you have all mentioned, the card is processed, but the order is not saved in OSC.

 

Does this sound to you guys like the same problem?

 

Thanks,

 

Paul

[nalin]

I think I am having a simular problem, but would likr to have it confirmed.

 

When I checkout and get to the confirm order screen and click the confim order button, it does not show me the "Your Order Has Been Processed!" page, instead it goes to the login page.

 

Like you have all mentioned, the card is processed, but the order is not saved in OSC.

 

Does this sound to you guys like the same problem?

 

Thanks,

 

Paul

 

This is the probem I am having as well. I happened to (personally) get this twice this morning.

 

By looking through my logfiles I have confirmed that authorize.net is indeed relaying through to the site on failed transactions (ie login page) and due to the fact that the site is in a beta-testing phase and displays error messages with X_REPONSE_CODE 2 or 3, authorize.net is handing me back a 1 (or the page is redirected before the X_RESPONSE_CODE is handled).

 

This implies that

1) there is a bug in oscommerce, or

2) authorize.net subtuly changed something with the returned values recently and this messes up processing on some but not all transactions, or

3) authorize.net has screwed up their backend.

 

This is not due to authorize.net timing out in my case, via a conversation with authorize.nets customer support and my logfiles (with ip, and pages, and relatively verbose rewrite logs which show very well that sometimes the redirect is to the proper place and other times to login.php) I am quite convinced that they are relaying back to me, and it is something within oscommerce or my server configuration thats puking. (I dont mean in any sense here to degrade OSC, its a fantastic peice of work, I am simply saying that Authorize.net is, in my case, certainly relaying back to checkout_confirm.php. Anyone with access to their log files should be able to confirm this by searching for the A.N. ip addresses, which in my case seem to be 64.94.118.* but this may be regional or change on occasion, that I am not sure of).

 

Generally I tend to suspect server configuration (Im using S.E friendly urls and mod_rewrite, and heavy modifications to OSC), but due to the number of people posting in this thread (and those who cant search enough to find this thread posting elsewhere), I have to assume that my configuration, in respect to this issue, is sound.

 

I dunno, in any case I wanted to clarify that this is an issue with the way data is handled within OSC, and not a problem caused by a failure of authorize.net to contact the server.

 

Additionally I got the errors this morning from within IE, so it is not netscape specific.

[Paulblo]

nalin,

 

I agree. I changed ou the authorixenet payment module with the one in the contributions and I was able to get authorizenet to redirect back to the billing screen, the only problem now is I can't get a payment to be approved at all.

 

Here is the thread that I have been following in this issue, but for some strange reason something is not right with OSC.

 

http://www.oscommerce.com/forums/index.php?showtopic=54791&st=80

 

You might want to read the whole thread to get caught up....

 

Thanks,

 

Paul

[nalin]

nalin,

 

I agree.  I changed ou the authorixenet payment module with the one in the contributions and I was able to get authorizenet to redirect back to the billing screen, the only problem now is I can't get a payment to be approved at all.

 

Here is the thread that I have been following in this issue, but for some strange reason something is not right with OSC.

 

http://www.oscommerce.com/forums/index.php?showtopic=54791&st=80

 

You might want to read the whole thread to get caught up....

 

Thanks,

 

Paul

 

Rejection of all transactions sounds like a problem more significant then losing records on a small portion of transactions, and for one of our other sites we are using (depricated) weblink which I beleive to be completely incompatible with AIM.

 

Looking through the code, there seem to be a select few redirections to login.php possible from checkout.php;

1) A handful of them in application_top which I ignored for the most part because they were checks which had to be explicitly enabled (in mysql or via administration interface, stuff like checking the user_agent which would be *very* suspect if it was enabled, as I highly suspect that authorize.net does not mimic the user agent in their redirect)

2) One in the checkout_process.php, that would redirect if a session had not been initiated, OR if the session was mangled elsewhere.

 

I believe thats all of 'em, my php is slightly rusty but if memory serves redirects need be sent within the headers, and thus have to be included before the </head> tag.

 

My moneys on 2, but for the record if anyone comes accros the error and ends up on the login page, this can be confirmed by logging in (if this if statement is responsible then logging in will redirect to the checkout_payment page).

 

I started to look for something capible of hosing the session but have been sidetracked (I initiated some nameserver changes which render me incapible of any testing for 48 hrs or so, until the changes propogate and authorize.net can find me)