Page 2 of 2

Posted: Wed Jun 08, 2005 12:31 pm
by Burrito
dreamscape wrote: Didn't mean to offend you if I did, but seriously the only thing you said that I understood was "curl" and "authorize.net" ;)

1. Yes I have fixed the curl to keep it from timing out
2. Why would I want to eliminate the call to a payment gateway in a eCommerce checkout?
3. Thanks, but I don't need any authorize.net gateway functions. I already have an Authorize.net AIM class for managing transactions that works wonderfully.
4. Authorize.net is not the problem. While technically speaking, maybe, because the script is waiting on authorize.net; however, replace authorize.net with XXX processor and the result will be the same (script waiting on XXX processor).
Offended I am not:

1. good but are you sure??...was my point it was
2. to troubleshoot the source of the problem
3. see 2 and if(2){ echo "try burritos";}
4. see 2

XMLHttp (as much as I love it), would be a poor choice in this scenario. Works with other browsers than IE it does, but SSL...sure I am not. Dependent on JS it is, and as mentioned above, cause headaches it could.

try submitting to your action page w/o the call to authorize.net you should to isolate the problem.

Posted: Wed Jun 08, 2005 12:34 pm
by dreamscape
Syranide wrote:....all browsers don't support JScript... and I'd bet someone would be furious if his browser would just stay there for an hour.
Just because all users may not support javascript, doesn't mean you should devalue everyone's experience. At least that is my view on things.

A great example is form validation... using JS to help validate a form can save a user some time and make the experience easier on them, while still performing PHP validation to catch anything the JS might not have and to still validate for users without JS.

A self-refreshing page could still be used for non-JS users, while still providing a more smooth experience to users who have JS enabled by using client side JS HTTP requests to check the status.

Posted: Wed Jun 08, 2005 12:43 pm
by dreamscape
Burrito wrote:1. good but are you sure??...was my point it was
Yes I am sure, by means of some simple logic:

1. There were problems with orders not going through. They either did not go through at auth.net or did go through at auth.net, but did not finish being processed in the script.
2. I increased the script execution time
3. There were still some problems with orders going through to auth.net, but not being processed further in the script. With plenty of execution time, the logical conclusion is that no response was being received from auth.net. This did not always happen, and because it was a rare occurance, it is difficult to debug. However, taking the next logical step, I increased the socket time out.
4. There are still some rare problems where customers do not believe an order has gone through; however, it has been processed with auth.net and has been processed by the script. For this to happen, the script must send a message to auth.net and receive a response. If no response is received, the script will stop where it is at and throw an error back to the client (if they have not timed out already). This means that the order will not be placed in the database. However, they are being placed in the database and processed completely, logically meaning that the CURL connection is not timing out, because if it were, the order would fail to be placed in the database.

Posted: Wed Jun 08, 2005 12:46 pm
by Syranide
of coarse JScript should be used, I like it myself, but if you are gonna use it commercially you better make sure it works too, people wouldn't like to hear saying "oops, I didn't know your browser actually didn't support it".

there is one thing about JScript that is quite tedious that many forget, and which makes their site crap... and that is the lack of errorchecking, JScript easily puts up an error to the user... that would be even worse if you ask me, but I'm with you, but make sure it is complete.

Posted: Wed Jun 08, 2005 1:00 pm
by Burrito
but seeing delays in page loads some people are...thus the point of this thread.

see delays in regular web browsing on your server do they?...my guess is not. Narrow down your problem you must, narrowed to processing of credit cards you already have. Isolate the problem within that function you must....troubleshoot the problem by removing the call to a.net I suggest, determine if that is the source you will, seek other options for requesting info from a.net you can.

very familiar with a.net I am: x_response_code, x_response_reason_code, and x_response_reason_text are all you *should* need to worry about. Responses from a.net with that information should take < 10 seconds....something else is causing your problem I think, and betting it has to do with your class I am.

Posted: Wed Jun 08, 2005 2:11 pm
by dreamscape
Burrito wrote:Responses from a.net with that information should take < 10 seconds....
Yes that is normally about what it takes... however, depending on the time of day and a host of factors on authorize.net's end, it might take up to 2 minutes to authorize a credit card. I have seen this happen. It is rare, but it can happen. Hell, even using authorize.net's virtual terminal often times out. If in fact you were familiar with authorize.net, you would know this and also know that sometimes it does take a bit to receive a response. Familiar, you are not.

