wisedave1 — 2012-07-25T09:21:15-04:00 — #1
I hope this is the right place to put this problem.....
I am having a problem that I suspect is due to my firewall and/or router blocking me from processing online credit card payments. We use a MOTO facility where we can manually input a client's credit card details for processing.
I put all of the details in the field and hit process...it then acts like it's going to begin that process, then immediately stops. There is no error, no page re-direction...nothing. It only shows their spinning " I'm thinking " wheel for about 1/2 second, then nothing. The page is still there with all of the clients details and no transaction has been placed.
At the request of the payment processor, I tried 3 different browsers (Chrome, IE and FF) but the problem still persists. I then tried from another computer on the same network...same problem. I had an employee try from a different office in a different city and the process worked perfect.
This is why I think it is a problem with the network.
Is there any direction you can think of that I can try? Their help desk is moving very slowly on this.
Thanks for the help!
jestep — 2012-07-25T10:29:01-04:00 — #2
Does it ever error out, or just go back to the page?
I would lean towards something with the payment processor blocking you rather than your router. If your router was blocking it, you would most likely get a timeout error page.
wisedave1 — 2012-07-25T10:45:05-04:00 — #3
Im not getting any errors at all....it's like it stalls, then nothing.
I have been in touch with the payment processor but it would appear as though they don't know anything. They don't see the transaction attempts at all.
Any thoughts are appreciated.
technobear — 2012-07-25T11:19:09-04:00 — #4
I've moved this to Server Config, as it sounds to be more of a network issue.
serverstorm — 2012-07-25T14:23:59-04:00 — #5
Do you know what ports the online payment servers requires to communicate with their service? I would assume they are using the default SSL port 443 but can you confirm?
If you find the ports that are being used we can attempt to use TelNet to access these ports to see if the answer. If for some reason your firewall lost a configuration and a port was disabled or someone accidentally disabled the port(s) then that will stop it right there without necessarily getting errors as the web part of it will work but the secure communications data obviously is not making it to your payment processor, but this will not generate an error except in the firewall logs.
Did you validate your account with your payment processor? Did they change any part of your account or adapt any of their payment systems recently? Just because they don't see any errors connecting they may not be looking to see if your TCP/UDP traffic came to them.
wisedave1 — 2012-07-25T14:32:50-04:00 — #6
I will pose the questions and get back to you......thanks for the help and idea! It's appreciated....
dklynn — 2012-07-25T19:04:27-04:00 — #7
Steve (SS) probably has hit on the correct problem.
I would have started with a verification that the correct information has been supplied in your form, i.e., testing via an intermediate page to print the information to your monitor rather than sending on to the processor.
Finally, processors normally have an error handling directive to return information about why a submission failed so check your configuration.
wisedave1 — 2012-07-26T05:51:00-04:00 — #8
I have heard back from eWay and this is what they state -
[B]"Our gateways operate of the standard SSL port 443 and since you are able to login to the Business Centre which is also on a secure site (port 443) we can eliminate any issues with your firewall blocking this port because if it were you would not be able to access any page with "https://"
With regards to this reply on the forum "Did you validate your account with your payment processor? Did they change any part of your account or adapt any of their payment systems recently? Just because they don't see any errors connecting they may not be looking to see if your TCP/UDP traffic came to them." it would not be relevant to this issue as you are processing the payment via your eWAY Business Centre which is a web based control panel. In cases where you are communicating with eWAY via an API call from your website or application we would then need to look at incoming traffic, ports and IPS."[/B]
I had an employee check to see if transaction can take place from their office location (in another city) and it worked fine. eWay is thinking it may be a firewall/router issue. I swapped routers (albeit the same kind), and it still doesn't work on my end. I normally have AVG running in the background but turned it off and tried....still the same problem.
I don't know where to go from here....any additional thoughts or ideas about this or firewall/router setting would be appreciated!
dklynn — 2012-07-26T07:45:07-04:00 — #9
Good troubleshooting and reporting back here! It appears (from your check from another office) that it is your local system which is causing the problem and have to agree with you and Steve that the culprit is likely your new firewall.
Firewalls are finicky things. I'll bet the new firewall isn't configured the same as your old firewall so I'll suggest that you look to the configuration (port 443).
wisedave1 — 2012-07-26T08:27:49-04:00 — #10
Thanks for the input. Is the firewall you are referring to my router? #confused
My initial thoughts on your response brought me back to the help that eWay is giving me.....being that I can log into their web based portal that is https, port 443 should not be an issue. I say that....but I don't know what that means LOL! I am only parroting what others are saying. It makes me looks smart when I say it but for those in 'the know', if they ask one question they would realise I am speaking a load of ********!
Maybe I just don't have a grip on what eWay is advising me of....
Further input is always appreciated!
serverstorm — 2012-07-26T09:17:34-04:00 — #11
So Dave you don't have a dedicated firewall or is your router both a router and firewall combo; if you don't know then what brand/model is the router?
You are on the money with
My initial thoughts on your response brought me back to the help that eWay is giving me.....being that I can log into their web based portal that is https, port 443 should not be an issue.
so another thing to diagnosis is latency, ie. does the request time out before the service answers? There service may have an incompatibility with your router - this would only be the case if they've recently made changes which the didn't seem to answer in their response.
Try this to help provide more diagnosis informtion:
[*]To determine if an intermediate device is blocking you or latency is poor, open a command line and attempt to traceroute using the traceroute utility
tracert [LEFT]<font color='#333333'><font face='Consolas'><font face='Verdana'>host.address.com</font> -d</font></font>[/LEFT]
the -d tells it to not map to host names.
[*]From the previous traceroute you'll get the IP of the host.address.com (denoting them as x in the telnet code) then telnet:
telnet x.x.x.x 443
see if the telnet establishes an initial connection. if the service doesn't respond you get a message like "Could not open a connection to host on port 443 : Connect failed" otherwise it will connect and wait (with a flashing cursor) for input. You may need to go through each IP that was listed in the traceroute to find if one of the intermidiate routes is causing a problem.
[*]You should also consider asking your other office what type of router they are using and try a similar model at your location.
wisedave1 — 2012-07-26T12:20:56-04:00 — #12
I can't seem to get this part right.....
I opened a command line and typed tracert, but do I need the "[ ]"?
When you reference host.address.com -d, would I use "https://uk.myeway.com/BusinessCentre.aspx"?
Thanks for the help in getting over this first hurdle.
wisedave1 — 2012-07-26T12:34:33-04:00 — #13
OK....I may be getting somewhere now as it seems to be whirring away. This is what I see.....does this tell us anything?
Where do I go from here?
serverstorm — 2012-07-26T12:54:01-04:00 — #14
The tracert looks pretty normal. The 'destination not reachable' are likely router that don't allow ICMP (PING) so they just won't answer, but the good news is that you arrived at your end host. The latency in the system is not too bad.
The next thing is to try telnet (as I described in my last post. Let us know how the telnet goes. Remember to first try telneting to the end I.P then if you can't connect keep trying the next closest I.P. to see if you can telnet to that. This will determine if you SSL is working correctly (I suspect that it is, but this will provide better feedback about routing (http/https is more forgiving about latency than routing protocols so you generally can learn more by using tools like tracert, nslookup, ping and telnet.
wisedave1 — 2012-07-26T14:04:36-04:00 — #15
I can't seem to get the telnet to work properly....
At first, I had to enable it on my computer (Windows 7). Now I can access it...happy days. The problem comes when I try to use a format that the prompt accepts.
The prompt I see at the moment is "Microsoft Telnet> " I used the following format to check each IP from the tracert -
o xxx.xxx.xxx.xxx 
Each ip comes back with "CONNECTION FAILED"
Did I use the proper syntax?
wisedave1 — 2012-07-26T14:28:39-04:00 — #16
In the mean time....I have also ensured AVG is uninstalled, turned off my firewall on my computer as well as turned off a firewall at the router.
This is pretty strange. My knowledge about this is minimal though.
serverstorm — 2012-07-26T14:30:09-04:00 — #17
Good going on getting it enabled
it would be
telnet 188.8.131.52 443
wisedave1 — 2012-07-26T14:39:18-04:00 — #18
Still having a bit of an issue with the format......
CLICK HERE - I have made a SCREENR video to show you what I see.
Thanks for taking an interest.
serverstorm — 2012-07-26T15:00:06-04:00 — #19
Legacy usage is not setup on your machine, which is ok, so issue the full command:
[*]Open command prompt then type:
[*]Once it connects to your telnet client then type
open <font color='#000000'>184.108.40.206 443</font>
[*]You may need to open telnet as a super user but try 1 and 2 first.
wisedave1 — 2012-07-26T15:09:26-04:00 — #20
OK....I tried what you recommended. The first IP I tried got the connection failed message. When I use the IP 220.127.116.11, I get the following message -
"Connecting To 18.104.22.168... and a flashing cursor.
It has had the flashing cursor for a few minutes now. When I type anything, it doesn't do anything...I can type what I want
What does this tell us if anything?
next page →