TOPIC: Error handling payments (authorizenet.php)

We are continuing to work on this... while almost all of our users are using Authorize.net just fine... we know it's important to the small number that are having this issue. It does appear to be server related, but tracking down exactly what it would be.

@isaiah - are you saying you have 50 successful Authorize.net transactions... along with 30 unsuccessful ones? That wouldn't make any sense to be server related.

Can you check your Authorize.net account and find any reasons there for declined transactions? There is just no reason that makes sense why some transactions would be able to communicate with Authorize.net while others can not.

It would appear the potential issue here (as it does appear server-related) is DNS settings. Authorize.net changed all of their URLs and certificates... but if your server caches an IP address instead of performing a fresh DNS lookup with each API call... then your server could be trying to connect with the old Authorize.net URLs instead of the new ones.

We've seen in a couple of cases where the error response said it failed to connect to what was the old Authorize.net URL... which DT Register code no longer uses. So that seems to show that the server is still looking in an old direction, despite what our code says to do.

Please check with your web host to see if you can disable DNS caching.

Interesting.

Can you give us a couple of cached and currrent server address examples so we can test how they resolve on our end?

Just ask your host to check and see why secure2.authorize.net/gateway/transact.dll is not accessible from your server.

On one client site, we got an error back saying the old "http" version of the Authorize.net URL was not accessible. It became clear that despite the updated URL in the DT Register code, the server was still trying to access an old one. Something is cached most likely.

@nathan.dth -
That's correct, both successful and failed payments. Sometimes, the same person who failed, is able to make a successful payment later.
I don't think it's that Authorize.net is declining the transaction; there is no record of declined transactions in our account. it appears the transaction never makes it to Authorize.net to even try to process. They enter cc info and when the click "submit" it promptly takes them to a page that says "Try Again" with no explanation why it failed to sync up.

A quick check of the URL pulled up successfully. Hmm, maybe this isn't the problem in our case. I have caching turned off at the Joomla level as well. (the quick check was done via wget on a linux CLI)

Any other suggestions? This issue doesn't crop up as regularly as the paypal error I have a ticket in about fwiw... (hope i don't jinx myself by saying that)