I have already identified this as being the problem, which itself does not create a problem for IE, and Mozilla. However, because Safari's default request timeout is only 60 seconds, it does create a problem for Safari users when in the rare case authorization of a card takes more than 60 seconds.

Now, please stop acting like I am some kind of moron.

Posted: Wed Jun 08, 2005 2:18 pm
by dreamscape
Burrito wrote:Isolate the problem within that function you must....troubleshoot the problem by removing the call to a.net I suggest, determine if that is the source you will, seek other options for requesting info from a.net you can.
I have already covered all of this in previous posts... and while I am flattered that you think I am a 2-year-old, most assuredly, I am not.

Posted: Wed Jun 08, 2005 2:22 pm
by John Cartwright
Now, please stop acting like I am some kind of moron.
No one is treating you like a moron or a 2 years old.

Bu your not making much sense. According to you even auth.net virtual terminal can take up to a few minutes. This is unavoidable, as you seem to believe. There is nothing much you can do when it comes to the browsers settings. Perhaps you can issue a warning to users using specific browsers that there is a possibility that their transaction may time out?

Posted: Wed Jun 08, 2005 3:15 pm
by Burrito
very dissapointed at this thread I am so jump out of yodaspeak I will for this post:

You posted on this forum because you are experiencing a problem with your script not functioning the way you'd like it to. You ask for our help (which we are providing from tried and tested experience, not from reading words out of a book). You are now insulted because why? Because you're not getting the answer you want, because you're frustrated that you can't figure out the problem? I don't know... I'm not insulting you here again, I just don't understand why you feel as though I've treated you like a moron.

Your problem lies in your script to authorize.net and you're not experiencing *I assume* any other delays in normal browsing in your web site. Wouldn't the first logical step be to remove the script to a.net to determine if it's somethign else on your action page that might be throwing it off? Apparently it would HAVE to be because you claimed you've already fixed the a.net script...correct? If removing the a.net script causes your page to work, then you know that indeed you haven't fixed it and there's more to do on it. If you still have large delays, then you know it's something else on your action page that needs attention.

The best way to troubleshoot problems is to remove the potential problems, then piece it back together one bit at a time and determine the breaking point. That is what I suggested and you took it as an insult.

Please dont' belittle me by saying "familiar I am not" when you have no background knowledge of my experience with a.net and what my experience with it has been. YOU are the one experiencing horrible delays with a.net and I'm trying to offer you solutions to HELP you resolve those delays. Two minute response times (from a.net) is unheard of on all of my scripts and when I say it should respond in under 10 seconds, that is exactly what I mean...I don't care what time of day it is, nor how loaded down they are, I've never experienced anything more than 30 seconds at most...

if you want help, then dont' bite the hand that feeds you, apparently you've already figured everything out which begs the question... why are you posting in here?

back to yoda I am...

Posted: Wed Jun 08, 2005 3:51 pm
by dreamscape
Burrito wrote:because you're frustrated that you can't figure out the problem?
I know what the problem is. I did not come here for help finding the problem. I came looking for help working out a solution to the problem. I am frustrated because apparently you think I am the biggest moron on the planet.

The problem is exactly this: On rare occasions a response from authorize.net WILL take LONGER THAN 60 SECONDS, and on these occasions, SAFARI USERS get a TIMEOUT because of a default 60 second request timeout that is built into Safari.

(side note, I don't care what your client's experience is with auth.net or your experience developing an auth.net script. Unless you have an account and frequently use it, you cannot even begin to know what their service is like, so please don't claim to. I have an auth.net account and frequently use it. I KNOW from experience that their service is sometimes a bit slow. Like I said EVEN THEIR VIRTUAL TERMINAL ON THEIR OWN SITE OFTEN TIMES OUT)

Further, Authorize.net is completely irrelevant to the problem. Substitute Authorize.net with Payment Processor B and the problem still has the potential of existing.

I have already said that I have already done debugging and tracing the problem down. Everything you keep saying for me to do, in all of your posts, I have already said I HAVE ALREADY DONE. But you keep posting the same thing.

All I can think is that you are either not really reading my posts and just posting canned answers you have stored somewhere; cannot comprehend what I am saying -- both of which I find unlikely -- which leaves the only other option I can think of to be that you think I am some kind of moron. That is why I am frustrated. I said all of this about 3 to 5 times now, yet you still keep posting the same thing.

PS. When I say "on rare occasions it will take longer than 60 seconds to receive a response" I am talking like 1 out of every 200 transactions.

Posted: Wed Jun 08, 2005 3:59 pm
by Chris Corbyn
Well then it seems like you have what you need.

Locked.